Two critical PHP flaws can enable unauthenticated code execution, and Amazon says it detected an apparent exploit attempt four days before they were publicly disclosed.
How the flaws put servers at risk
The flaws, CVE-2026-109618 and CVE-2026-109619, are known together as PHP2Shell and affect PHP’s core runtime. One involves a request running out of memory while PHP sets up internal data; cleanup can then mishandle that data. The other can leave stale internal state pointing to memory that has already been freed, which a later request handled by the same worker may use.
PHP identifies Apache’s mod_php as the highest-risk setup because an unauthenticated request can trigger an exploit before application code runs. Researchers also demonstrated code execution through PHP-FPM application paths. PHP says all installations serving web requests are at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed.
What needs to be updated
Changing a website’s application or content-management system is not enough: the flaws are in PHP itself, beneath software such as WordPress or Drupal. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP no longer supports version 8.1 and older, so organizations using those versions need to check for a backport from their operating-system or long-term-support provider, or move to a supported version.
Cloudflare estimates PHP runs on nearly 70% of websites. That is the language’s estimated prevalence, not the number of systems that are vulnerable or compromised. A successful attack could give an intruder the web server’s privileges, with potential to steal data, disrupt services or use the server to reach elsewhere in a network.
Why the fixes took time
The PHP Foundation says signs of the out-of-memory issue emerged during an external security audit in 2024, but no concrete attack path had been found then. Fixes to core memory handling can bring risks: maintainers said possible approaches could break compatibility, reduce performance or require changes across PHP’s large extension ecosystem. OpenAI says Calif used its GPT-5.6 Sol model to help find one critical flaw, while Wiz independently discovered and reported both. PHP maintainers led the fixes.
A release plan under pressure
CVE identifiers appeared online on October 20, before patches were available. PHP moved its planned release forward to October 21, saying it could publish early if details leaked or active exploitation appeared. The PHP Foundation later said Chainguard published patched container images more than six hours before the coordinated release, potentially giving attackers time to study the fix. Chainguard’s CEO defended the decision as a response to reports of active exploitation.
What the reports say about attacks
Amazon says its MadPot honeypot network recorded an apparent PHP2Shell attempt on October 17, four days before public disclosure. Amazon does not know how the actor obtained the exploit information. It reported more attempts before and after the October 21 release, but said it has not established whether the earliest attempts would have worked against real-world systems. CISA said in its October 21 alert that it had not observed exploitation at the time of publication. Attempts are not proof of successful compromises, and the reports describe observations made at different times.
PHP may be hidden in containers, appliances, hosting platforms or other products, making it hard to find. CISA urged organizations to inventory systems, prioritize internet-facing servers and take PHP-based services offline if they cannot update promptly. A web application firewall can provide temporary protection, but Cloudflare says it is not a substitute for updating PHP and reports that attackers have changed payloads to test defenses.
What defenders should do next
Amazon says exploitation is now broad and urges organizations to treat critical fixes for internet-facing systems as urgent, rather than relying on week-long patch schedules. Defenders should find every PHP runtime, verify that the runtime—not just the application—has been fixed, and review logs for suspicious activity. Because Amazon’s earliest observed attempt predates the public warning, organizations should not assume the risk began on disclosure day.