Amazon says its MadPot honeypot recorded an attempted PHP2Shell attack on October 17, 2026, four days before PHP publicly disclosed the vulnerabilities and released fixes. The activity was aimed at Amazon’s sensors; the company did not report a confirmed compromise of a real-world system. PHP’s fixed releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

What Amazon’s sensors recorded

Amazon says MadPot recorded the October 17 attempt against a honeypot. On October 21, the day PHP disclosed the flaws, Amazon observed proof-of-concept activity around 02:00 UTC and additional attempts against its sensors between 02:00 and 08:00 UTC. PHP lifted its disclosure embargo at 14:00 UTC; Amazon says further activity targeted its sensors after that time.

A honeypot is a decoy system set up to attract and observe suspicious activity. These dates describe activity Amazon says it saw on its own sensors, not confirmed intrusions into other organizations’ systems. Amazon says it could not determine how the October 17 actor learned about the vulnerabilities.

Which PHP installations are affected?

PHP2Shell is the name used for two critical vulnerabilities in PHP’s core. Both can allow remote code execution (RCE), meaning an attacker can run code on a server, without authentication in affected web-serving installations.

PHP names PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed among the affected request-serving environments. It identifies Apache mod_php as the highest-risk configuration.

The two flaws involve different memory errors. CVE-2026-109618 involves out-of-memory handling that can leave request data partly initialized. CVE-2026-109619 involves stale global state: a worker can retain a reference to request-owned memory after that memory has been freed, allowing a later request to encounter the old state.

Which PHP versions include the fixes?

PHP’s October 21 security release lists these upstream versions as fixing both vulnerabilities:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

PHP 8.1 and older no longer receive updates from the PHP project. Distributions and long-term-support vendors may backport fixes, and PHP says it provided source backports for versions 7.4, 8.0, and 8.1. For packages supplied by a distributor, check that provider’s status rather than relying on the upstream version number alone.

Can a WAF replace the update?

No. PHP says installing a fixed release is the only complete remediation. Configuration changes can reduce exposure to particular attack paths, but do not make an installation safe. A web application firewall (WAF) can be an additional layer; it is not a substitute for applying the fix.

PHP’s security release lists the fixed versions, affected environments, and limits of configuration mitigations.