HTTP2Shell confusion masks urgent PHP2Shell patch

Is HTTP2Shell the same as PHP2Shell?

No. The names are easy to misread, but the affected code, products and remediation paths differ. PHP2Shell is the informal name for CVE-2026-109618 and CVE-2026-109619 in PHP itself. The PHP project’s advisories classify both as critical and list the same four patched PHP builds.

HTTP2Shell, also called Node2Shell in earlier coverage, refers to CVE-2026-111497 in Brotli decompression. Brotli is a compression format often used in web traffic. Node.js says malformed Brotli input can write outside an internal decoder buffer when an application decompresses attacker-controlled data.

The practical rule is simple: a PHP version upgrade does not repair the Brotli flaw, and a Node.js upgrade does not repair the PHP flaws. The HTTP2Shell incident record lists separate fixes for Node.js, Bun, Python Brotli packages, Envoy and Istio. Treat the similarity in names as a search problem, not a shared vulnerability.

Which PHP versions need the PHP2Shell patch?

Every supported PHP branch needs its matching fixed build. The PHP project released security updates on 21 October for the four supported production branches. Its release archive says there are no complete mitigations, making an updated runtime the safe choice.

PHP’s release archive confirms that 8.2.35, 8.3.36, 8.4.27 and 8.5.12 fix both CVEs. It also says PHP 8.1 and older no longer receive updates from the PHP project. That is the most important dividing line for triage: identify installed versions, not merely the version an application was designed to use.

Do not mistake the release number after the dot for a severity score. It is the required maintenance build within that branch. A server on PHP 8.4.26 is exposed, for example, while PHP 8.4.27 contains the security changes.

What do the two PHP flaws actually affect?

The flaws sit below WordPress, Drupal, Laravel and custom PHP code, in the PHP interpreter. CVE-2026-109618 concerns an out-of-memory condition. If a request reaches PHP’s configured memory limit at a particular point, PHP can later treat partly initialized internal data as valid, causing memory corruption.

PHP’s advisory for CVE-2026-109618 says Apache deployments using mod_php had a demonstrated unauthenticated code-execution path with default settings. It also confirms code execution through PHP-FPM application-level paths. PHP-FPM is the FastCGI process manager commonly used behind web servers.

The second issue, CVE-2026-109619, concerns stale global state after a fatal error. A worker can retain a reference to memory from a prior request after that memory was freed. The PHP advisory for CVE-2026-109619 records a confirmed use-after-free and worker crash, plus demonstrated code execution against a real-world Apache mod_php application.

Both advisories score 9.2 on CVSS v4. CVSS is a standardized severity measure, not a forecast that every unpatched server will be compromised. In this case, the score reflects a network-reachable risk with no required account, alongside significant impact if the conditions for exploitation are met.

Does secure application code protect a PHP server?

No application patch can fully remove this runtime-level exposure. A careful WordPress plug-in configuration or a well-reviewed Laravel application does not replace an updated PHP binary. The application still depends on the same PHP engine to parse requests, allocate memory and handle errors.

Wiz says it demonstrated unauthenticated code execution against WordPress, Drupal and Joomla deployments, but describes those as representative targets. Its key finding is broader: a simple PHP application can be vulnerable because the vulnerable behavior is in the engine, not in the site’s own source code.

That changes the asset list. Include public websites, internal dashboards, queue workers with web endpoints, hosting control panels, container images and appliances that bundle PHP. Inventory should also cover inactive virtual hosts and old containers. They can remain exposed even when the main site runs a newer release.

How should teams triage PHP2Shell today?

Start with exposed PHP web services, then find every remaining runtime package and image. The PHP project says the issues touch memory management and error handling, parts of the engine used by nearly every request. That makes web-facing installations the first operational priority.

1. Identify the actual runtime. Check the PHP executable, PHP-FPM pools, Apache modules, containers and vendor appliances. A deployment repository may say PHP 8.4 while the running package is older.
2. Compare against the fixed build. Require 8.2.35, 8.3.36, 8.4.27 or 8.5.12, unless the operating-system vendor explicitly confirms an equivalent backport.
3. Apply the vendor package or rebuild the image. Replacing source code without redeploying the running PHP service does not complete the work.
4. Restart long-running workers. Confirm PHP-FPM, Apache workers and application worker processes now load the patched runtime.
5. Record exceptions. Unsupported branches need an owner, an upgrade plan and compensating isolation until retirement.

