TL;DR
- what: PHP released emergency fixes for CVE-2026-109618 and CVE-2026-109619, two critical flaws in the PHP runtime collectively named PHP2Shell, a day after details leaked ahead of planned disclosure.
- impact: An unauthenticated attacker can achieve remote code execution, with a single-request exploit demonstrated on Apache mod_php, and can read worker memory holding passwords, tokens, API keys and certificates from other requests.
- fix: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both flaws, source backports exist for 7.4, 8.0 and 8.1, and the PHP team states that only updating fully protects a server.
- who: Every PHP installation serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, regardless of how secure the application code is.
PHP has shipped emergency updates for two critical flaws in the language runtime that let an attacker with no account execute code on a web server. Tracked as CVE-2026-109618 and CVE-2026-109619 and collectively named PHP2Shell, both carry a CVSS v4.0 score of 9.2 and affect nearly every PHP version back to PHP 5.4. Because the bugs live in the engine, not in application code, a server is exposed even if the site running on it is flawless. A plain "Hello World" page on a vulnerable PHP build is enough of a target.
The fixes landed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 around 14:00 UTC on October 21, 2026. That release came a day after technical details leaked ahead of a coordinated disclosure planned for October 22. Researchers at Wiz, Calif and OpenAI found and reported the flaws. Cloudflare reported early exploit attempts before the patch shipped.
What PHP2Shell Does
The PHP security advisory lists every web-facing deployment model as affected: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Exposure differs by server API.
- Apache mod_php is the highest-risk configuration. Researchers demonstrated an exploit where a single unauthenticated request triggers the attack before any application code runs.
- PHP-FPM shuts the worker down when a request fails early in setup, which changes the picture. For one flaw, PHP's analysis supports that FPM is susceptible, but no complete FPM exploit has been shown.
- The second flaw was shown to reach code execution on both mod_php and PHP-FPM, though the FPM path depends on an operation inside the running application.
- Separately from code execution, an attacker can read memory from the PHP worker process. That memory can hold passwords, authentication tokens, API keys and certificates belonging to other users' requests.
The memory disclosure deserves equal weight with the RCE. The researchers demonstrated reading live worker memory against applications they did not control, meaning the technique does not depend on the application stack above PHP. A server that never yields a shell can still leak session tokens and secrets from concurrent traffic.
⚠️ Application updates do not fix this — Updating WordPress, Laravel or any other framework does not touch the PHP runtime beneath it. The runtime comes from the server package, the hosting provider or the container image, and that is the layer that must change. The PHP team states plainly that only updating the runtime fully protects a server.
The Patch and Branch Status
Fixed versions per supported branch are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything below those numbers on the respective branch is vulnerable. PHP 8.1 and older no longer receive official releases, and PHP 8.2 reaches end of life on December 31, 2026. For the unsupported branches, the PHP security team published source backports for PHP 7.4, 8.0 and 8.1 aimed at teams building from source or waiting on a vendor.
Linux distributions and long-term-support vendors received the patches in advance. A distribution package can therefore carry the fix under a version string that looks old. Debian advises confirming the CVE in the package changelog rather than trusting the version number. This matters for inventory: version-based scanners will flag patched distro packages as vulnerable and may miss unpatched custom builds.
The fix also introduces a new hard memory limit. Hitting it terminates the process and prevents shutdown handlers from running, so applications with heavy memory use or cleanup logic in shutdown handlers may behave differently after the update.
Interim Mitigations Are Partial
The advisory lists configuration changes that reduce exposure to specific attack paths while stating they do not make a server safe. For CVE-2026-109618, the advisory covers memory_limit, post_max_size and request-size limits at the web server or proxy, and warns that RLIMIT_AS and RLIMIT_DATA can trigger the same vulnerable path and are not substitutes. For CVE-2026-109619, it covers disabling session.upload_progress.enabled, plus fatal_error_backtraces on PHP 8.5.
The session upload progress setting is the workaround that circulated before the patch, and the release confirms it was never a complete fix. Upload progress is on by default and can reach session handling before PHP finishes setting up a request, which is why it participates in one confirmed path for CVE-2026-109619. Disabling it blocks the confirmed session paths but not other variants, and does nothing for CVE-2026-109618.
"The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much," PHP core developer Gina Peter Banyard wrote before the release, responding to a suggestion that the setting might suffice.
Exploitation Status
Cloudflare CTO Dane Knecht said the company was seeing early attacks and updating its firewall mitigations as new vectors appeared, while calling those rules a stopgap and urging administrators to patch. No source has confirmed a successful compromise. watchTowr, which reproduced CVE-2026-109618, reported no in-the-wild exploitation as of 11:26 UTC on October 21, and neither CVE was in CISA's Known Exploited Vulnerabilities catalog at that time.
Several organizations pulled services offline as a precaution. BambooHR took its service down across the United States, Canada and Ireland, warned that payroll would be interrupted, and had no restoration time. In the Netherlands, NOS reported that MijnOverheid, DigiD, the lower house of parliament's site, the national cyber-security center and several education systems went offline.
Indicators the researchers flagged — For servers that may have been hit before patching, the researchers point to unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, abnormally large PHPSESSID response cookies, and unexplained PHP worker restarts.
RedEye Assessment
PHP2Shell is a runtime-level bug with a public leak, a 9.2 score, a one-request exploit on mod_php and confirmed scanning activity. That combination usually shortens the gap between disclosure and mass exploitation to days. The memory disclosure path widens the blast radius beyond RCE: any credential or token that passed through a vulnerable worker should be treated as potentially exposed. The hardest assets to find will be the ones nobody tracks: legacy PHP 7.x hosts, vendor appliances with embedded PHP, and container images built months ago. Organizations that cannot quickly answer which PHP runtimes they run, and which of those are internet-facing, are the ones most at risk this week.
Originally published on RedEye Threat Intelligence.
Top comments (0)