PHP2Shell: Technical Analysis of CVE-2026-109618 and CVE-2026-109619

On October 21, 2026 (14:01 UTC), the PHP development team released out-of-cycle security updates addressing two critical vulnerabilities in the PHP runtime that can lead to unauthenticated Remote Code Execution (RCE) with the privileges of the web worker account. The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619, and both are rated 9.2 (Critical) on the CVSS v4.0 scale:

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

The vector explains the score: the attack is network-reachable and requires no authentication or user interaction, but it is rated high complexity (AC:H) and has attack requirements (AT:P), so it falls short of the maximum. The “CVSS 10.0” figure that circulated before the release came from leaked, pre-disclosure reports. It is not the official PHP rating.

The community calls the issue “PHP2Shell.” The vulnerabilities reside in the PHP core, so the risk is not limited to a single content management system (CMS) or plugin. PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed (LSAPI) deployments must each be evaluated based on their version and configuration. The attack paths are not identical across these environments.

According to PHP’s official security advisories, the two vulnerabilities have distinct root causes:

CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), “RCE via OOM corruption”: Error handling during out-of-memory (OOM) conditions can interrupt PHP while request memory is only partially initialized. Request cleanup may then treat that invalid data as valid.
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), “RCE via stale global state”: Request-owned global state can survive after its memory has been freed. A later request on the same worker may then use it.

Both vulnerabilities are fixed in the following versions:

Branch	Affected	Fixed
8.5	< 8.5.12	8.5.12
8.4	< 8.4.27	8.4.27
8.3	< 8.3.36	8.3.36
8.2	< 8.2.35	8.2.35
7.4 / 8.0 / 8.1 (EOL)	Affected	Source backports only (see Section 6)

This article examines the root causes, exploitation conditions, how the risk differs between runtime environments, remediation, and detection and response steps for Blue Teams. The technical evaluation is based on the official PHP security advisories. The publication of Proof-of-Concept (PoC) code, demonstrations of successful exploitation, and observations of real-world attacks are treated as separate categories of evidence.

1.1. Timeline

Date / Time (UTC)	Event
Oct 20, 2026	Details of the vulnerabilities leak ahead of coordinated disclosure (a now-deleted Hacker News post). Claims of “CVSS 10.0” and “PHP 5 and later” circulate.
Oct 20, 2026, ~19:33	PHP publishes an advance notice of an out-of-cycle critical security release.
Oct 20, 2026	CERT-EU publishes Security Advisory 2026-018.
Oct 21, 2026, 14:01	PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and publishes the GitHub security advisories.
Oct 21, 2026	Distributions that received the patches in advance publish updates. For example, Ubuntu publishes USN-8948-1.
Oct 22, 2026	Originally planned coordinated disclosure date.

2. Technical Background

When it processes a web request, PHP manages request data, error state, session state, and various internal object and extension states. The lifecycle of these data structures must be controlled carefully, especially in long-running worker processes such as PHP-FPM children and Apache mod_php workers, which serve many requests in succession.

Freeing the memory allocated to a request when it terminates is not enough. Global or process-level references that subsequent requests might access must also be left in a valid state. Likewise, if PHP’s error handling aborts processing because a memory allocation failed, any partially built state must be safely sanitized afterward.

These two vulnerabilities show the security impact of two different lifecycle flaws: one in memory management and error handling, the other in cross-request state handling. Both can be triggered before any application code runs, so application-level security controls, including CMS and plugin updates, cannot prevent them.

3. Technical Analysis of the Vulnerabilities

3.1. CVE-2026-109618: OOM-Induced Memory Corruption

Weakness classes: CWE-416, CWE-755, CWE-824, CWE-1325, CWE-1419

PHP uses longjmp() to leave the current execution context when it runs out of memory (OOM). This vulnerability is caused by that mechanism.

In certain execution contexts, request memory becomes reachable before all its internal fields are initialized. If a memory allocation fails during this window, the early exit leaves the request’s internal state inconsistent. Request shutdown can then read uninitialized or invalid data, or branch on corrupted values.

The failed allocation does not have to be directly related to the corrupted data. The core problem is that an OOM event disrupts control flow, and the lifecycle of request memory is not managed correctly across that disruption.

