PHP2Shell: CVE-2026-109618 and CVE-2026-109619 Risks, Fixes and Response

Reporting cutoff: October 21, 2026. This analysis uses public PHP advisories and researcher disclosures, not independent exploitation or victim forensics. Guidance reflects the sources available at this cutoff.

PHP has released emergency security updates for two critical vulnerabilities that can expose process memory or allow unauthenticated remote code execution. Known collectively as PHP2Shell, the issues are tracked as CVE-2026-109618 and CVE-2026-109619. They affect the runtime underneath websites, rather than a particular WordPress plugin, framework or application feature. [1, 4]

The immediate priority is to deploy PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a vendor package explicitly containing both fixes, and replace the running processes. Updating a CMS alone does not repair the PHP engine. PHP's security team states that configuration changes can reduce exposure to particular paths, but only the security update provides a complete solution. [1]

The situation is serious without treating every deployment as identical. Apache with mod_php has a demonstrated attack path before application code runs. PHP-FPM is also within scope, with important differences in how individual paths become reachable. A vulnerable runtime is not proof of compromise, and a researcher demonstration is not proof of widespread malicious exploitation.

What PHP2Shell Covers

PHP2Shell is an umbrella name for related memory-safety failures, not a single endpoint or a mandatory two-step exploit chain. The two CVEs describe failure classes with multiple variants and different prerequisites. Research demonstrations combine primitives in some cases, but defenders should not assume both flaws must always be chained for an impact. [2, 3, 4]

The PHP Group assigns CVSS v4.0 scores of 9.2, Critical, to both vulnerabilities. The published vectors describe network access, no required privileges and no user interaction, but also high attack complexity and additional attack requirements. These qualifications describe exploitation conditions; they are not a reason to defer remediation. The scores are PHP Group assessments, not independent NIST scoring. [6, 7]

Potential impact includes execution with the web worker's privileges and exposure of sensitive memory. This is not automatically operating-system root access. The eventual reach depends on service-account permissions, accessible secrets, filesystem access and network connectivity. Even without elevated privileges, an application worker may have substantial access to databases and internal services.

CVE-2026-109618: When Memory Exhaustion Breaks Cleanup

The first vulnerability concerns PHP's handling of out-of-memory errors. Historically, PHP could leave the current execution context abruptly through longjmp(). In affected contexts, an allocation failure could interrupt work while internal request data was only partly initialized. Cleanup could subsequently treat that invalid data as usable. [2]

That transforms a condition normally associated with a failed request into a memory-corruption risk. The allocation that fails does not necessarily belong to the damaged object. An apparently unrelated allocation can interrupt the process at the wrong point.

The advisory identifies multipart request processing as one way to create memory pressure, alongside application-specific allocation behavior. Raw request size is not a reliable measure of internal memory use: parsed fields and associated bookkeeping can consume more memory than their representation on the network. Basic upload-size checks alone therefore do not establish safety. [2]

For Apache mod_php, the critical distinction is cleanup after failed request startup. PHP may encounter the problem while automatically processing request input, before the website's own code executes. The advisory reports complete unauthenticated RCE over HTTP against mod_php with default PHP input and memory limits and ordinary multiworker prefork configurations. [2]

The fix changes the failure-handling model. The advisory describes a delayed, graceful soft out-of-memory condition at a safe execution point, with immediate process termination at a second, higher threshold. This avoids passing invalid intermediate state into ordinary cleanup while retaining the ability to limit memory consumption. Teams should test the operational consequences of worker termination as part of rollout.

CVE-2026-109619: Request Memory That Outlives Its Request

The second vulnerability concerns state retained by a worker across requests. PHP maintains internal error, session, object and extension state that can temporarily refer to memory belonging to one request. Those references must be cleared before the request's memory is released. [3]

A fatal interruption can prevent the matching reset. In other cases, a diagnostic emitted late in shutdown can recreate state after it was already cleared. A later operation may then use the stale reference before normal initialization replaces it. The result can be use-after-free, memory disclosure or code execution.

