PHP2Shell: Critical PHP RCE Flaws

Affected and fixed PHP versions

The upstream security releases became available on 21 October 2026. For the supported branches, the minimum fixed versions are:

Source: PHP's security release notice. Install a later security release if your vendor recommends it.

A practical patch and verification checklist

The following is ProCheckUp's recommended operating checklist. Record the evidence in your emergency change or incident ticket, rather than closing the task when an installation command succeeds.

1. Map each service to its runtime. Record its owner, hostname, backend, PHP integration and package or image. Include FPM pools, control panels, webmail, exposed staging systems and embedded PHP. Suppliers may be needed to identify bundled runtimes. Joint European guidance.
2. Match the fix to the running installation. Check the complete package revision and vendor notice for both CVEs. php -v identifies the CLI executable; the website may use another binary or FPM pool. Inspect the actual serving process and its configuration through authenticated administration.
3. Update the deployment source as well as the host. Rebuild and replace containers, and update base images, templates and rollback versions. Cover every replica and region so a later rollout cannot restore vulnerable PHP. Cloud.gov's container guidance.
4. Replace old workers and prove it. Follow the vendor's restart procedure. Record process replacement times and verify each backend's loaded runtime. Automatic package updates alone do not prove the new code is running. Ubuntu's restart requirement.
5. Check the customer journey and failure handling. Test login, sessions, uploads, scheduled jobs and important transactions. Check worker exits and recovery after the update; exercise memory-pressure behaviour in a private test environment. Do not publish an unrestricted phpinfo() page or run an untrusted exploit on production.
6. Review exposure and record exceptions. Preserve relevant logs, investigate suspicious activity and give every unpatched dependency an owner and deadline. Close the task only when runtime evidence, worker replacement, service tests and the exposure review are documented.

Temporary controls do not replace the update

If a verified fix cannot be applied promptly, isolate the exposed service while the owner and supplier resolve it. ENISA explicitly recommends considering removal of exposed applications from public networks where immediate remediation is not feasible. ENISA guidance.

PHP documents measures that reduce particular attack paths: disabling session upload progress in startup configuration, disabling fatal_error_backtraces on PHP 8.5, and restricting request size and multipart complexity before traffic reaches PHP. Restart workers after configuration changes; application-level ini_set() is too late for the relevant early processing. These are incomplete protections. PHP's temporary measures.

Do not copy memory_limit=-1 without understanding the trade-off. Calif notes that removing PHP's cap increases memory-exhaustion risk. PHP's OOM advisory additionally warns that underlying allocation failure remains possible and that RLIMIT_AS or RLIMIT_DATA can trigger the vulnerable failure path. Any temporary memory strategy needs an administrator-designed availability boundary and capacity monitoring. Calif's warning; PHP's detailed limitations.

Keep applicable WAF protections enabled, verify their coverage and restrict direct origin access. A filter only covers traffic that passes through it, and payload changes can challenge detection. Cloudflare itself recommends patching despite its protections. Cloudflare's defence-in-depth guidance.

Why a runtime flaw matters

PHP executes the application behind many websites. A flaw in that underlying engine can remain reachable even when the website's own code is well maintained. Updating WordPress, Drupal, Joomla or an e-commerce plugin alone does not replace the vulnerable PHP installation. Where hosting is managed, the hosting provider must confirm that the runtime has been fixed. Cloudflare explains the distinction.

Successful exploitation can expose application data or give an attacker the ability to run code with the PHP worker's permissions. This is not automatically root or administrator access, but a worker may already be able to read database credentials, application secrets or customer records. Wiz's research also describes sensitive process-memory disclosure, including tokens and API keys, without requiring a conventional shell. Wiz's research and impact assessment.

For an organisation, the consequence can be a disrupted service, a data investigation and a wider credential compromise. The business question is therefore broader than “is our website online?” It is whether every reachable runtime is fixed and whether the service remains trustworthy.

Two flaws, different failure points

PHP's advisories identify CVE-2026-109618 as out-of-memory corruption and CVE-2026-109619 as stale global state. PHP rates both CVSS v4.0 9.2 — critical. The rating describes severity; it does not mean every integration is equally easy to exploit. The advisories document different conditions for each flaw.

CVE-2026-109618
Out-of-memory corruption

What goes wrong. A memory-allocation failure interrupts work while internal request data is only partly initialised. Cleanup can then use that invalid data.

Why it matters. Specially crafted input can trigger memory pressure within apparently acceptable request limits. PHP confirms remote code execution against mod_php.

CVE-2026-109619
Stale global state

What goes wrong. A worker retains references to memory belonging to a finished request. A later request uses those references after the memory has been freed.

Why it matters. A matching producer and consumer must occur on the same worker. Confirmed consequences include memory disclosure and remote code execution.

Technical sources: PHP's OOM advisory and PHP's stale-state advisory.

