PHP2Shell: patched isn't safe until you check for compromise

Short read

This post covers PHP2Shell, two serious flaws in PHP made public on 21 October that let attackers take over web servers remotely. Attacks were spotted four days before the fix came out, and working attacks have since been seen on servers that hadn't been updated, so updating PHP isn't the end of the job.

You'll learn how to find every place PHP runs in your business, including inside other products, and how to look for signs of a break-in going back to 17 October. We also explain how urgentic BLUE watches for this kind of suspicious activity around the clock, because the real question is "can we show nobody got in before we patched?"

If you patched PHP after the PHP2Shell disclosure on 21 October, you've closed the door. What patching can't tell you is whether anyone walked through it before you did. For PHP2Shell, that gap is real: exploitation attempts were recorded four days before the fix was published, and working shells have now been seen on unpatched servers.

This article covers what we know about the two PHP2Shell vulnerabilities, why the patch date is the wrong place to start an investigation, and the practical checks that tell you whether a PHP server was compromised before it was updated.

What PHP2Shell is

PHP2Shell is the name given to two flaws in PHP, CVE-2026-109618 and CVE-2026-109619. According to the NCSC's alert for UK organisations, the first lets an attacker trigger an out-of-memory condition that interrupts PHP while internal request data is only partly set up. The second lets internal state from one request survive after its memory has been freed, so a later request handled by the same worker can use it. Together, under certain conditions, they allow unauthenticated remote code execution on a web server running PHP.

The reach is wide. CISA's alert says the flaws affect all PHP installations serving web requests, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On 26 October, CISA added both flaws to its Known Exploited Vulnerabilities catalogue, which means it has evidence of exploitation in the wild.

Why the patch date is the wrong starting point

Most patching processes treat the disclosure date as day zero. PHP2Shell shows why that assumption no longer holds.

Amazon Threat Intelligence reported a PHP2Shell exploitation attempt against its honeypot network dated 17 October 2026, four days before the embargo lifted at 14:00 UTC on 21 October. On the day of release, it saw proof-of-concept exploits from around 02:00 UTC, and further attempts from several sets of anonymised infrastructure in the hours that followed. Once the patch was public, more proof-of-concept exploits appeared within hours and were used against its sensors almost immediately.

Amazon's advice to security leaders is direct: start investigations from the earliest known exploitation, not from the disclosure date, and for PHP2Shell investigate from at least 17 October.

The picture has also moved from attempts to confirmed code execution. SecurityWeek reported that a researcher running honeypots on PHP 8.4.26 under Apache mod_php recorded 35 shells launched across three honeypots on 24 October, using a four-stage chain of requests that first exhausted PHP's memory, then leaked memory contents, then ran a shell command.

So if a server was exposed and unpatched at any point from 17 October onwards, "we've patched it" is only half an answer.

Find every PHP install first

You can't check a server you don't know about. Both CISA and the NCSC make the same point: PHP is often bundled inside other software, so it won't always show up as "PHP" in an asset list. The NCSC also advises not to limit discovery to outdated versions, because all versions before the fix may be affected.

Start with an inventory that covers:

• Web servers and hosting platforms you run directly
• Content management systems, intranets and customer portals
• Appliances and third-party products that include PHP. The Dutch NCSC has published a list of affected products, linked from the NCSC alert
• Anything internet-facing first, then internal systems

Confirm each one is on a fixed version. CISA says that anything that can't be updated straight away, or that runs PHP 8.1 or earlier unsupported versions, should be taken offline until it can be patched or updated.

How to check for signs of compromise

The NCSC's guidance is clear that if you couldn't update immediately, you should look for evidence of compromise and for backdoors before you call the job done. Based on the published guidance, these are the places to look, going back to 17 October:

• PHP worker processes launching shells or downloading tools. CISA specifically calls this out as suspicious activity to monitor. A web server process starting a command shell, or running tools such as curl or wget, deserves an immediate look.
• Out-of-memory errors and worker crashes. The attack chain relies on exhausting PHP's memory, and the honeypot research logged out-of-memory errors and worker crashes as part of the activity. A cluster of these in your logs is worth investigating, even if most turn out to be failed attempts.
• Unusual multipart requests. Amazon suggests blocking multipart file uploads on deployments that can't be patched straight away, where your application allows it. That makes unusual multipart traffic in web server logs worth reviewing.
• New or changed files in web roots. Web shells are often small files dropped where the server will run them.
• Unexpected outbound connections from web servers. A web server reaching out to unfamiliar addresses can be a sign that a second-stage tool has been downloaded.

CISA has also published a SIGMA detection rule for PHP2Shell activity, linked from its alert, which can be adapted for most log platforms. If you aren't confident running these checks yourself, the NCSC recommends getting help from an NCSC-assured Cyber Incident Response provider.

The wider lesson: patch by exploitation, and keep watching

PHP2Shell is one vulnerability, but the pattern isn't new. In our article on five security controls behind fifteen breaches, two of the five were patching by exploitation rather than by severity score, and having someone looking at what your systems are doing every hour of the day.

Amazon's analysis explains why both matter more now. AI-assisted analysis makes it quicker to turn a patch or advisory into a working exploit, so more attackers can act within hours of disclosure. Its recommendation is to measure patch timelines for critical, internet-facing flaws in hours, not in 7-day or 30-day service levels, and to invest in detections that don't depend on a signature for one specific vulnerability, because the first exploitation often comes before those signatures exist.

That's the gap a patch can't close on its own. The evidence of an intrusion before the fix sits in process activity, logs and network connections, and it only helps if someone reviews it quickly. The longer an intruder goes unnoticed, the more damage they can do, as we covered in how long attackers go undetected.

This is the work urgentic BLUE is built for: AI agents that investigate alerts around the clock, so suspicious behaviour on a server gets looked at when it happens rather than when someone next checks the queue. You can see how it fits together on our platform page.

Whatever tools you use, the question for this week is the same. Not "did we patch PHP?", but "can we show nobody got in before we did?"