Time to Exploit Is Now Negative: PHP2Shell Lessons

PHP2Shell showed that the time to exploit a critical flaw is now shorter than the time most organisations need to find out whether they are exposed. That makes it a visibility problem before it is a patching problem.

Key Takeaways

On PHP2Shell, exploit attempts began before a patch existed. The time to exploit a critical flaw is now shorter than the time most organisations need to confirm whether they are exposed.
ASD’s ACSC’s first instruction was to find where PHP runs. Knowing where you are exposed, and which systems matter most, is now the only reliable head start.
Record patch volumes are draining operational budgets, and end-of-support platforms have become measurable attack surface.
Four things separate teams that move within the hour from those that move within the week: a runtime-level inventory, agreed business criticality, near-real-time telemetry and a pre-agreed emergency change path.

At 14:00 UTC on 21 October, the PHP project released fixes for two critical flaws in the PHP runtime. In Sydney it was 1am. Within 20 minutes, researchers were reporting active exploitation attempts against both flaws (The Hacker News, 2026). That figure made the headlines, and it is the flattering version. On PHP2Shell, the real time to exploit was negative.

The two flaws, CVE-2026-109618 and CVE-2026-109619, are both rated 9.2 under CVSS v4.0 and allow unauthenticated remote code execution with the web worker’s privileges (Rapid7, 2026). Any PHP installation serving web requests is at risk, whether it runs PHP-FPM, Apache mod_php, php-cgi or another server interface.

The coordinated disclosure came apart a day early. The CVE identifiers leaked online on 20 October. Around 20:00 UTC that evening, one of the research teams mistakenly posted a video of its working proof of concept (The Hacker News, 2026), roughly 18 hours before a fix existed. An exploit attempt against both flaws had already been logged on 17 October, four days before disclosure (The Hacker News, 2026). By the time the patch landed, government services and education systems in the Netherlands had gone offline as a precaution (The Hacker News, 2026). Closer to home, cyber.gov.au and several other federal websites were taken offline that night while work was done to mitigate the risk (iTWire, 2026).

Time to exploit has gone negative

For the past year, Orro’s working assumption has been that attackers need about eight hours to turn a published patch into a working exploit. AI tools let them compare patched and unpatched code and find the underlying flaw faster than most change advisory boards can meet. Eight hours felt aggressive when Orro set it. PHP2Shell suggests it was generous.

AI now works on both sides of a disclosure. The PHP2Shell flaws had sat in the runtime for more than a decade, and researchers say AI models let one person do in about a week what would otherwise have taken a team months (The Hacker News, 2026). Attackers have the same tools. Within days of disclosure, researchers reported a PHP2Shell compromise at a European government entity. Attackers reached password hashes and multi-factor authentication secrets within two hours, and their command patterns suggested an AI agent was doing the work (The Hacker News, 2026). On 26 October, CISA added both flaws to its Known Exploited Vulnerabilities catalogue (BleepingComputer, 2026).

The longer trend points the same way. Mandiant’s M-Trends 2026 estimates the mean time to exploit at negative seven days, meaning exploitation now begins, on average, before a patch exists (Mandiant, cited in Cloud Security Alliance, 2026). When Orro examined the recovery-denial economy in August, the story was attackers industrialising everything after initial access. The steps before it are industrialising too.

It is worth staying measured. Rapid7 found the early public exploits worked only under narrow conditions and were not broadly reliable, and urged organisations to treat that difficulty as a window to patch, not a reason to wait (Rapid7, 2026). That was the right reading. The window existed, but only for days, and it was never one anyone could schedule.

Evidence Snapshot

On the timeline

An exploit attempt against both PHP2Shell flaws was logged on 17 October, four days before disclosure (The Hacker News, 2026)
CISA added both flaws to its Known Exploited Vulnerabilities catalogue on 26 October (BleepingComputer, 2026)

On the trend

Mean time to exploit is estimated at negative seven days: exploitation now begins, on average, before a patch exists (Mandiant, cited in Cloud Security Alliance, 2026)

On the scale

PHP runs on 69.2% of websites whose server-side language is known (W3Techs, 2026)
Microsoft’s October 2026 Patch Tuesday addressed a record 1,411 vulnerabilities (BleepingComputer, 2026)

The first instruction was to find it

ASD’s ACSC issued a Critical Alert on 21 October, hours before the fixes were released (ASD’s ACSC, 2026). Its first instruction to Australian organisations was to identify where PHP runs in their environments. Monitoring PHP’s guidance came second, preparing to patch came third, and watching PHP applications for malicious activity came fourth. For most of that day, finding PHP was the only useful action available. When the time to exploit is negative, knowing where you are exposed is the only head start left.