The OOM patch changes error handling: PHP defers a soft out-of-memory failure to a safe execution point, with an immediate process exit at a higher hard limit. Include memory-pressure behaviour and worker recovery in deployment checks. The stale-state fix clears affected state before later requests can consume it.

Which deployments are at risk?

PHP's release notice tells operators to assess all PHP installations serving web requests, including mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. It identifies mod_php as the highest risk. That broad patching scope should not be confused with identical exploit evidence for every integration. PHP's security release notice.

• Apache with mod_php: PHP confirms OOM exploitation before application code executes. Application login checks therefore cannot be assumed to protect the affected request-processing path.
• PHP-FPM: the OOM advisory describes source-based susceptibility without a complete FPM exploit demonstrated for that CVE. The stale-state advisory separately confirms an FPM session-lifecycle RCE route requiring a suitable operation during application execution and a later request on the same worker.
• Other integrations: PHP's analysis identifies likely or conditional routes in FrankenPHP and LSAPI. Treat these as patch priorities; do not translate “not demonstrated” into “not affected”.

Session upload progress belongs under the stale-state advisory. It is enabled by default and can operate without the application calling session_start(). Turning it off removes specific demonstrated paths, but it does not fix the entire vulnerability class. PHP's confirmed cases and conditions.

What the exploitation evidence shows

Demonstrated capability: researchers have established working exploitation, including remote code execution and memory disclosure. Calif records sharing an RCE proof of concept with PHP on 14 August, with confirmation the next day. This validates the risk; it does not establish that a particular organisation was breached. Calif's disclosure timeline.

Observed attempts: Cloudflare reports attack traffic and payload changes intended to evade its protections. Its account says protection for customers using its free or paid WAF began at 03:02 UTC on 21 October. Neither a WAF match nor a blocked request, by itself, proves successful compromise. Cloudflare's observations.

Public exploit claims: the PHP Foundation said it had not found a functioning public exploit among those it inspected at release time. That statement has a time limit; it is not a current guarantee that effective exploits are unavailable. Assess your own hosts and logs rather than waiting for a public victim count. PHP Foundation's release account.

Patch urgency does not depend on a victim count. The UK NCSC advises identifying PHP systems, monitoring exposed services and applying updates. Where rapid remediation is not feasible, it says organisations should consider taking the system offline. NCSC alert.

What to look for after exposure

Correlate reverse-proxy, web-server, PHP, endpoint and identity logs. Elastic's detection research highlights unexpected shells or interpreters started by web workers, outbound tool downloads, new webshell files and persistence changes. These are investigative leads rather than PHP2Shell-specific proof. Elastic's detection coverage.

Include repeated PHP startup or cleanup warnings, fatal errors, execution-time failures and unexpected worker exits in the review. These can reveal risky application paths or service faults, but they are not unique indicators of an attack. PHP warns that missing log entries do not establish safety: a path may not have been exercised, the relevant severity may have been excluded, or failure may precede logging. Preserve evidence before rotation or rebuilding. PHP's logging and configuration audit guidance.

• Investigate unusual worker behaviour together with request timestamps, process ancestry and network destinations.
• Review unexplained PHP file changes, scheduled tasks and new accounts against approved deployments.
• Consider secrets accessible to the application account, including database credentials and cloud identities.
• Do not treat an absence of spawned shells as proof of safety: memory disclosure or activity inside PHP may produce a different footprint.

ProCheckUp recommends isolating a suspected host, preserving evidence and involving incident responders before rebuilding. If compromise is confirmed, remove persistence, restore from a trustworthy source and rotate exposed secrets through a controlled recovery plan. Memory disclosure may expose credentials without leaving a webshell, so scope the review to what the PHP worker could access, including database, API and cloud credentials. Patching closes the vulnerability; investigation establishes whether an attacker already used it.

What the discovery and disclosure teach us

The PHP Foundation connects the OOM issue to work following a 2024 security audit. It describes difficult compatibility and availability trade-offs that delayed a fix. Reports from Calif and OpenAI on 11 August 2026, followed by additional research, established the impact and drove remediation. After CVE identifiers leaked on 20 October, PHP moved the coordinated release forward by a day. PHP Foundation's account.

Wiz describes AI assistance in developing and adapting complex exploit chains. Calif emphasises the continued importance of researcher expertise and knowledge of earlier vulnerability classes. The useful lesson is practical: assumptions that a bug is too difficult to exploit can change, while finding and validating a safe fix still takes experienced maintainers. Wiz research; Calif's methodology.

Organisations can prepare by maintaining a runtime inventory, assigning patch ownership and rehearsing emergency upgrades. Ask suppliers for evidence of a running fix, and give security teams a clear escalation route when ordinary maintenance windows are too slow.

Sources and further guidance

Primary technical and operational sources checked on 22 October 2026. Advisories may change as research and vendor coverage develop.