Home
PHP2Shell took six days to go from a leaked CVE number to CISA’s exploited list. The fix shipped ten hours after the first exploit tooling was seen scanning. A week later, FireCompass research across 1,000,000+ assets found that 65 percent of organisations still had at least one exposed application, and that nearly half of those exposures were invisible to the version check most teams used on day one.
None of this was new. Replace “PHP” with “Log4j,” “MOVEit Transfer,” “NetScaler,” or “Ivanti Connect Secure” and the sequence reads the same. The names change every few months. The pattern has not changed since 2021, which means it can be planned for.
The pattern, five years running
| Event | What it was | What happened | What it taught |
|---|---|---|---|
| Log4Shell, December 2021 (CVE-2021-44228) | Unauthenticated RCE in a logging library embedded in a large share of Java software | Mass scanning within hours of disclosure; organisations spent weeks finding where Log4j was, not patching it | The vulnerable component is not in the inventory; it is inside things that are |
| Spring4Shell, March 2022 (CVE-2022-22965) | RCE in the Spring Framework | Details leaked before the fix; exploitation attempts before most teams had a list of affected apps | The disclosure calendar is not yours to control |
| MOVEit Transfer, May 2023 (CVE-2023-34362) | SQL injection to RCE in a managed file transfer product | Exploited as a zero-day by Cl0p before the advisory; thousands of organisations breached through a single internet-facing product | One exposed system is enough, and the attacker already had the list |
| Citrix Bleed, October 2023 (CVE-2023-4966) | Session token leak in NetScaler ADC and Gateway | Patched systems stayed compromised because stolen sessions survived the patch | Patching is not the same as eviction |
| Ivanti Connect Secure, January 2024 (CVE-2023-46805, CVE-2024-21887) | Auth bypass and command injection in a VPN appliance | Exploited before disclosure; mitigations shipped before patches; CISA ordered agencies to disconnect | Interim mitigations and verification matter as much as the fix |
| regreSSHion, July 2024 (CVE-2024-6387) | Unauthenticated RCE in OpenSSH on glibc Linux | Millions of exposed instances; the question was again “which version is this” on hosts that do not say | Version fingerprinting is the first filter, never the verdict |
| PHP2Shell, October 2026 (CVE-2026-109618, CVE-2026-109619) | Unauthenticated RCE in the PHP runtime | Leak, then exploit tooling, then fix, then KEV in six days; 65 percent of organisations exposed a week later | All of the above, at once |
Four things are constant across every row.
The bug is in the runtime or the library, not in the application. Your application inventory, however good, is the wrong index. The question on day one is “which binary serves this,” and most CMDBs do not know.
Exploitation starts before the fix ships, and the fix is only the beginning. For PHP2Shell, the ordering was exploit tooling, then patch, then confirmed compromise, then KEV. For MOVEit, the breach came before the advisory. Planning for “patch within 30 days of release” plans for the wrong decade.
What the system says about itself is unreliable in both directions. Version headers are suppressed by hardening. Backported packages keep the old version string. Catch-all routes answer every probe. In FireCompass’s PHP2Shell data, a header check missed 48 percent of exposures and misflagged one in four of the rest.
The long tail is where the breach happens. Public telemetry showed the number of exposed PHP systems falling by two-thirds within days. The remaining third- the staging hosts and forgotten admin panels, and acquired applications- is the one attackers were still scanning a week later.
What a day-zero and day-one programme looks like
A programme for this class of event has seven parts. Most organisations have two or three. The gaps are usually in discovery, validation, and verification, which is exactly where PHP2Shell exposures survived.
1. A written guideline with decision rights and clocks
Write it before the next event, not during. The guideline names who declares a day-zero or day-one event, what triggers a declaration (a KEV listing, a vendor emergency release, a CVSS 9+ on an internet-facing runtime, credible exploit chatter), and what clock starts for each tier.
A workable tiering:
- Tier 0: exploited in the wild, internet-facing, in your stack. Inventory and exposure scan within 24 hours. Mitigate or patch within 72 hours. Verify within 7 days. Hunt for compromise in parallel.
- Tier 1: critical, no confirmed exploitation, internet-facing. Scan within 48 hours. Patch within 14 days. Verify.
- Tier 2: critical, internal only. Scan within 7 days. Patch in the next cycle with the exposure recorded.
Decision rights matter as much as clocks. Who can approve an emergency change outside the window? Who decides that a legacy application with no fix gets isolated rather than retired? Who talks to customers, the board, and the regulator?
2. An inventory that includes the assets you do not know about
The guideline cannot be executed against a list that is missing the assets attackers scan first. Day-zero inventory has to start from the outside: what is reachable on the internet, including subdomains, cloud instances, partner-facing portals, staging environments, and the appliances with embedded runtimes. Then reconcile against the CMDB and treat every difference as a finding in its own right.
This has to be running already. Discovery on the day of disclosure is a scramble; discovery that was running the week before is a filter.
3. The ability to scan for a specific exposure within a day
Within 24 hours of a Tier 0 declaration, you need a safe, repeatable check for the specific vulnerability that you can run across every discovered asset. The requirements, learned the hard way across every event in the table:
- Non-intrusive and production-safe, with a bounded request budget and early stop on errors, so that the scan itself is never the outage
- Fingerprint-based first (version headers, banners, diagnostic pages), because that is fast and covers the majority
- Control checks against known false-positive shapes: catch-all routes, single-page applications, soft-404s, look-alike version strings from the application layer
- Backport awareness, so that distribution-managed hosts are flagged for package confirmation rather than marked critical on the version string
- Evidence attached to every verdict, so that remediation queues receive findings and not guesses
4. The ability to validate, because fingerprinting is not enough
This is the capability most programmes lack. The scan in Part 3 will return three populations: confirmed exposed, confirmed safe, and unknown. For PHP2Shell, the unknown population was nearly half of the real exposures. Unknown is not a result a CISO can take to a board, and it is not a result a remediation team can act on.
Validation means establishing, with evidence, whether the vulnerable condition is actually present and reachable: behavioural checks where the version is hidden, package confirmation where a backport is possible, and, where the risk justifies it, controlled exploitation to confirm the exposure is real and to see what it chains to. That last point is the one that changes priority. An exposed PHP runtime on a brochure site and an exposed PHP runtime on a host with a route to the payment network are the same CVSS score and very different emergencies.
5. A mitigation catalogue and a remediation workflow with owners
For every runtime and product class in your stack, keep a pre-written mitigation card: the interim controls that exist, what each stops, what each breaks, and how to apply it in a way the application cannot override. For PHP, that card would have had session.upload_progress.enabled = 0request body limits, the memory_limit trade-off, and a WAF rule, with a note that none is a complete fix. Writing that card on the day costs hours you do not have.
The workflow is a shared tracker per affected asset with owner, status, target date, and evidence, and a standing rule that a legacy asset with no fix gets a documented decision (migrate, isolate, retire) rather than silence.
6. A hunting playbook, because the fix does not evict anyone
Citrix Bleed taught the industry that patched systems stay compromised. For every Tier 0 event, hunting runs alongside patching: process lineage from the affected runtime, worker crashes and respawns, outbound connections from processes that should only answer inbound, persistence in the usual places. If evidence is found, the host is a compromise, not a patch ticket.
7. Verification, drills and metrics
Closure is verified by a rescan after the restart, with the result recorded per asset. Then measure the programme itself: hours from declaration to complete inventory, hours to first scan across all assets, percentage of assets that returned a definitive verdict rather than unknown, days to verified closure, and the number of assets discovered during the event that were not in the inventory before it. Drill it twice a year against a past event. The metrics from the drill are the budget case for the gaps.
Where FireCompass fits
FireCompass is an agentic AI penetration testing platform, and the programme above maps onto what its agents already do in sequence.
Discovery agents find the unknown unknowns. FireCompass maintains an outside-in view of an organisation’s internet-facing assets as a standing capability, not a day-of-disclosure exercise: domains, subdomains, cloud assets, APIs, staging hosts and the undocumented admin panels. On the day a PHP2Shell is declared, the asset list already exists, and the scan in the next step runs against all of it rather than against the subset the CMDB remembered.
The day-one agent checks for the specific exposure, safely, at scale. For PHP2Shell, FireCompass released its exposure scan within one day of disclosure and ran it across 1,000,000+ assets: at most nine ordinary web requests per application, control checks for catch-all routes and soft-404s, backport-aware verdicts, no exploitation, and the exact request and response signal attached to every result. Day-one CVE validation for new disclosures is a standing platform capability, so the next event gets the same treatment on the same clock.
The pentest agents confirm what is real and show what it chains to. Where the day-one agent returns unknown, or where the risk justifies proof, the FireCompass pentest agents validate the runtime directly and, under scoped authorisation and safe-exploitation controls, demonstrate what an attacker could reach from it: credential material, lateral movement, the internal target behind the exposed host. Every finding carries a proof of exploit. In the PHP2Shell research, this is how the 48 percent of hidden exposures were confirmed rather than reported as unknown, and how one in four raw flags were cleared before they reached a remediation queue.
Verification and the record. Rescans after each fix confirm the new version or fixed behaviour is live, and the evidence trail per asset is what goes to the auditor. For organisations that need it, FireCompass runs the remediation programme alongside the customer’s teams: advisory support, a dedicated testing point of contact who tracks each finding to closure, and a dedicated customer success executive working with security, DevOps and application owners through verified closure.
The programme in Section 2 is seven parts, and most organisations staff two. FireCompass automates discovery, day-one scanning, validation, and verification as one sequence, so the parts that were missing when PHP2Shell arrived are in place before the next one does. The agents are agentic and autonomous, with an expert in the loop, and the platform holds false positives under 2 percent. FireCompass AI pentesting agents ranked #1 on HackerOne in Q3 2026.
The next one
There is a CVE number reserved right now for a runtime you run, in a disclosure queue you cannot see, with a researcher who used an AI model to find it in a fraction of the time it would have taken in 2021. The only variable you control is whether, on the morning it leaks, you are building an inventory or reading one.