OOM trigger strategies (high level)

The advisory notes that several attacker-controlled strategies can drive PHP into the OOM condition. Most of them involve the multipart/form-data request body parser, which runs during request startup before any application code:

Missing declared length: Multipart requests without a usable declared content length can pass the initial post_max_size check and keep supplying decoded body data.
Unbounded part headers: Individual multipart parts can carry an unbounded number of headers. These consume far more memory inside PHP than on the wire.
Empty file controls: Empty file inputs do not count toward max_file_uploads but still create file metadata arrays. Nested field names multiply this work.
Application input: Application-specific input can also cause large or repeated allocations.

Susceptibility by SAPI

Apache mod_php: Runs request shutdown even when request startup fails. Body parsing during startup can exhaust memory_limit, and shutdown then processes the invalid state. According to the advisory, a full remote exploit was validated over HTTP against mod_php with default settings, and no application-specific code is needed to reach the path.
PHP-FPM: The FPM child exits when request startup fails, so this specific path does not occur in the same way. An OOM that happens after normal request initialization may still reach the vulnerable code. The advisory states that no complete FPM exploit has been demonstrated for this CVE.
FrankenPHP: Source analysis suggests it is likely susceptible, similar to mod_php, because teardown logic can run even when startup fails.
LSAPI (LiteSpeed): Its model is closer to FPM. Application-specific exploitation is considered likely but not validated.

Risk assessments for these environments must be based on the exact version and runtime model in use.

Remediation approach: PHP removed the longjmp()-based early exit for OOM conditions. It replaced it with two mechanisms. A delayed soft OOM is handled gracefully at the next safe virtual machine instruction point. A hard OOMterminates the process immediately (_exit()) if memory usage reaches a second, higher threshold. Normal memory_limit enforcement is kept. The goal is to make sure teardown routines never act on partially initialized memory.

3.2. CVE-2026-109619: Use-After-Free via Stale Global State

Weakness classes: CWE-416, CWE-755, CWE-824, CWE-1325, CWE-1419

The second vulnerability arises because global state kept in a running worker process can still hold references to a request’s memory after that memory has been freed.

PHP keeps several kinds of internal state in the running process, including error, session, object and extension state. Some of these can point into memory owned by a single request. When the request ends, that state must be reset. Two things can break this:

Skipped reset: Fatal errors, including OOM conditions and timeouts, can skip the reset entirely.
Late repopulation: Non-fatal diagnostics emitted during late shutdown can repopulate error state after it has already been cleared.

If the next request touches this stale state before normal initialization resets it, a Use-After-Free (UAF) condition occurs. The advisory lists heap use-after-free, memory disclosure, and RCE with the web worker’s privileges as possible impacts.

Producer and consumer model

According to the advisory, exploitation requires two components, a producer and a consumer, that run in the same worker process:

Producer: An operation leaves request-owned state published in a global area. This typically happens when a fatal error interrupts the request, for example an OOM condition or a timeout, so the state is never reset.
Premature release: The request heap is freed while the global state still holds the dangling reference.
Consumer trigger: The same worker process receives a new HTTP request.
Early access: Before normal request initialization finishes, an operation in the new request reads or writes the stale state.

The producer and the consumer can be different HTTP requests. Running multiple workers and recycling them more often lowers the probability of success, but neither removes the underlying condition.

Consumer paths

The official advisory identifies two main consumer paths that access stale global state before normal request initialization:

INI configuration diagnostics:
- Trigger: A warning, notice or deprecation produced while invalid or deprecated INI values are applied before php_request_startup() can touch stale error state. The message does not have to be displayed or logged. error_reporting settings, the @ operator, and disabling display_errors or log_errors do not preventthis.
- Apache mod_php: The path applies to per-directory configuration (.htaccess, php_value / php_flag, and Apache directives) that is evaluated before request initialization.
- PHP-FPM: The path is conditionally exposed when the frontend passes PHP_VALUE or PHP_ADMIN_VALUEFastCGI parameters. Pool configuration and .user.ini files are evaluated differently and do not provide the same early consumer.
Session upload progress lifecycle: The session upload progress handler runs before ordinary session initialization and can consume state left behind by an interrupted earlier upload. This feature (session.upload_progress.enabled) is enabled by default, and the application does not need to call session_start().