Tenable’s guidance notes that authenticated or agent-based checks are more complete than unauthenticated scans. A remote scan can only identify an exposed PHP version when the host reveals it. That matters because hiding a version header can reduce scanner visibility without changing the installed runtime.

Web application firewall rules can reduce exposure to known request patterns, but they are not a patch. PHP’s own release notice says complete mitigations do not exist. Use filtering and temporary isolation as short-term risk controls while a package update is being staged.

What should PHP 8.1 and older users do?

Move to a supported branch or obtain a verified vendor backport. PHP 8.1 and earlier do not receive official PHP project releases for these flaws. The PHP archive says some Linux distributions and long-term-support vendors may backport fixes, so a package version can be secure even when it does not look like an upstream 8.2, 8.3, 8.4 or 8.5 release.

That exception needs proof from the operating-system or appliance vendor. “Our server is on Ubuntu,” “our host handles security,” or “the control panel updates PHP” are not confirmations. The useful evidence is a vendor advisory naming CVE-2026-109618 and CVE-2026-109619, along with the corrected package version.

For a business that cannot upgrade immediately, prioritize systems that accept public web requests. Isolate them where possible, reduce exposed functionality and set a dated migration decision. Permanent dependence on an unsupported interpreter leaves the organization waiting for vendor exceptions whenever the next core PHP issue arrives.

When did PHP promise and ship the patch?

The planned release moved forward by one day after the CVE identifiers leaked. This timeline separates the intended coordinated disclosure from the security releases that customers could actually install. Times below are UTC where the PHP Foundation provided one.

The PHP Foundation’s account says the earlier planned release was 22 October at 14:00 UTC. It moved to 21 October after the leaked CVE identifiers circulated with an incorrect 10.0 score. The actual CVSS v4 score for each PHP advisory is 9.2.

The same account records that patched Chainguard images appeared at 07:41 UTC on 21 October, more than six hours before coordinated release. That did not provide a patch path for every user, but it meant the binary changes could be studied ahead of the general announcement.

How does the cross-language Brotli risk change triage?

It adds a separate dependency check for services that decode untrusted Brotli data. That work should run alongside, not instead of, PHP2Shell patching. The shared term “shell” does not establish a shared exploit path, shared vulnerable server, or shared fixed package.

Node.js released fixed versions 22.23.4, 24.22.1 and 26.12.1 on 21 October. Node.js describes the affected condition as malformed compressed input passed to its bundled Brotli decoder, including applications that use node:zlib to decompress attacker-controlled data.

The broader HTTP2Shell label includes products that bundle or call the affected decoder. The listed fixes include Bun 1.4.4, PyPI Brotli 1.2.1, Envoy builds in several supported release lines, and Istio builds 1.29.9, 1.30.6 and 1.31.2. Those are separate products with separate ownership teams.

For a mixed stack, create two tickets. The first should name the PHP CVEs and the four PHP fixed builds. The second should name CVE-2026-111497 and ask whether the service decodes Brotli responses or request data. Joining the tickets risks an inaccurate closure note: one fixed package cannot prove both issues are resolved.

What we could not verify?

Public information does not establish one universal exploit condition for every PHP deployment. The demonstrated impact varies with web-server mode, PHP configuration and application behavior. Only the operator of a specific environment can confirm whether it accepted the conditions needed for an attack before patching.

Public material also cannot confirm whether a particular server was compromised. Web-server logs, PHP-FPM logs, process records, file-integrity checks and the organization’s incident-response team can settle that question. Vendors of end-of-life PHP packages can settle whether their packages contain a verified backport.

Sources

• The PHP Foundation: Today’s PHP Security Release, and How We’re Strengthening PHP Security
• PHP: News Archive 2026
• PHP advisory GHSA-w8hw-w9fx-j79w: RCE via OOM corruption
• PHP advisory GHSA-6wmf-4rv5-p3rp: RCE via stale global state
• Wiz: PHP2Shell research
• Tenable: PHP2Shell FAQ
• Node.js: 21 October 2026 security releases
• pwn.watch: Node2Shell / HTTP2Shell incident record