Attackers have moved from scanning for PHP2Shell to executing commands on vulnerable servers, launching 35 shells against three honeypots on October 24, according to researchers tracking the activity. The confirmed executions came from two IP addresses and show that exploitation of the newly disclosed PHP flaws is no longer limited to reconnaissance.
The activity, reported by SecurityWeek, produced three shells from one address and 32 from the other across the sensors. Researchers said the attacks used a four-stage HTTP request sequence: some requests forced PHP into memory-exhaustion conditions, others exposed memory contents, and a final request executed a shell command. The traffic closely resembled a publicly available proof of concept. The evidence demonstrates command execution in the honeypots, but does not by itself establish the identity or affiliation of the attackers.
PHP2Shell refers to two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 under CVSS v4.0. The PHP project describes the first as remote code execution caused by out-of-memory corruption and the second as remote code execution involving stale global state. Both can allow an unauthenticated attacker to run code with the privileges of the web server process.
The flaws affect PHP installations serving web requests, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The PHP project considers Apache mod_php deployments particularly exposed because the demonstrated attack can reach vulnerable interpreter code before application logic runs. Older PHP branches are also affected, although PHP 8.1 and earlier no longer receive regular upstream releases; some operating-system and long-term-support vendors provide backported fixes.
PHP released security updates on October 21: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both vulnerabilities, according to the project’s security advisory. Administrators should identify every PHP runtime and package in use, install the corresponding vendor-supported update, and restart PHP-FPM, Apache and other persistent workers so the patched interpreter is actually loaded.
The PHP advisory lists configuration changes that can reduce exposure to particular attack paths, including disabling session.upload_progress where appropriate and tightening request and upload limits. Those measures are incomplete defenses, however. The project says updating is the only complete solution, and defenders should review web-server and process logs for unusual large requests, repeated memory-related failures, unexpected child processes and shell activity following PHP requests.