Validated and conditional cases

PHP 8.5 fatal_error_backtraces (strongest case): Backtrace state generated during fatal error reporting can persist in global state after request memory is freed. Early diagnostics in a later request can then access it. This is the basis of the confirmed RCE against mod_php.
Session upload progress lifecycle: Exploitation is validated against both Apache mod_php and PHP-FPM. The demonstrated producer is an OOM during input processing, which links this path to the same class of multipart-driven memory exhaustion described in Section 3.1. FPM terminates the worker when request startup fails, so do not assume that every step described for mod_php applies to FPM unchanged.
Other error, exception, object and extension state: These are conditional. Exploitability depends on the operations attackers can reach, the application flow, and the loaded extensions.

Additional SAPI notes

LSAPI: A conditional candidate.
FrankenPHP: No early consumer was established in its default configuration. This does not mean it is immune.

Remediation approach: PHP implemented a broader cleanup that systematically clears the relevant global state beforerequest memory is freed. The goal is not only to close the known consumer paths but to secure the lifecycle of any stale state that a later request could otherwise reach before normal initialization.

3.3. Comparison of the Two Vulnerabilities

	CVE-2026-109618	CVE-2026-109619
Bug class	Control-flow disruption on OOM, leaving partially initialized request memory	Stale global reference (UAF) that crosses request boundaries
Typical trigger	Memory exhaustion during request startup (multipart parsing)	Producer request (fatal/OOM/timeout) followed by a consumer request on the same worker
Strongest validated case	mod_php, default settings	mod_php (8.5 fatal backtraces); session upload progress on mod_php and FPM
FPM	Full exploit not demonstrated	Validated via session upload progress
Fix	Removal of `longjmp()` on OOM; soft and hard OOM	State reset before request memory is freed

The two issues are independent at the code level, but they reinforce each other in practice. An attacker-induced OOM is both the trigger for CVE-2026-109618 and a demonstrated producer for CVE-2026-109619. Mitigations that reduce attacker-controlled memory exhaustion therefore reduce exposure to both. The fixes differ, and each must be verified separately.

4. Attack Surface and Potential Impact

These vulnerabilities affect PHP runtimes that process web requests and can be triggered before application code runs, so the theoretical attack surface is very large. Still, the fact that an application is built with PHP does not prove that exploitation is possible. The actual risk depends on the running version, the SAPI, the configuration, and whether the specific attack paths are reachable.

The following environments need particular attention:

Apache mod_php: The highest-risk environment. Both CVEs have validated RCE paths here, and default settings are sufficient for CVE-2026-109618.
PHP-FPM: CVE-2026-109619 is validated through the session upload progress path. CVE-2026-109618 is theoretically reachable after request initialization.
php-cgi: Deployments that serve PHP requests via CGI.
FrankenPHP and LiteSpeed/LSAPI: Behavior and reachability of the attack paths must be verified independently.
Container and shared hosting infrastructure: Systems where multiple applications or tenants share the same PHP runtime.
Bundled PHP: Control panels such as cPanel and Plesk, appliances, and vendor software that ship their own PHP builds.

Official PHP advisories confirm a validated exploit for CVE-2026-109618 on mod_php. For PHP-FPM, source analysis supports theoretical exploitability, but no complete exploit has been demonstrated. For CVE-2026-109619, validated impact has been demonstrated through the fatal backtrace path on mod_php (PHP 8.5) and through the session upload progress path on both mod_php and PHP-FPM. For FrankenPHP and LSAPI, theoretical likelihood must be kept separate from verified exploit evidence.

For PHP-based platforms such as WordPress, Drupal, Joomla, Magento, Laravel and Symfony, the first step is to identify the exact PHP runtime version and the SAPI that actually serves requests, rather than listing application names. Updating a CMS or plugin does not replace patching the PHP core, and application-level security plugins such as WordPress WAF plugins cannot inspect a request before PHP’s core parses it.

Potential impacts of successful exploitation include:

