PHP2Shell was exploited before the patch. Expect more of it.

On October 17, an Amazon honeypot captured exploitation of two critical vulnerabilities in PHP’s core. The fix arrived on October 21.

Threat actors had four days inside the window before defenders knew there was a vulnerability to patch.

This pattern is becoming normal. In 2001, defenders had roughly a month between a patch and a worm. In 2018, the average window was about two months. Today, Mandiant puts the mean time to exploit at minus seven days.

The patch is no longer the first defensive move. For many vulnerabilities that matter, exploitation has already started by the time the fix becomes public.

Twenty-five years of shrinking warning

Vulnerability response used to follow a predictable order. A flaw was disclosed, a patch was released, and threat actors built an exploit.

That order has broken down.

The chart and table below show the changing window across seven vulnerabilities that defined their period. A positive number means defenders had the patch first. A negative number means exploitation began before the fix or disclosure.

Dates are based on the sources in the table below. SQL Slammer and Citrix Bleed are approximate.

• ‍2001 to 2003, the worm era. Code Red and SQL Slammer moved quickly once exploitation began. SQL Slammer infected about 75,000 hosts in ten minutes. Both, however, targeted vulnerabilities that had been patched weeks or months earlier. At the time, patching before exploitation was a realistic defense.‍
• 2017, the leaked-exploit era. EternalBlue was patched in March 2017. The Shadow Brokers published a working exploit the following month, and WannaCry began spreading on May 12. Organizations that patched during the first eight weeks were protected. The window was still positive, but the exploit no longer needed to be discovered from scratch.‍
• Since 2021, exploitation has often preceded disclosure. Log4Shell was being tested on December 1, eight days before it became public. MOVEit was used for data theft four days before Progress disclosed the vulnerability. Citrix Bleed was exploited for roughly six weeks before the fix, then moved into mass exploitation within days of a public proof of concept.

PHP2Shell follows the same pattern. Patching quickly still matters. It no longer covers the whole response.

What PHP2Shell cost

The first cost of PHP2Shell was not a breach. It was organizations switching themselves off, because there was no safe way to wait for the patch.

• Governments and institutions went dark. On October 21, government websites in Finland, the Netherlands and France were taken offline. In Austria, universities, the steel maker voestalpine and the Burgenland state portal went down, and the hosting provider Anexia pulled every managed PHP service 15 minutes before the patch because the known workarounds did not protect them. In Belgium, DPG Media sites, the VUB, several hospitals and the national cyber security center's own website went offline as a precaution.
• Attackers were scanning before the fix existed. Amazon saw attempts on October 17. By patch day, Hadrian reported exploitation "in the wild at scale", and researchers tied some attempts to a Mirai botnet. No successful compromise had been confirmed publicly at the time of writing, but watchTowr's view was blunt: "we don't expect that will last long."
• The exposure is enormous, and some of it is permanent. Palo Alto Networks counts over 22 million PHP instances exposed online, and Silas Cutler puts the hosts that are actually vulnerable at about 1.3 million. PHP 8.1 and older get no official updates, and Cisco Talos estimates around half of PHP systems may never be patched.
• Defenders became targets too. Within a day, AhnLab counted a hundred GitHub repositories named after the bug. Some were fake exploits. Others were one-line "fix" scripts posted by strangers that ask to be run as root.

This is what a negative window looks like in practice. When attackers are already in before the fix, the choices left are to go offline, or to patch and hope you were not already compromised.

Mean time to exploit is now negative

The 2023 figure excludes 15 outliers. Including them produces a figure of 47 days.

In seven years, the average warning period moved from roughly two months to a week of head start for threat actors.

Mandiant describes its figures as conservative, which means exploitation may begin even earlier than the data shows. The type of vulnerability being exploited has changed too. In 2023, 70% of the exploited vulnerabilities Mandiant tracked were zero-days.

The operational consequence is direct. When a critical vulnerability affects an internet-facing system, teams must investigate activity before the disclosure date, not only after the patch arrives.

Why the window keeps closing

Several forces are compressing the time available to defenders.

• ‍A patch can reveal the vulnerability. A fix identifies the code that needed changing. Comparing patched and unpatched versions has been standard practice for years, and public repositories make the process faster. A code change can reveal the vulnerable logic before the vendor advisory is published.‍
• The internet is scanned continuously. Finding every exposed instance of a product once took days. Today, threat actors can identify vulnerable systems at scale within hours. Once an exploit works, it can be directed at thousands of systems immediately.
• ‍Exploits have commercial value. Initial access brokers and ransomware groups pay for reliable access to exposed systems. That makes edge devices, file-transfer platforms, VPN appliances, and web runtimes worth researching. Google counted 90 zero-days exploited in 2025, with 48% affecting enterprise software and appliances. That was a record share.
• ‍AI is reducing the cost of vulnerability research. The teams that reported PHP2Shell both used AI models. The vulnerabilities had been present in PHP’s code since 2012. AI did not replace human direction, but it shortened the work required to read code, test hypotheses, and adapt an exploit.

