PHP2Shell: two critical PHP bugs, already exploited
PHP shipped emergency fixes on 21 October 2026 for two remote code execution flaws. What happened, and what to check on your servers.
What happened
On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical bugs, CVE-2026-109618 and CVE-2026-109619, that can let an unauthenticated attacker run code on a server that serves PHP web requests. Both are rated 9.2 on CVSS 4.0. Together they are being called PHP2Shell.
The two bugs, as the PHP project describes them:
- CVE-2026-109618: if PHP runs out of memory part-way through setting up a request, cleanup can treat half-built data as valid.
- CVE-2026-109619: request data can outlive its memory, and a later request handled by the same worker can use it.
Details leaked on 20 October, before the planned disclosure. watchTowr says it saw exploitation in the wild from 21 October, and that CISA added CVE-2026-109618 to its Known Exploited Vulnerabilities list on 26 October. BleepingComputer reported confirmed remote code execution against a test server running PHP 8.4.26 under Apache mod_php, and noted that this was a setup chosen to be easy to exploit, so it does not show how reliable the attack is elsewhere.
On 23 October PHP added a separate advisory, CVE-2026-115560. It affects only unusual setups (a session serialize handler changed at runtime while session upload progress is on) and has no fix yet. PHP suggests setting session.upload_progress.enabled=0 until the next release.
Why it matters
PHP runs a large share of the web, including WordPress and many older custom sites. These bugs need no login. A patch exists, but plenty of servers run PHP versions that get no updates from the project: 8.1 and older are not patched by PHP itself. watchTowr reports older branches, including PHP 5, are affected too.
What to check
- List every system that runs PHP, starting with internet-facing ones. Include old servers, staging sites and anything a hosting company runs for you.
- Find the PHP version on each one. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a distribution package that has the fix backported.
- Restart PHP workers after updating. The fix is not active until you do.
- If you run PHP 8.1 or older, plan an upgrade. Ask your vendor or distribution whether they backport the fix.
- Look for signs of compromise on servers that were exposed while unpatched: new files in web directories, unexpected processes, odd outbound connections.
- Do not treat configuration changes as a fix. PHP says updating is the only safe option.
If you are not sure what runs where, an external attack surface review answers it from the outside.