It is harder than it sounds. PHP is used by 69.2% of websites whose server-side language is known (W3Techs, 2026), and that is only the visible part. It sits inside content management systems, vendor appliances, container images and internal tools that never advertise it. Updating WordPress or an application framework does not update the PHP runtime beneath it, and Linux distributions can ship the fix under an old-looking version number (The Hacker News, 2026). An inventory built on version strings can be wrong in both directions.

The organisations that came through the night well could answer three things within the hour: where PHP runs, which of those systems face the internet, and which of them the business cannot do without. They spent the early hours patching in a sensible order. Others spent them discovering. When exposure cannot be confirmed quickly, switching a service off is the only control left. It is the same gap this edition opens with in The Network Is Up. The Business Is Down.: infrastructure can look healthy while nobody can say what the business depends on.

The cost nobody budgeted for

PHP2Shell landed on top of an already heavy month. Microsoft’s October Patch Tuesday alone addressed a record 1,411 vulnerabilities (BleepingComputer, 2026). That is one vendor, before Linux distributions, network firmware, browsers and every application with its own release cycle. Each critical item competes for the same people, maintenance windows and change approvals.

In conversations with security and infrastructure leaders, the pattern is consistent. The continual emergency effort is draining operational budgets. Overtime, out-of-hours change and repeated regression testing come out of the run budget, and new projects are being pushed back to absorb it. Accountability is sharpening at the same time. When a breach traces back to a known, unpatched vulnerability, insurers and the business will look to IT first.

Tech debt is now attack surface

PHP2Shell turned end of support from a housekeeping item into a live exposure. PHP 8.1 and older no longer receive routine upstream updates; for this incident, the project supplied limited source backports for 7.4, 8.0 and 8.1 (Rapid7, 2026). That was a courtesy in an emergency, not a support model. Yet more than a third of PHP websites still run version 7 or earlier (W3Techs, 2026). And PHP 8.2 reaches end of life on 31 December 2026 (The Hacker News, 2026), so many teams patching 8.2 this month are patching a branch with weeks of support left.

The wider pattern matters more than PHP. Every platform that falls off support carries flaws that will never be fixed. Those flaws were once protected by obscurity and the effort needed to find them. AI is removing both. Long-buried is no longer the same as safe.

There is an upside. This is forcing honest conversations about tech debt that many organisations have deferred for years. Retiring an unsupported platform is now a security decision with a visible risk attached, and that makes it easier to fund.

Feeling behind is a detection problem, not an effort problem

In Orro’s conversations with security leaders, one line comes up more than any other: it does not matter what we do, we are still behind. Part of the reason is volume. Part of it is detection. As time to exploit shrinks, more attacks arrive before a fix exists, and detection has to carry more of the weight.

Many tools rely on indexes of known events and patterns. New attack behaviour, increasingly shaped by AI, can be different enough not to trip them. When leaders ask why their tooling did not flag something, the answer is often that the pattern changed. Rapid7 made a related point about PHP2Shell: the absence of relevant log entries is not proof that a server is safe (Rapid7, 2026).

Severity scores do not settle prioritisation either. Both PHP2Shell flaws scored 9.2, and so did plenty of other findings in the same month. When everything is critical, the score stops being a ranking. What separates the urgent from the merely severe is reachability, business consequence and what is actually happening on the system right now.

Make time to exploit a decision, not a guess

None of this is a tool problem with a tool answer. It usually means rethinking architecture and process so the organisation can see and act quickly. Orro’s earlier piece, Beyond the Scan, covers how exposure management turns that into a continuous programme. In practice, four things separate the teams that move within the hour from those that move within the week.

The first is a current inventory that reaches the runtime and package level, including software that vendors bundle into appliances and images. The second is an agreed view of business criticality, settled before the incident, so ranking exposure is a lookup rather than a debate at 1am. The third is near-real-time telemetry from the systems that matter, watched by people who know what normal looks like there. The fourth is a pre-agreed fast path for emergency change: who can approve taking a service offline, against what criteria, and how quickly it comes back.

With those in place, time to exploit stops being a number you hope to beat and becomes a constraint you plan around. Patch speed still matters. It is simply the last step in a sequence that has to start much earlier.

The patch is out. You are already exposed.

PHP2Shell will not be the last disclosure where the time to exploit outruns the patch cycle. As exploitation reaches machine speed, the harder question is how a human stays meaningfully in the loop, and Orro takes that up in Human in the Loop Is a Promise You Can’t Keep at Machine Speed.

Find your exposure before the next disclosure

If PHP2Shell exposed gaps in what you run on unsupported platforms, or in what your logs can tell you, The Cyber Action Year Readiness Checklist works through ASD’s critical actions on replacing legacy technology, best-practice event logging and preparing for AI-enabled threats. If you want to talk through where your own exposure sits before the next disclosure, Orro is happy to help.

GET THE CYBER ACTION YEAR READINESS CHECKLIST

Eight Hours Was Optimistic