Data access: Unauthorized access to sensitive data and configuration readable by the web server account.
Memory disclosure: In-process memory may be exposed (CVE-2026-109619).
Tampering: Modification of web content or application source code, including webshell deployment.
Execution: Creation or execution of malicious binaries on the server.
Credential theft: Exfiltration of application credentials and secrets, such as wp-config.php and .env files.
Lateral movement: Attempts to reach adjacent systems where network access and privileges permit.
Disruption: Service disruption or resource exhaustion.

These are the theoretical bounds of RCE impact. They do not mean every outcome is possible in every PHP environment because of these CVEs.

5. PoC Claims and Exploitation Status

Before the patches were disclosed, reports circulated about leaked exploit tooling and technical details under the name “PHP2Shell”. A short exploitation demonstration video was briefly posted and then removed. watchTowr stated that it had reproduced CVE-2026-109618 and confirmed that the vulnerabilities were real. After the release, the official PHP advisories documented successful remote code execution and validated attack paths on specific runtimes.

Three types of evidence must be kept separate:

Publication of PoC code: Publicly available code intended to trigger a vulnerability.
Demonstration of successful exploitation: Reproducible evidence that a payload triggers the bug and achieves the claimed impact.
Real-world attack observations: Credible incident response or telemetry data showing that threat actors are using the vulnerability against production environments.

Status at the time of writing (October 21, 2026, ~15:30 UTC):

Evidence type	Status
Vendor-validated exploitation	Yes. PHP advisories describe validated RCE on mod_php (both CVEs) and on PHP-FPM (CVE-2026-109619, session upload progress path).
Public PoC code	Repositories claiming to contain PoC code have appeared on GitHub. None has been independently verified. Tenable has also warned that unverified exploit code is sometimes laced with malware.
In-the-wild exploitation	Early reports, not yet broadly confirmed. Cloudflare stated it is seeing early attacks and has deployed WAF rules for known vectors. Huntress and watchTowr had not observed exploitation in their telemetry as of their latest updates. Patchstack’s claims of active incidents had not been backed by published evidence.
CISA KEV	Not listed at the time of writing.

The existence of a PoC repository does not prove that RCE is achievable in every environment. Some scripts only reach a specific error path, and others may be broken or malicious. The official advisories confirm exploitation for specific attack paths, but that does not mean every public PoC is reliable or that every PHP installation is exploitable out of the box. Exploit reliability depends on the PHP build, the loaded extensions, the frontend, and the allocator layout.

Claims of active exploitation must likewise be judged by their source, timeline and supporting evidence. Seeing scan attempts in one organization does not mean every PHP system is equally targeted. Conversely, finding no exploitation in a given environment does not prove that environment is secure.

PoC code must never be run against production environments. If analysis is needed, it must be done in isolated, controlled lab environments.

6. Patching and Remediation Process

On October 21, 2026, the PHP development team released the following security versions, which fix both vulnerabilities:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

According to PHP, updating is the only complete fix. Interim mitigations reduce exposure but do not make an installation safe. PHP 8.2 reaches end of life on December 31, 2026.

6.1. Distribution packages and backported fixes

Linux distributions and LTS vendors received the patches in advance. Many distributions backport fixes without changing the upstream version string, so the visible version alone (php -v) cannot be used to judge whether a system is patched. Always check the full package version and the vendor’s security bulletin.

Distribution	Fixed package (example)	Notes
Ubuntu 24.04 LTS	`8.3.6-0ubuntu0.24.04.13`	USN-8948-1. The version string stays 8.3.6.
Ubuntu 22.04 LTS	`8.1.2-1ubuntu2.28`	USN-8948-1. PHP 8.1 is EOL upstream but patched by Canonical.
Ubuntu 26.04 LTS	`8.5.4-0ubuntu1.5`	USN-8948-1
Debian, RHEL and derivatives	Check DSA/DLA and RHSA	Backported fixes, version strings may not change

On Ubuntu and Debian, the package changelog (/usr/share/doc/<package>/changelog.Debian.gz) can be searched for the CVE identifiers to confirm that the fix is installed.

Mirror lag: Some hosting providers’ local package mirrors can lag behind the official security archive by hours. If the vendor bulletin lists a fixed version that apt/dnf does not yet offer, configure the vendor’s primary security repository directly (for example security.ubuntu.com for Ubuntu) instead of switching to a third-party repository.