For the confirmed request-lifecycle cases in the PHP advisory, an earlier request leaves the stale state and a later request handled by the same worker consumes it. More workers or routine recycling can reduce success per attempt, but do not remove the underlying defect. This same-worker condition should not be generalized to every variant: Wiz separately describes an OPcache shared-state issue involving interaction between workers. [3, 4]

Two confirmed paths receive particular attention in the vendor advisory. One involves PHP 8.5 fatal-error backtraces followed by an early diagnostic. Another involves session upload-progress processing before normal initialization. Upload progress can activate internal session handling even when application code never calls session_start(). [3]

These are runtime lifecycle problems, not simply a developer forgetting to validate a form. Fixing application errors can break particular attack paths, but cannot replace the engine-level state-reset patch.

Exposure Depends on How PHP Serves Requests

PHP's public notice places installations serving web requests within scope, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. It identifies mod_php as the highest demonstrated risk. That is a prioritization statement, not an exemption for the other deployment models. [1]

Apache with mod_php: The advisories describe confirmed RCE and an application-independent startup path. Authentication performed inside the PHP application may run too late to protect that path. An upstream access restriction that rejects requests before PHP is invoked is a different control.

PHP-FPM: FPM terminates a child if request startup fails, preventing some startup-failure sequences from carrying on in that process. However, the stale-state advisory describes validated session-lifecycle RCE after successful startup, dependent on a suitable application operation. It works with a normal dynamic pool. [3]

The publications are not fully aligned in their per-CVE account of FPM validation. The OOM technical advisory says its source analysis supports susceptibility but does not report a complete FPM exploit for that path; the PHP Foundation's summary reports OOM-related FPM RCE through application-level paths. The practical conclusion is unchanged: FPM is not a safe exemption, but the sources do not justify claiming every application-independent mod_php sequence works unchanged on FPM. [2, 3, 5]

FrankenPHP and LiteSpeed: The OOM advisory discusses likely or conditional susceptibility based on source analysis, rather than equally validated exploits for every environment. The stale-state advisory also distinguishes confirmed consumers from candidates. Include these runtimes in the update program without overstating demonstration coverage. [1, 2, 3]

In all cases, assess the actual service, PHP build, loaded extensions, frontend configuration and reachable application operations. A successful test against one image is evidence of impact, not a universal exploitability result for every installation.

Confirmed Demonstrations Are Not Victim Counts

Wiz reports pre-authentication code execution against WordPress, Drupal and Joomla deployments using their latest container images at the time of testing. Those applications were representative targets; the flaws are in PHP itself. The report also describes unauthenticated disclosure of process memory without first obtaining code execution. [4]

Memory disclosure matters independently. A defender looking only for shell processes or webshell files could miss an incident that exposed passwords, tokens or API keys from memory. Whether particular secrets were present and actually disclosed remains a question for the affected environment, not something a vulnerability announcement establishes.

Wiz's references to PHP powering approximately 70% of websites describe ecosystem reach. They should not be repeated as a measured percentage of exploitable or compromised sites. Version, patch status and configuration still matter, and no victim count follows from that market-share figure.

The PHP Foundation reports that, at release and public disclosure, the security team had not identified functional exploits among the public PoCs it inspected after the disclosure leak. That narrow observation is not a claim that private researcher exploits did not exist, nor proof that attackers had never exploited the flaws. The sources reviewed for this article do not establish a confirmed in-the-wild campaign. Recheck official updates as the situation develops. [5]

Fixed Releases and Legacy Systems

For upstream releases, the supported-branch remediation baseline is clear. Apply a current trusted security release containing both fixes, using the following first-fixed versions as the minimum for each branch. [1, 6, 7]

• PHP 8.2: Releases earlier than 8.2.35 are affected. First fixed release: 8.2.35.
• PHP 8.3: Releases earlier than 8.3.36 are affected. First fixed release: 8.3.36.
• PHP 8.4: Releases earlier than 8.4.27 are affected. First fixed release: 8.4.27.
• PHP 8.5: Releases earlier than 8.5.12 are affected. First fixed release: 8.5.12.

