This episode breaks down:
Plus Bishop Fox research on the true blast radius of an AI attack when agents act inside enterprise systems.
PHP2Shell is the name for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities in the PHP runtime that let an unauthenticated attacker execute code on a web server. Both are rated 9.2 on the CVSS v4.0 scale. PHP fixed them on October 21, 2026, in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Because the flaws live in the PHP engine rather than in any application, a site can be exposed even when its own code is secure. Researchers say even a simple "Hello World" page on a vulnerable version can be attacked. Calif, OpenAI's Codex Security team, and Wiz Research found and reported the flaws.
What causes the PHP2Shell vulnerabilities? CVE-2026-109618 is triggered when PHP runs out of memory partway through setting up a request, which leaves internal data structures half built for cleanup code to trust. Calif showed attackers can force that condition with a multipart request packed with empty, deeply nested file-upload fields. That request fills the default 128 MiB PHP heap while staying under the default 8 MiB post_max_size limit. CVE-2026-109619 involves internal session state that outlives the request memory it points to, so the next request a PHP worker handles can act on stale data. Session upload progress, which is enabled by default, plays a role in one confirmed attack path. Attackers can also read memory from PHP worker processes without first gaining code execution. That memory may hold passwords, authentication tokens, API keys, and certificates belonging to other requests. The underlying out-of-memory weakness traces back to a 2020 PHP bug report and was flagged again in a 2024 external audit, but no route to code execution was proven until 2026.
Which PHP versions and server setups are affected by PHP2Shell? Every PHP installation that serves web requests is in scope:
mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. Apache mod_php carries the highest risk: a single unauthenticated request can trigger the attack before any application code runs. PHP-FPM is also at risk: CVE-2026-109619 has been shown to reach code execution on PHP-FPM, though that path depends on an operation inside the running application, such as session handling or unserialize() calls. Calif confirmed pre-authentication RCE against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony, and WHMCS.
Is PHP2Shell being exploited in the wild? Exploit attempts are underway, but no confirmed compromise of a specific server had been reported as of October 22, 2026. Cloudflare reported early attack traffic before the patch shipped and watched attackers modify payloads to get around its firewall rules. watchTowr observed exploitation attempts against both CVEs through its honeypot network. Neither CVE had been added to CISA's Known Exploited Vulnerabilities catalog as of October 23. Several organizations took systems offline as a precaution, including BambooHR and Dutch government services such as DigiD and MijnOverheid. Some proof-of-concept code circulating publicly is fake, and some is built to infect the researchers who run it, so treat unofficial PoCs as untrusted.
How did the PHP2Shell coordinated disclosure fall apart? Calif reported the first bug to PHP on August 11, 2026, and disclosure was planned for October 22. On October 20, details were leaked online ahead of the embargo. That evening, around 20:00 UTC, Calif posted a video of its working proof of concept. According to Bishop Fox exploit developers who reviewed it, the video exposed memory addresses and function calls that pointed researchers toward the vulnerable code. On the morning of October 21, a vendor published container images containing the patch about six hours before the official release, letting anyone study the fix. PHP pulled its release forward to 14:00 UTC on October 21, roughly 18 hours after the video appeared.
How did AI help find and exploit PHP2Shell? AI accelerated both discovery and exploitation, but human expertise pointed it in the right direction. Calif's researcher used no special harness or non-public models. He steered an LLM using his knowledge of a 2004 PHP memory-limit bug, and the researchers say that let one person do in about a week what would otherwise take a team months. The same speed applies to anyone working from leaked details. A Bishop Fox exploit developer fed screenshots of the leaked demo video to an AI model, and within an hour it had triaged the right bug in the right region of code. It got roughly 90% of the way to a working chain before missing the out-of-memory step.
Is PHP2Shell as bad as Log4j? The scope is comparable, but exploitability is less uniform. With Log4j, running the vulnerable library was usually enough to be exposed. With PHP2Shell, success depends on preconditions such as the server API, the PHP version, the application's behavior, and its configuration. Even Calif tailored its exploits to specific platforms. Whether PHP2Shell ends up worse or better than Log4j will depend on how portable public exploit code becomes.
Can a WAF rule or configuration change protect against PHP2Shell? Not fully. PHP states that only updating protects a server, and that no configuration change fully mitigates either flaw. Cloudflare called its own firewall rules a stopgap after attackers began reworking payloads to bypass them. The interim measures PHP published reduce exposure to specific attack paths only:
memory_limit=-1 so applications cannot override it, keep post_max_size low, and enforce request-size limits at the web server or proxy. Do not substitute RLIMIT_AS or RLIMIT_DATA, which can trigger the same vulnerable path. session.upload_progress.enabled=0 and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0. This blocks the confirmed session paths but not other variants. What indicators of compromise should you look for after PHP2Shell?
Review logs and hosts for:
Why does PHP2Shell make the case for continuous security testing? A point-in-time penetration test from six months ago could not account for a 2020 bug becoming exploitable this week. Point-in-time testing still fits a new product launch or a foundational new feature. Systems that keep changing, or that depend on components as widespread as PHP, need ongoing testing that tracks emerging threats as they appear.
Mitigation: Update every PHP runtime to the fixed release for its branch, starting with internet-facing servers running Apache mod_php. Then restart Apache, PHP-FPM, and any long-running PHP workers. Updating an application such as WordPress or Laravel does not update the PHP runtime underneath it. That comes from the server package, the hosting provider, or the container image. Linux distributions received the patches in advance and may ship the fix under an older-looking version number, so check package changelogs for the CVE IDs; the version string alone won't tell you. For PHP 7.4, 8.0, and 8.1, use a distribution or long-term-support vendor package or PHP's source backports; upgrade anything older. If a PHP system cannot be patched and is not business critical, take it offline or restrict internet access until it is. After updating, review memory_limit and post_max_size settings, because the fix adds a new hard memory limit that ends the process when reached. Plan for follow-up fixes, since researchers across the industry are now reviewing PHP for related flaws.
Sources: The Hacker News, Calif, watchTowr
Subscribe to our PODCAST
Real talk on the threats, trends, and tactics shaping security today
Recommened Resources
Download
Your download is starting in a new tab. If it does not start automatically, use the button below.
