Amazon Threat Intelligence reported that its MadPot honeypot telemetry recorded a PHP2Shell exploitation attempt on October 17, 2026, four days before PHP publicly disclosed CVE-2026-109618 and CVE-2026-109619. The source IP was associated with a commercial anonymization network. AWS says it cannot determine whether the observed attempts would have succeeded against real-world systems.

What the two flaws put at risk

PHP describes two critical flaws in its core request handling that can enable unauthenticated remote code execution, meaning an attacker may run code without first logging in. PHP rated both vulnerabilities 9.2 under CVSS v4.0, a severity scoring system.

  • CVE-2026-109618 involves out-of-memory corruption. If PHP runs out of memory while request data is only partly initialized, cleanup may handle that invalid data as if it were valid.
  • CVE-2026-109619 involves stale request state. A later request handled by the same worker may use internal state after its backing memory has been freed, before normal initialization resets it.

PHP says all installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It identifies mod_php as the highest-risk integration because an unauthenticated request can trigger the issue before application code runs.

PHP lists PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as fixed releases. Its security notice also says Linux distributions and long-term support vendors may backport fixes, so their package version numbers may differ from the upstream releases. PHP 8.1 and older no longer receive updates from the PHP project.

What Telekom Security recorded on its honeypots

Telekom Security's separate honeypot report places the advisories' appearance in its timeline at 13:34 UTC on October 21 and records its first exploit-like serialized payloads at 14:18 UTC that day. Those observations describe Telekom Security's sensors; AWS's report concerns MadPot's separate network and an attempt dated October 17.

What PHP operators should do

PHP says updating to a fixed release is the complete remediation; configuration measures reduce exposure to specific attack paths. AWS recommends reviewing POST requests containing PHP_SESSION_UPLOAD_PROGRESS, web-server logs, and unexpected process execution or file changes. For systems that cannot be patched immediately, AWS says to consider restricting multipart file uploads only after assessing the effect on the application.

AWS also listed six IP addresses associated with its observations: 103.216.220.92 on October 17, and 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 and 95.217.98.37 on October 21. AWS says the addresses include shared anonymization infrastructure and recommends investigating matches rather than blocking them automatically.