PHP2Shell emergency response: two CVSS 9.2 PHP remote-code-execution flaws

What happened

PHP fixed two critical vulnerabilities in the interpreter core that can lead to unauthenticated remote code execution. They are independent of the application framework and affect every SAPI serving requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed.

CVE-2026-109618 abuses an out-of-memory exit while request memory is partially initialized; request shutdown can then treat corrupted state as valid. CVE-2026-109619 is a cross-request use-after-free: a worker-global value can still reference memory owned by an earlier, freed request when the next request is processed.

Affected versions

PHP 8.2 through 8.5 have official fixed releases. PHP 8.1 and older are end-of-life upstream. PHP provided minimal source backports for 7.4, 8.0, and 8.1, but no new official binary releases.

Why application updates are not enough

The attack paths execute during PHP request initialization, parsing, or cleanup before application code runs. Updating WordPress, Drupal, Joomla, Laravel, or a security plugin does not replace a PHP runtime update.

• PHP considers mod_php highest risk: a demonstrated unauthenticated request can trigger exploitation before application code runs.
• PHP-FPM must not be treated as safe. Source analysis supports susceptibility, and the related flaw was demonstrated on both mod_php and FPM.
• Installing a package is not complete remediation. Old PHP-FPM, Apache, IIS, and CLI workers may still execute the old binary.
• Docker requires a new image and a recreated container; docker restart only restarts the old image.

How we scoped the estate

We used a passive scanner to inventory CLI, FPM, CGI, Apache modules, Docker, Windows services, extensions, and relevant INI settings, then verified the runtime behind each real web entry point instead of trusting a single php -v result.

• Inspect PATH, /www/server/php, /usr/local, /opt, FPM pools, Apache modules, IIS FastCGI, the registry, and containers.
• Compare package installation time with worker start time to identify an installed-but-not-running patch.
• Hidden banners, CDNs, and WAFs reduce exposure alerts but do not prove the origin runtime is fixed.
• Appliances, NAS products, control panels, and embedded PHP require separate vendor advisories.

Safe remediation sequence

Updating PHP is the only complete fix. This sequence applies to Linux and Windows Server, including BT panel, IIS, and container deployments.

• Create a full-machine snapshot in the cloud or hypervisor and record PHP versions, SAPIs, extensions, services, and pool configuration.
• Back up the PHP directory, php.ini, FPM/Apache/IIS configuration, and binaries; verify that the rollback script is readable.
• Install the same-branch official release or a distribution package explicitly marked fixed in its CVE advisory.
• For Docker, pull the fixed image and recreate the container. Fully restart FPM, Apache, IIS, and long-running PHP workers after package updates.
• Verify login, upload, payment, queues, caching, and critical APIs, and confirm the actual web SAPI version.
• If the host was internet-facing before remediation, hunt for web shells, unexpected child processes, new scheduled tasks, outbound connections, and credential access.

If you cannot patch immediately

Configuration controls block specific known paths but do not make PHP safe. Patching and a full worker restart remain the only complete remediation.

• CVE-2026-109618: enforce memory_limit=-1 where applications cannot override it, lower post_max_size, and cap decoded body size, parts, headers, and nesting at the proxy. Do not substitute RLIMIT_AS or RLIMIT_DATA.
• CVE-2026-109619: set session.upload_progress.enabled=0 before request initialization and fully restart every worker; on PHP 8.5 also set fatal_error_backtraces=0.
• Do not rely on .user.ini or ini_set() for these controls; they apply too late for some paths.
• A Cloudflare WAF or other edge rule is defense in depth and protects only traffic routed through that edge.

Rollback and tool boundaries

The preferred rollback is always a full-machine snapshot. The server scripts write reports, manifests, and rollback artifacts under /root/php2shell-fullfix/<timestamp>/ on Linux or C:\ProgramData\PHP2ShellFullFix\<timestamp>\ on Windows.

Automatic changes are limited to recognized BT panel PHP installations, a narrow set of Debian official-image PHP containers, and official Windows PHP ZIP installations. Unknown source builds, distribution packages, and embedded runtimes receive an operator path rather than an unchecked change.

Response tools

The scanners perform passive version and configuration inventory. Server remediation scripts default to check-only and require three confirmations before changes.

SHA256 checksums

Authoritative sources

Product facts prioritize PHP and GitHub Security Advisories; CISA, CERT-EU, NCSC-NL, and cloud-provider notices are used for cross-checking.

1. PHP official security advisory · 2026-10-21
2. CVE-2026-109618 · GHSA-w8hw-w9fx-j79w
3. CVE-2026-109619 · GHSA-6wmf-4rv5-p3rp
4. PHP 8.2.35 official release record
5. NCSC-NL · php2shell operational information
6. CISA CSAF/VEX · VA-26-295-01
7. Canadian Centre for Cyber Security · AL26-026
8. CERT-EU Security Advisory 2026-018
9. Cloudflare · php2shell WAF protection