How AI is changing exploit discovery

AI can now take on much of the slow work involved in finding and weaponizing a vulnerability. The remaining advantage is choosing the right place to start. That advantage is shrinking.

PHP2Shell shows how the division of labor is changing.

Researchers at Calif began with a hypothesis based on PHP research from 2004 and PHP’s behavior when it runs out of memory. They directed the model toward that part of the code. The model then read the source and traced the flaw.

Wiz found its first PHP vulnerability with Gemini 4 Argon and GPT-5.6 Sol on August 19, 2026. The team confirmed unauthenticated code execution against Drupal the next day and WordPress the day after. According to Wiz’s analysis, the models helped adapt a working exploit across PHP versions and applications in hours. The team wrote that “a single researcher completed in a week what previously would have taken a world-class team months of work.”

Human review remained part of the process. In earlier research into a different PHP vulnerability, Calif gave a model about twenty historical PHP advisories, asked it to identify reusable patterns, and used it to produce an exploit. People selected the source material, directed the investigation, and verified the result.

That distinction matters. The tasks models handle well are the parts that used to consume the most time: reading large codebases, finding a known mistake in a new location, and turning a crash into reliable code execution across versions.

The harder task is forming the initial hypothesis. Which part of the code deserves attention? Which old advisory contains a useful pattern? Which unusual behavior points toward a new vulnerability?

Today, that judgment still depends on deep expertise in a particular codebase. There are only so many people with that expertise.

The constraint is already weakening. Google’s Big Sleep agent found an SQLite vulnerability in 2025 that Google said was known to threat actors and close to exploitation. No human hypothesis started that investigation.

As models need less direction, vulnerability research will depend less on the number of specialists available and more on the compute behind the research. Defenders gain the same capability, but they face an uneven workload. They must address every relevant vulnerability. A threat actor needs only one.

What security teams should expect next

1. Exploitation before disclosure will become routine for internet-facing software. VulnCheck found that 28.96% of known exploited vulnerabilities in 2025 were exploited on or before the day their CVE was published. That figure was 23.6% in 2024. The proportion is likely to keep increasing for edge devices, file-transfer platforms, and web runtimes. One vulnerability in an exposed product can create access to millions of systems.
2. The next PHP2Shell may sit in a library nobody knows they use. Days after PHP2Shell, researchers reported “Node2Shell,” CVE-2026-111497. The vulnerability was in Google’s Brotli decompression library. Node.js, Bun, several Linux distributions, and two Python packages bundled the library. The Python fixes shipped without an advisory, which meant vulnerability scanners had no public identifier to flag. Shared libraries sit beneath thousands of products. Threat actors only need to find one exposed implementation first.
3. Vulnerabilities will arrive in families. Once a vulnerability class becomes public, models can search similar codebases for related flaws. Calif has already applied this approach to historical PHP advisories, and Wiz adapted its PHP2Shell exploit across applications in hours. A major disclosure may therefore produce a cluster of related vulnerabilities in other languages and runtimes. Defenders and threat actors will be searching for them at the same time.
4. Embargoes will shorten and leak more often. The PHP2Shell embargo leaked through several channels before the fix. CVE IDs appeared with an incorrect score, a demonstration video was published early, and one vendor shipped a fix ahead of schedule. Every additional party involved in a pre-disclosure process creates another route for information to escape. Regulators are responding. CISA’s BOD 26-04 gives US federal agencies three days to fix critical known exploited vulnerabilities, down from two weeks.
5. Defenders currently have an AI advantage, but it will narrow. The strongest models are still concentrated among vendors and well-funded research teams. That is why defenders found PHP2Shell before it became public. Open models are improving, and they can increasingly run locally. The advantage will belong to the teams that can identify and act on a vulnerability first. That lead will become harder to keep.

What defenders should do now

If exploitation can begin before a patch exists, patching is only one part of the response. Teams also need to investigate the period before disclosure.

1. Hunt backward when a critical edge vulnerability is disclosed. Patch the exposed system, then review logs from before the disclosure date. For PHP2Shell, that means investigating activity from at least October 17, not only October 21.
2. Track bundled libraries as part of your software inventory. Node2Shell shows why the important question may be, “Do we use Brotli?” An accurate inventory should connect applications to the libraries they include, even when those libraries aren't obvious to the teams running the application.
3. Reduce internet exposure. Every exposed administration panel, file-transfer server, or VPN appliance creates another opportunity for exploitation. Put management interfaces behind access controls and remove services that no longer need to be public.
4. Prepare for the period before a patch exists. Decide in advance whether you can disable a module, apply a web application firewall rule, or take a service offline. Define who can approve that decision outside business hours.
5. Detect post-exploitation activity. Exploits change. The activity that follows is more consistent. A web server spawning a shell, a new file appearing in a web directory, or an unexpected outbound connection from an appliance can all indicate compromise before a vulnerability has a name.
6. Measure patching in days for known exploited vulnerabilities. CISA now expects US federal agencies to fix critical known exploited vulnerabilities within three days. That is a reasonable target for internet-facing systems in any organization.