For Linux distribution or commercial LTS packages, check the vendor's security notice and exact package revision. A vendor may backport the fixes while retaining an older upstream version string. Conversely, an apparently familiar version string is not evidence that the required backport exists.

PHP 8.1 and older no longer receive routine upstream updates. PHP has provided minimal source backports for 7.4, 8.0 and 8.1 for this emergency, but those do not restore general support for obsolete branches. Use a supported distribution or LTS fix where available, or migrate to a supported PHP branch. Wiz reports affected code dating back to PHP 5.4; absence from the supported-branch table should not be interpreted as safety for older installations. [1, 4]

PHP also included the fixes in 8.6.0 RC4 and urged users of earlier test builds to update. That release candidate is not a recommended production migration target. PHP 8.2 reaches upstream end of life on December 31, 2026, so patching it now should accompany a planned supported-version upgrade. [1]

Patch the Runtime That Actually Handles Traffic

A useful deployment check must reach beyond a package-management success message. Inventory every runtime serving requests, including virtual hosts, separate FPM pools, bundled application stacks, container replicas, standby nodes and autoscaling images.

Updating a command-line PHP binary does not prove that Apache's loaded module or an FPM service uses the same version. Similarly, a refreshed image tag does not prove running containers were replaced. Record the actual service package or image digest and verify it against the relevant fixed-release or vendor-backport record.

A practical rollout sequence is:

1. Establish ownership and exposure. Identify the PHP runtime behind each service, its deployment mode, package provenance and reachable interfaces. Prioritize internet-facing mod_php, then other exposed PHP services and sensitive internal workloads.
2. Install a complete fix. Update all relevant packages or rebuild images from a trusted patched base. Include bundled runtimes and deployment templates that could recreate an unpatched instance.
3. Replace old processes. Restart the affected Apache or PHP-FPM services and replace long-running workers using the platform's deployment procedure. Confirm that old workers have drained and exited rather than relying solely on a reload command returning successfully.
4. Verify the live service. Confirm the serving runtime and extension compatibility through an authenticated operational check. Do not expose a public phpinfo() page to perform this verification.
5. Exercise normal application flows. Test uploads, sessions, error handling, background processing and health checks. Watch worker churn, memory usage, latency and HTTP errors as patched capacity enters service.

These checks verify deployment and compatibility; they do not require sending an exploit to production. Retain an auditable record that both CVEs are addressed on every serving replica.

Temporary Measures Have Important Trade-Offs

If patching is temporarily blocked, follow PHP's current guidance as an emergency exposure-reduction plan with an owner and an expiry. No configuration combination described here should be recorded as a complete remediation. [1, 2, 3]

Disabling the finite PHP memory limit is not a harmless toggle. The vendor describes administratively enforcing memory_limit=-1 to remove the predictable PHP-limit failure used by certain attacks. Underlying allocation failures can still reach vulnerable behavior. Removing that limit also creates availability risk, so it requires explicit capacity planning and suitable external resource boundaries.

A container or cgroup limit can help constrain resource consumption, but may terminate multiple workers or an entire service depending on isolation. It is not guaranteed to eliminate allocation failures and is not a complete security fix. PHP specifically warns against substituting RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable failure path. Do not blindly apply this workaround across a shared host. [2]

Reduce request-driven memory pressure. Use frontend limits on decoded request size, input complexity and multipart structure, including requests without a usable declared content length. Where the application does not need multipart requests, consider rejecting them before they reach PHP. Align limits with real application requirements and test legitimate workflows.

Disable specific vulnerable features where applicable. PHP recommends administratively setting session.upload_progress.enabled=0 for the confirmed session paths, and fatal_error_backtraces=0 on PHP 8.5 for the confirmed backtrace path. Restart every affected worker. Apply settings before request parsing through appropriate startup or server configuration; application ini_set() calls or FPM .user.ini are too late for the cited early session path. [1, 3]