Third-party repositories: The volunteer-maintained rpms.remirepo.net repository did not have updates on release day. PHP advised its users to switch to distribution packages or build from source.

6.2. End-of-life branches

PHP 8.1 and older branches no longer receive regular security support. The PHP security team published minimal source backports on the following branches for users who build from source or have no LTS vendor:

PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619

Operating system distributions and LTS vendors may ship their own patched packages for these branches. Decisions about legacy systems must not rely on version numbers alone. Check the vendor’s security advisories directly, and plan a migration to a supported branch.

6.3. Recommended remediation workflow

Checking the version reported by the command-line interface (php -v) is not enough. The CLI binary and the runtime that serves web requests (PHP-FPM, the Apache module libapache2-mod-php/mod_php, or another SAPI) are often separate packages with separate configuration files. You must verify that the SAPI actually serving traffic runs the patched binaries.

Inventory: Find all PHP installations across production, staging, test and container environments, including PHP bundled with control panels and vendor appliances.
Identify the source: Determine whether each installation uses official PHP builds, operating system packages, or a hosting vendor’s distribution.
Check vendor bulletins: Confirm whether the fix has been backported into the specific distribution packages.
Update: Apply updates in a controlled but expedited, phased manner, starting with internet-facing systems.
Restart fully: Stop and start PHP-FPM, the Apache service when using mod_php, or the corresponding worker processes. A full restart is recommended over a graceful reload, so that no worker keeps running the old binary. For containers, rebuild images from patched base images and redeploy them.
Validate: Confirm the runtime version of the serving SAPI, for example with the full package version or a temporary phpinfo() page that is removed afterward, and check core application functionality.
Review: Check logs and identify any legacy or overlooked systems.
Record: Update the asset inventory with the current patch status.

7. Temporary Mitigations

If patches cannot be applied immediately, configuration changes and network controls can reduce exposure. These measures do not provide complete protection and are not a substitute for the official patches. PHP states that no complete, generic configuration-based mitigation exists.

The official interim configuration from the PHP security announcement:

; php.ini or FPM pool / Apache config, applied before request parsing
memory_limit = -1                    ; set via php_admin_value so apps can't override
post_max_size = 8M                   ; 32M if file uploads are required
session.upload_progress.enabled = 0  ; restart all workers afterwards
fatal_error_backtraces = 0           ; PHP 8.5 only; restart all workers afterwards

All of these must be applied at the administrative level, such as php.ini, php_admin_value/php_admin_flag in FPM pools or the Apache configuration. All workers must then be restarted. Application-level mechanisms such as ini_set(), and per-directory overrides, should not be relied on.

7.1. Mitigations for CVE-2026-109618

memory_limit = -1 is the main configuration workaround. It removes the predictable per-request memory-limit exhaustion that the validated attack path relies on. It is not complete, because system-level allocation failures (for example from mmap()) can still reach the vulnerable longjmp() path. Requirements:

Enforcement: It must be set and enforced administratively (php_admin_value). No pool, directory or application setting may restore a finite limit.
Restart: All workers must be restarted afterward.
Availability: It removes the per-request memory cap, so it must be paired with a container or cgroup memory limit (for example memory.max) that preserves service availability. Evaluate it against available hardware before rolling it out.

Warning: PHP explicitly advises against using RLIMIT_AS or RLIMIT_DATA process limits as the boundary. They make mmap() fail when reached and so trigger the very allocation-failure path they are meant to defend against.

Additional hardening (reduces OOM and DoS risk but does not replace updating):

Request size: Keep post_max_size conservative (8M, or 32M where uploads are required), and keep upload_max_filesize consistent with it.
Frontend body limits: Enforce the decoded request body size at the frontend, for example LimitRequestBody in Apache, client_max_body_size in nginx, or WAF limits.
Multipart bounds: Limit the number of multipart parts, the headers per part, and the number of uploads at the frontend or WAF.
Input structure: Reduce max_input_nesting_level and bound the number of input variables (max_input_vars).
Block multipart where unused: If an application does not use multipart forms, block multipart/form-datarequests at the frontend. Otherwise restrict them to the specific upload endpoints and trusted sources.

7.2. Mitigations for CVE-2026-109619

To remove the specific validated producer and consumer paths on unpatched systems, the official guidance recommends:

session.upload_progress.enabled = 0: Removes the validated session upload progress consumer path (mod_php and FPM). PHP recommends keeping this disabled even after patching if the feature is not needed. Few applications use it, and WordPress core does not.
fatal_error_backtraces = 0 (PHP 8.5 only): Removes the confirmed RCE producer used in the mod_php demonstration.
Remove pre-initialization diagnostics: Audit .htaccess files, Apache php_value/php_flag directives, and any PHP_VALUE/PHP_ADMIN_VALUE FastCGI parameters for invalid or deprecated INI settings that produce warnings or deprecations.
Eliminate attacker-reachable fatal errors and timeouts where possible.
Worker recycling: Consider pm.max_requests = 1 for PHP-FPM if performance allows, so that a worker never serves a second request with stale state.
Audit in isolation: In an isolated environment, enable log_errors, set a working error_log, and use error_reporting = E_ALL to find warnings and fatal errors. Clean logs do not prove safety.

These controls cover only specific vectors. They do not mitigate every INI diagnostic path, other global state, other error-handling paths, or extension-specific vectors.

7.3. Network-level controls

Isolation: CERT-EU and the UK NCSC recommend isolating or taking offline internet-facing PHP applications that cannot be patched promptly.
Edge WAF rules: Cloudflare has deployed WAF rules for known exploit vectors. These only protect traffic that actually passes through the WAF and should be treated as a stopgap.
Origin exposure: Restrict origin servers to accept HTTP(S) traffic only from the CDN or WAF provider’s IP ranges. Otherwise an attacker can bypass edge controls by connecting to the origin directly.

The permanent solution for both CVEs remains upgrading to the patched PHP versions or vendor packages.

8. Blue Team: Detection and Threat Hunting

HTTP access logs alone are not enough to detect exploitation of these vulnerabilities. Access logs must be correlated with PHP error logs, web server error logs, process behavior telemetry, file system changes, and network activity.

8.1. Web Server and PHP Logs

Investigate the following:

Multipart anomalies: Anomalous multipart/form-data POST requests, especially to endpoints that do not normally accept uploads. Look for unusually large part or header counts, many empty file fields, deeply nested field names, missing or inconsistent Content-Length, and bodies containing a PHP_SESSION_UPLOAD_PROGRESS field.
Memory exhaustion bursts: Bursts of Allowed memory size of ... bytes exhausted fatal errors, particularly during request startup or POST parsing.
Worker crashes: Unexpected worker terminations or segmentation faults. In Apache this appears as child pid ... exit signal Segmentation fault (11). In PHP-FPM it appears as child ... exited on signal 11 (SIGSEGV).
Repeated timeouts: Repeated max_execution_time or request_terminate_timeout events from the same sources.
Pre-startup diagnostics: Warning, deprecation or other configuration-related messages generated before normal request initialization.
Behavior shifts: Application errors or sudden changes in service behavior immediately after suspicious requests.

None of these indicators proves exploitation on its own. Legitimate file uploads and traffic spikes can produce similar patterns, so correlate them with the timeline and other telemetry.

8.2. Process Behavior Telemetry

Query EDR and process monitoring systems for PHP worker processes that spawn unexpected child processes. Shells, system binaries (sh, bash, nc, wget, curl) and script interpreters (python, perl) started directly by PHP-FPM, php-cgi, Apache or other web server workers require immediate triage. Command lines containing reverse-shell patterns (such as /dev/tcp/, mkfifo) or reconnaissance commands (id, whoami, uname -a) are high-signal.

Some legitimate PHP applications run external system commands, so normal application behavior must be taken into account. Process trees, command-line arguments, user contexts, timestamps, and the corresponding HTTP requests must be evaluated together.

8.3. File System and Network Telemetry

Key forensic artifacts to inspect during incident response:

Web root changes: Unexpected PHP scripts or unauthorized modifications in the web root, including .php files in upload directories such as wp-content/uploads/.
Temporary files: Suspicious files in temporary or upload staging directories.
Outbound connections: Network connections initiated directly from PHP worker processes.
Persistence: New cron jobs, scheduled tasks or unauthorized administrative accounts, including CMS administrator accounts.
Configuration changes: Unexplained modifications to application configuration files, .htaccess files, and file permissions.

