PHP2Shell: Patch Two Critical PHP Remote Code Execution Flaws

PHP has released emergency fixes for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities that can allow unauthenticated remote code execution. Update affected PHP runtimes to 8.2.35, 8.3.36, 8.4.27, or 8.5.12, or install a vendor package explicitly fixing both CVEs. Configuration changes and WAF rules cannot replace the complete fixes.

What is PHP2Shell?

PHP2Shell is the name being used for two PHP core vulnerabilities. PHP's advisories describe different failure modes:

• CVE-2026-109618: A memory allocation failure can interrupt processing while request data is incomplete. Cleanup can then act on invalid memory, enabling code execution.
• CVE-2026-109619: A worker can retain references to a completed request's freed memory. A later request reaching that worker can use the stale state, enabling memory disclosure or code execution. Session upload progress is one affected path.

A change that interrupts one attack path does not necessarily address the other vulnerability.

What products and versions are affected?

PHP's warning covers installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. The project identifies mod_php as the highest-risk deployment.

For supported branches, the fixed releases are:

• PHP 8.2: Releases earlier than 8.2.35 are affected. Update to 8.2.35.
• PHP 8.3: Releases earlier than 8.3.36 are affected. Update to 8.3.36.
• PHP 8.4: Releases earlier than 8.4.27 are affected. Update to 8.4.27.
• PHP 8.5: Releases earlier than 8.5.12 are affected. Update to 8.5.12.

The OOM advisory and stale-state advisory both list these fixed releases. Distribution backports require checking the vendor package advisory, not just comparing its upstream version string.

PHP 8.1 and older are outside regular upstream support. PHP has nevertheless provided minimal source backports for 7.4, 8.0, and 8.1 for this emergency. Check your distribution or LTS provider for packaged fixes, or move to a supported branch.

How severe is it?

PHP assigns each flaw CVSS v4.0 9.2, Critical, with the vector 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. Authentication and user interaction are not required; exploitation has high complexity and depends on execution conditions. Successful code execution runs with the web worker's privileges.

For CVE-2026-109618, PHP validated remote code execution against mod_php, including a path before application code runs. Its advisory describes FPM as susceptible but does not report a complete FPM exploit for that flaw. For CVE-2026-109619, session lifecycle RCE was validated against both mod_php and FPM.

Treat internet-facing affected deployments as an immediate patching priority. A login page alone should not be your reason to defer a runtime update.

Why should organizations act now?

Cloudflare is already observing early attacks targeting these vulnerabilities, according to BleepingComputer’s October 21 update. Its emergency WAF protections are temporary measures while organizations apply PHP’s fixes.

NSA Cyber also urged organizations using PHP to prepare for an immediate update, recommending taking systems offline if they could not update immediately, until fully mitigated. PHP has since released the patches.

Are patches available?

Yes. PHP announced the emergency releases on October 21, 2026. The release changelog also associates the fixes with both advisories, although its 8.5.12 heading carries an October 22 date. Use the current security announcement and your package vendor's availability to guide deployment.

Include WordPress and Drupal sites, phpMyAdmin installations, and other PHP applications in your inventory. Updating an application, plugin, or module does not establish that the underlying PHP runtime has been patched. Assign an owner to verify the actual runtime behind each deployment, including hosted services and container images.

What should you do right now?

1. Inventory and update exposed runtimes. Start with public websites, administrative tools, APIs, and forgotten staging environments. Record the PHP branch, hosting owner, package source, and update status. Use your external asset inventory to organize the work.
2. Verify deployment completion. Replace or restart affected workers through your normal deployment process. Check the runtime serving web requests, not only the command-line binary. For backports, retain the vendor advisory and installed package revision as evidence.
3. Check every deployment copy. Review load-balanced nodes, alternate container images, rollback images, and autoscaling templates. Otherwise, a later deployment may restore an older runtime.
4. Reduce exposure while a patch is delayed. Restrict access at the proxy or network layer, or temporarily withdraw the affected service where practical. Test that the restriction also covers direct origin access.
5. Investigate suspicious activity. Review unexpected child processes from web workers, new executable files, unusual outbound connections, and changes to application files. These are general compromise indicators, not PHP2Shell-specific signatures. Preserve relevant logs and artifacts before rebuilding a suspicious host.

Keep a simple closure record: affected service, responsible owner, fixed package or image, running-worker verification, and completion time. A successful installation job alone does not show that every serving instance has changed.

Application read-only or maintenance mode is not a substitute for patching: PHP has demonstrated an attack path before application code runs. Restrict access to the affected service or take it offline if necessary while arranging the update.

Does disabling upload progress or adding WAF rules protect you?

Only partially. Setting session.upload_progress.enabled=0 blocks confirmed session lifecycle paths, but it does not cover every stale-state variant. PHP 8.5's fatal_error_backtraces=0 addresses another confirmed path. Apply these settings before request parsing and restart every worker.

The OOM advisory contains separate memory and request-limiting guidance. Review the full instructions with your operations team before changing memory limits. Removing a per-request limit changes availability risk.

Cloudflare issued an emergency managed-rules update. Confirm relevant rules are active and traffic reaches them. Use WAFs and scanning together, and keep patching underway even when a WAF is blocking suspicious requests.

How Halo Security can help

Halo Security customers can filter their Technology list for PHP to find identified PHP assets and prioritize patch verification. Use Technology Scanning as a starting point, then verify each runtime and its installed fix with the service owner.

Do not wait for a vulnerability alert before checking your PHP deployments. Identifying PHP helps prioritize investigation; verify the installed runtime and vendor patch status with the service owner.

FAQ

Close the gap across your exposed PHP services

Give each service an owner and verify the running fix before closing the work. Learn more about organizing remediation through external vulnerability management.

This is a developing situation. Exploitation reports and mitigation guidance may change. Check PHP’s official security advisory for the latest guidance.