On October 20, details of two critical flaws in PHP leaked online before the fixes were ready. PHP, the scripting language behind a large share of the web, moved its patch release up a day and shipped it on October 21. The flaws, CVE-2026-109618 and CVE-2026-109619 (nicknamed php2shell), let an attacker run commands on a web server through PHP itself, with no login needed.
Patch now. That advice is right, and it leaves a gap. This post is about the gap.
Attackers were testing the flaw before the fix existed
Fixes are out for PHP 8.2 to 8.5,and PHP says PHP 8.1 and older will not get updates. One estimate counts about 884,000 such servers still online, a rough figure from a single source.
Amazon's honeypots (decoy servers built to attract attackers) recorded the first attempt on October 17, four days before disclosure, and by October 21 Amazon described the flaws as broadly exploited. Cloudflare saw early attacks, and the UK National Cyber Security Centre warned organizations to update immediately or take systems offline. How many real servers were taken over is still unclear. Amazon says it does not know whether the attempts it saw would have worked outside a honeypot.
Every flaw has been out there for a while before anyone announces it
A flaw becomes news on the day it is announced, not the day it appears. PHP's own maintainers first spotted signs of this problem in a 2024 audit, and attackers reached it before the public did.
We have seen this pattern before. When Log4j hit in December 2021, Vectra wrote that the first sign of an attack was hard to spot and that the safest assumption was that at least one server in an estate was already compromised. Other flaws in the software your business runs are very likely in the same position today: known to someone, announced to no one. Patching deals with the ones you hear about. It cannot help with the rest.
The PHP servers you miss matter most
PHP runs WordPress,Drupal, Joomla and Magento sites, hosting control panels, and a lot of software that never mentions PHP. The servers you know about will get patched. The ones you do not know about are the ones attackers find first, because nobody is watching them.
No team patches everything on the day a fix ships. Knowing which servers face the internet, and which hold the most valuable data, turns a backlog into a short list of decisions, including which services to switch off until they are fixed. On any server you suspect was hit, save logs and a snapshot of memory before restarting, because a restart erases traces.
What happens after a PHP server falls
An attacker who gets code running through PHP usually does not need malware. The web server already has a shell, a network connection and access to files, so they can use the tools already installed on the machine to look around, find credentials and move from one system to the next. Nothing looks wrong, because the web server is doing web server things with slightly different commands. That is the first of the three detection gaps I write about: nothing looks wrong.
What changes is where the server talks to. A web server that has served the same pages for years suddenly reaches places it never did before, calls out to unfamiliar addresses, or starts talking to internal systems. That behavior shows up in network traffic, not in patch status. A view of the network is how you see what a server is actually connecting to, whether or not anyone is watching the server itself.
What Vectra AI can and cannot see
Vectra AI is not really concerned about what the initial attack vector is. What we see is what happens afterward.
PHP is the story today. Next week it will be something else: another flaw, a phone call to a help desk, someone on the inside. What we look at does not depend on which door was used. We watch what a system does once an attacker is inside, so we do not need the way in to be known or the flaw to be published. That matters most when the entry point is unknown or the vulnerability has not been announced yet.
Uncovering Potential PHP Servers and Shadow IT
One of the challenges in securing PHP infrastructure is knowing where it exists in the first place. Forgotten applications, unmanaged servers, and shadow IT can create security blind spots, even after known vulnerabilities have been patched.
Vectra AI's PHP Server Visibility dashboard provides an additional investigative tool to help security teams identify potentially overlooked PHP servers using indicators observed in unencrypted HTTP traffic, such as .php endpoints and PHPSESSID cookies. Analysts can then investigate whether these hosts are also receiving externally originated encrypted traffic, helping prioritize potentially exposed systems for further investigation.
The dashboard is not intended to provide a complete inventory of PHP servers. It can only identify systems exhibiting observable PHP-related indicators, and encrypted traffic or limited network visibility may leave some servers undiscovered. Instead, it acts as an assistant to existing asset discovery and threat-hunting workflows, helping analysts uncover potential shadow IT, investigate exposure, and identify systems that warrant closer examination, even after patching.
Detection rules for known php2shell exploit attempts
Vectra Match now contains rules to detect the PHP2Shell attacker behaviors when proper visibility is provided to the attacker traffic. They flag known exploit attempts in network traffic when that traffic is visible to us, so they catch attempts at the door, while the detections above catch what follows. An attempt is not a compromise. A match is a reason to look at that server, not proof that it was taken over. This is available for all Vectra Match customers.
The rules, by ET rule number:
- 2072548: ET EXPLOIT PHP php2shell Handler-mismatch Session Injection (CVE-2026-109619)
- 2072549: ET EXPLOIT PHP php2shell Multipart Header Amplification OOM (CVE-2026-109618)
- 2072550: ET EXPLOIT PHP php2shell Nested Empty File Control OOM (CVE-2026-109618)
- 2072551: ET EXPLOIT PHP php2shell Chunked Multipart Request without Content-Length (CVE-2026-109618)
- 2072552: ET EXPLOIT PHP php2shell Binary URL-Encoded POST for $_POST Corruption (CVE-2026-109618), commented out in the rule set, so off by default
- 2072553: ET EXPLOIT PHP php2shell Multipart Request without Content-Length (CVE-2026-109618)
- 2072554: ET EXPLOIT PHP php2shell Code Injection in Filename (CVE-2026-109619)
- 2072555: ET HUNTING PHP Generic Upload Progress Session Manipulation, a hunting rule, not an exploit rule, so treat a match as a lead
- 2072556: ET EXPLOIT PHP php2shell Excessive Multipart Part Count (CVE-2026-109618)
- 2072557: ET EXPLOIT PHP php2shell Excessive Empty Multipart File Controls (CVE-2026-109618)
What a compromised PHP server reveals about your resilience
The old measure of success was whether attackers get in. The better one is how far they get. Patching, a sound network design, splitting the network into zones, least privilege and knowing which systems carry your most important business processes all limit that distance. The network record can show whether anyone came through the door before it closed, and where they went next.
The three gaps are walked end to end in the Mind Your Gaps in the Age of AI-Powered Attacks white paper.