At the time of writing, no authoritative, CVE-specific indicators of compromise (IOCs) such as attacker IP addresses, domains or file hashes had been published. Payloads can vary widely, so broad behavioral indicators should not be presented as CVE-specific IOCs unless verified incident reports or trusted threat intelligence support them.

8.4. Incident Response Steps

If successful exploitation is suspected:

Isolate the affected host from the network immediately if active intrusion is observed.
Preserve web server, PHP-FPM, EDR, and system audit logs.
Investigate suspicious child processes and file system modifications.
Assess whether application credentials, database secrets or API tokens stored on the host may have been exposed.
Rotate and revoke potentially exposed credentials from a separate, clean environment.
Rebuild on a clean, patched build and verify application integrity.

Applying the patch does not remove artifacts left by an earlier successful compromise, such as webshells, persistence mechanisms or stolen credentials. A suspected security event must not be closed simply by upgrading. A full incident response triage must be performed.

9. Conclusion

CVE-2026-109618 and CVE-2026-109619 are critical vulnerabilities in the PHP core. Under specific runtime conditions they allow unauthenticated remote code execution before any application code runs. The CVSS v4.0 score of 9.2, validated exploitation on Apache mod_php (and on PHP-FPM for CVE-2026-109619), the leak before disclosure, and early reports of attacks all make rapid, systematic remediation essential.

Technically, CVE-2026-109618 comes from control-flow disruption and partially initialized request memory during OOM handling. CVE-2026-109619 comes from stale global state that persists across request boundaries in the same worker. The two issues reinforce each other in practice, because attacker-induced memory exhaustion is a trigger for the first and a demonstrated producer for the second.

For organizations, the immediate priority is to inventory every PHP installation, deploy the appropriate upstream or vendor security updates, and verify that the SAPI actually serving web traffic runs patched binaries. Distribution backports usually keep the upstream version string, so verification must be based on package versions and vendor bulletins. Temporary configuration changes and network controls reduce exposure, but they must not be treated as permanent fixes. Disabling session.upload_progress is still worthwhile after patching if the feature is not used.

For Blue Teams, knowing that the vulnerabilities exist is not enough. Correlating request logs with web server crash signals, process behavior, file system integrity, and network telemetry is essential for detecting exploitation attempts and limiting their impact.

PHP2Shell is a critical security event that requires coordinated patch management and proactive threat hunting. Security decisions must be based on verified technical findings and current vendor advisories, and PoC claims, active exploitation reports, and IOCs must each be kept separate according to the evidence behind them.

Running PHP in production and unsure whether you are exposed? Our External Penetration Testing identifies the exact PHP runtime, SAPI and configuration serving your requests and the attack paths that reach them, our Managed Security Services hunt for the post-exploitation behavior described above, and our Incident Response Tabletop Exercisesprepare your team for a fast-moving disclosure like this one. Talk to our team.

References

PHP: Official security announcement and patched versions. https://www.php.net/archive/2026.php
PHP: CVE-2026-109618, RCE via OOM corruption (GHSA-w8hw-w9fx-j79w). https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
PHP: CVE-2026-109619, RCE via stale global state (GHSA-6wmf-4rv5-p3rp). https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
PHP Foundation: PHP 8.3.36 Released. https://discourse.thephp.foundation/t/php-php-8-3-36-released/6279
Ubuntu: USN-8948-1, PHP vulnerabilities. https://ubuntu.com/security/notices/USN-8948-1
CERT-EU: Security Advisory 2026-018, Critical Vulnerabilities in PHP. https://cert.europa.eu/publications/security-advisories/2026-018/
Tenable: php2shell (CVE-2026-109618, CVE-2026-109619) FAQ. https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote
Help Net Security: PHP2Shell, critical PHP vulnerabilities patched. https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
Huntress: Rapid Response, php2shell. https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
Sansec: PHP2Shell Research. https://sansec.io/research/php2shell

Note: This article is based on the PHP security advisories published on October 21, 2026 and on public reporting available as of approximately 15:30 UTC that day. Distribution packages, exploitation reports and IOCs are changing rapidly. Verify the current status in the respective vendor sources before publication.

Scroll to top