Do not confuse hiding errors with fixing error handling. Remove invalid or deprecated per-request settings that generate early diagnostics, and investigate attacker-reachable fatal errors and timeouts. Disabling display_errors, changing error_reporting or suppressing messages with @ does not prevent the internal stale-state access described in the advisory. [3]

WAF or provider rules may reduce exposure to known request patterns, but verify their coverage and whether traffic can bypass them to reach the origin. Such rules do not repair memory management or account for every variant. After patching, review emergency settings and restore appropriate resource controls under change management.

Detect Exposure and Investigate Suspected Abuse

Start with vulnerable-runtime inventory and process replacement status. Traffic and host signals can prioritize investigation, but a quiet log is not a substitute for patch verification.

Wiz highlights unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed session response cookies, and unexplained worker churn. PHP's advisory additionally recommends reviewing early initialization diagnostics, shutdown warnings, fatal errors and execution timeouts. None of these signals alone proves exploitation. [3, 4]

Correlate reverse-proxy, web-server, PHP, container and endpoint telemetry. Where available, associate requests with worker lifetimes to investigate relevant cross-request behavior. Investigate unexpected child processes, file changes, outbound connections and suspicious subsequent use of application credentials. Avoid indiscriminately recording response cookies or memory contents into broadly accessible logs, since they may contain sensitive data.

If evidence suggests exploitation, isolate the affected workload through established incident procedures and preserve relevant logs, images and volatile evidence before destructive cleanup where feasible. Evaluate both code-execution activity and possible memory disclosure. Patch or rebuild the runtime, investigate persistence, and rotate or revoke potentially exposed credentials from a clean environment after containment.

A PHP update prevents the fixed vulnerability paths; it does not remove an attacker-created account, restore altered application files or invalidate a stolen token. Conversely, a vulnerable version alone does not justify stating that all secrets were stolen. Scope the response to exposure, evidence and the access available to the service.

Research, AI and the Maintenance Lesson

Wiz credits AI-assisted research with making complex discovery, exploit adaptation and patch validation more practical. The PHP Foundation provides complementary history: signs of the OOM problem emerged during work related to a 2024 audit, and concrete reports from Calif, OpenAI and Wiz in 2026 clarified its full impact. This was a coordinated engineering effort, not simply an autonomous tool producing a finished fix. [4, 5]

The Foundation also acknowledges that difficult compatibility trade-offs, decision-making and limited specialist resources delayed earlier progress. For organizations depending on PHP, the lesson extends beyond this release: maintain runtime ownership, supported-version plans and a tested path for urgent updates to shared infrastructure.

For today's response, the conclusion is straightforward. Patch every affected PHP runtime, replace the running workers, and verify the serving environment. Treat temporary mitigations as partial, and investigate memory disclosure as seriously as visible command execution. PHP2Shell's broad reach calls for disciplined remediation, not unsupported claims that every PHP website is already compromised.

Sources

1. PHP: Critical Remote Code Execution Vulnerabilities and October 21 Security Releases - Official upgrade targets, deployment scope, legacy-version guidance and temporary mitigations.
2. PHP Security Advisory GHSA-w8hw-w9fx-j79w: RCE via OOM Corruption - CVE-2026-109618 mechanism, validation scope, patch behavior and mitigation limitations.
3. PHP Security Advisory GHSA-6wmf-4rv5-p3rp: RCE via Stale Global State - CVE-2026-109619 lifecycle conditions, confirmed and conditional paths, and response guidance.
4. Wiz Research: PHP2Shell - October 21, 2026. Research demonstrations, memory disclosure, deployment caveats and detection signals.
5. The PHP Foundation: Today's PHP Security Release, and How We're Strengthening PHP Security - October 21, 2026. Discovery history, coordination and disclosure status.
6. CVE Program: CVE-2026-109618 - PHP Group description, supported-branch version ranges and CVSS v4.0 assessment.
7. CVE Program: CVE-2026-109619 - PHP Group description, supported-branch version ranges and CVSS v4.0 assessment.