PHP2Shell RCE Flaws: Patch CVE-2026-109618 and CVE-2026-109619 on PHP Servers

The short version for admins​

Two critical PHP flaws, nicknamed PHP2Shell, were patched in an emergency release on October 21, 2026.

• CVE-2026-109618 is "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w).
• CVE-2026-109619 is "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp).
• Both are rated CVSS v4.0 9.2.
• The patched versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
• PHP says both can allow unauthenticated remote code execution on installations that serve web requests. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates the risk highest for mod_php.
• PHP notes that Windows source and binaries are on its downloads page.

Check Point also points out that the bug is in the PHP core interpreter, not in application code, so updating WordPress, Magento or Drupal alone will not fix it.

The dispute: who broke the embargo?​

PHP's account​

As reported by The Register, PHP maintainers say two CVE IDs began circulating on forums and social media around 15:00 UTC on Tuesday, October 20. The posts carried wrong details about the release time and severity. That pushed the maintainers to warn users and move disclosure forward a day, from Thursday to Wednesday.

Third-party write-ups add detail. The original post was taken down, but screenshots had already spread. Researchers at watchTowr then confirmed the leak was real and said they had reproduced CVE-2026-109618.

PHP's own blog, per The Register, lists several further problems:

• Researchers at Calif "mistakenly" published a proof-of-concept video and limited extra information.
• Mitigation advice given to a few critical-infrastructure providers may also have leaked.
• At 07:41 UTC on October 21, more than six hours before the coordinated release, Chainguard published built images containing the fix.

PHP's complaint about the last point is that anyone could inspect the fix in binary form while other PHP users were still waiting for official updates.

Chainguard's account​

CEO Dan Lorenc told The Register that the company "didn't leak". He did not dispute the timeline. His version of events:

• A researcher told Chainguard on Friday that something was coming in PHP.
• That night, Chainguard's own AI harness and a frontier model independently found the same memory-corruption bugs.
• Chainguard worked with the maintainers from Saturday and helped test the patches.
• By Tuesday night, proofs of concept were on social media and other vendors were reporting real-world exploitation.
• Lorenc notified PHP's coordinated-disclosure channel and shipped the fixes, citing a policy of coordinating "unless there's evidence of active exploits in the wild."

He also said Chainguard's honeypots caught IPs from China and Russia targeting the bugs on Wednesday. That is his claim. The sources I reviewed did not independently confirm it, and none of them established how widespread exploitation is. Other reports are mixed. SOCRadar says some vendors report in-the-wild exploitation that is still under investigation, while Equixly lists exploitation as disputed.

Chainguard's support notice does corroborate one operational point. It says the patched images were built overnight, before the public disclosure, so the console may show updates timestamped hours before the announcement. It does not settle the argument over authorization or motive.

My read​

Both positions are defensible, and neither is clean.

• PHP's case is that embargoes protect the many users who depend on slower distribution channels. A public fixed binary makes diffing easy.
• Chainguard's case is that once proofs of concept circulate and exploitation is reported, silence only helps attackers. Check Point's reading of the sequence fits that view, since the original leak had already begun.
• The Register notes the irony that a supply-chain security company is the one accused.

The more durable lesson is Lorenc's remark that simply being told a bug exists in PHP was enough for him to find it with AI. If that holds up, embargo windows built for human-speed analysis are shrinking. That is general analysis, not a finding from the sources.

How the bugs work​

CVE-2026-109618. PHP can exit a request via longjmp() after an allocation failure. If that happens while request memory is only partly initialized, the shutdown code later treats it as valid. The advisory describes several ways a remote request can reach out-of-memory, including multipart parsing quirks. The confirmed RCE was against Apache mod_php with default input and memory limits. Per the advisory, PHP-FPM exits a child when request startup fails, which blocks that exact route. Source analysis still supports FPM as susceptible, but no complete FPM exploit has been demonstrated. FrankenPHP is likely susceptible; LSAPI exploits are likely but unvalidated.

CVE-2026-109619. Request-owned state, such as error and session state, can survive after its memory is freed. A later request on the same worker can then use it, causing a use-after-free. The advisory confirms RCE against mod_php. It also confirms a session-lifecycle path against both mod_php and FPM. Session upload progress is enabled by default.

Wiz, as quoted by The Register, says every PHP release of the last decade is affected by at least one of the bugs, back to 5.4. PHP's own pages give fixed versions and the support boundary, not a full affected-version matrix. Treat the 5.4 claim as Wiz's.

What to do​

1. Inventory PHP. The EU's joint statement from the European Commission, ENISA, CERT-EU, Europol EC3 and the CSIRTs Network says to identify PHP-based applications, coordinate with hosting providers and prioritize internet-facing systems. It also warns that many products use PHP in the background.
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor's patched package. PHP says Linux distributions and LTS vendors received the patches in advance.
3. Restart workers and confirm the running version, not just the installed one.
4. Check PHP 8.1 and older. The PHP project no longer updates them, though vendors may backport fixes. PHP says its security team also provided minimal source backports for 7.4, 8.0 and 8.1 for people building from source. The Check Point and PatchMon tables show 8.2 security support ends December 31, 2026.
5. If you truly cannot patch yet, PHP lists partial mitigations. None of them makes an installation safe.
   • Set memory_limit=-1 administratively, so applications cannot override it. PHP warns an underlying allocation failure can still reach the vulnerable path. Be aware of the operational effect on memory use.
   • Set a conservative post_max_size, such as 8M if you don't need uploads and 32M if you do. Enforce request limits at the web server or proxy.
   • Do not use RLIMIT_AS or RLIMIT_DATA as a substitute. These can cause the vulnerable allocation failure.
   • Set session.upload_progress.enabled=0 and restart every worker.
   • On PHP 8.5, set fatal_error_backtraces=0.
   • Fix attacker-reachable fatal errors and timeouts in your applications.
   Cloudflare has also deployed WAF rules, which Security Boulevard describes as a stopgap that covers only traffic routed through Cloudflare.

If you run Chainguard images​

Chainguard's guidance lists fixed package versions. They carry the same fixes as the official releases but keep older version numbers:

Affected images include php, php-fips, php-fpm and frankenphp. They also include images that bundle PHP, such as WordPress, Drupal, Laravel, Nextcloud, phpMyAdmin and Moodle.

Common failure points, per Chainguard:

• Digest-pinned images never pick up the fix. Look up the current digest and update your manifests.
• Mirrors and caches need a sync, followed by a digest comparison.
• Cached build layers need docker build --pull --no-cache.
• Pinned apk add versions need updating to the fixed version or later.
• php -v showing 8.4.26 rather than 8.4.27 is expected on a fixed -r4 package.
• PHP 8.1 gets no fix from Chainguard. It recommends upgrading, and suggests 8.4 or 8.5 given 8.2's end of life.

To confirm a fix, check the SBOM attestation or run apk info -v inside a -dev image. These instructions apply only to Chainguard's packages. Other distributions will use their own package versions.

Why this matters beyond PHP​

PHP's own advisory calls its risk highest for mod_php. Operators of default Apache and mod_php stacks should treat this as an emergency rather than a routine patch Tuesday item. The wider question is how coordinated disclosure should work when AI shortens the gap between "something is coming" and a working exploit. That debate won't end with this incident, and the disclosure fight may get more attention than the patching job. The patching job is the part that decides whether servers get compromised.