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.
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.