The 48-Hour Exploit Window: Nation-State Tempo for Everyone

A proof-of-concept exploit lands on GitHub at 11pm on a Tuesday. Forty lines of Python, from a researcher who did everything right: coordinated disclosure, vendor patch shipped, ninety days elapsed. By Wednesday afternoon it has been forked two hundred times. By Thursday morning it is being sprayed at every host on the public internet that returns a matching fingerprint. Nobody chose your company. The scan chose it.

Wednesday morning, somebody in your security channel posts the advisory and asks the only question that matters: do we run that? And the honest answer, if your team is like most teams at your size, is "give me two days."

Two days is the whole window. CrowdStrike's 2026 Threat Hunting Report found that 88% of the exploitation it observed against vulnerabilities with a public proof-of-concept began within 48 hours of that PoC being published. If you want to know how fast attackers exploit vulnerabilities in 2026, that is the answer, and it is not a patching statistic.

Organisations that fail the 48-hour exploit window rarely fail at the patching step. For most internet-facing web software, applying a vendor fix to a system you know you run is a change ticket and an afternoon. There are real exceptions, and you will know yours: clustered databases, vendor-controlled appliances, anything with a certification dependency or an OT footprint. But those are usually a scheduling problem you can see coming. What is slow is the prior question: do we run that, where, and is it reachable from the internet? Answering that from a stale inventory commonly takes days rather than hours, and by then the only question left is whether anyone got in.

The 48-hour window is not a patching problem. It is a knowing problem.

What CrowdStrike Actually Measured (and What It Does Not Say)

The number is real and it is worth stating with its full provenance, because it gets repeated without qualifiers and the qualifiers are load-bearing.

CrowdStrike released its 2026 Threat Hunting Report at Black Hat on 3 August 2026. Covering January to June 2026, it found that 88% of observed exploitation against vulnerabilities that had a public proof-of-concept occurred within 48 hours of that PoC being released.

Three qualifiers matter. It is CrowdStrike telemetry, reflecting what their sensors saw across a customer base that skews toward organisations already running endpoint detection. It is scoped to vulnerabilities with a public PoC, not to all CVEs: thousands are published monthly with no working exploit code and no observed exploitation ever. And the 48 hours runs from PoC release, not from CVE publication and not from patch availability. Those three dates can be weeks apart or, increasingly, the same day.

Two cases show what the compressed timeline looks like in practice. In the React2Shell activity, CrowdStrike's OverWatch hunters responded to more than 800 hunting leads across more than 80 victim organisations in four days. And with CVE-2026-31431, disclosed on 29 April alongside a researcher's public PoC, CrowdStrike detected widespread deployment of the exploit the following day, with roughly 94% of first-24-hour events showing behaviour consistent with testing derived directly from the public code. That last detail is the tell. The early wave is not skilled adversaries developing custom exploits. It is the published script, run at scale, against everything.

Which raises the obvious question: is this a 2026 anomaly, or the end of a trend line?

The Window Has Been Closing for Eight Years

It is a trend line, and this is the section for your board deck, because a single scary statistic invites the response "well, that's one report." A slope does not. Here is the slope.

Read the first row again. Two months was enough time for a change advisory board, a maintenance window, and somebody's holiday. The third row is enough time for one working day and a night's sleep.

The fourth row is worth reading slowly, because the minus sign invites a misreading and you will probably be asked about it. Mandiant's estimated -7 days is measured against patch availability, not against public disclosure. It does not say exploitation starts a week before anybody knows the vulnerability exists. It says that by the time a fix is on offer, exploitation has on average already been under way for about a week. Mandiant also publishes it as an estimate, and it is worth repeating it that way. The direction of the series is the part not in dispute: every revision of this measurement for eight years has moved the same way, and none of them moved back.

Now put a 30-day patch SLA next to that slope.

Most mid-market vulnerability management policies still specify 30 days for critical findings. That language was reasonable when it was written, somewhere around 2018 to 2020, and it has quietly become fiction. A 30-day window against a 48-hour exploitation curve is not a slow policy. It is a policy describing a threat environment that no longer exists. If yours still says 30 days, the question at the next review is not the cadence. It is whether the document describes reality at all.

The other thing that changed is who is operating inside that window.

Three Different Adversaries Are Now Inside the Same Window

The headline version of this story is "nation-states are coming for mid-market." That is not what the evidence supports, and a CISO who reads threat intel for a living will stop trusting you the moment you say it. The accurate version is more interesting. Three distinct tiers of adversary now operate at the same tempo, for three different reasons.

Tier three is the one that will actually knock on your door. Tier one is the one that makes the headlines. Tier two is the one that changed this year, and it is the reason the language people reach for has stopped being accurate.

Which brings us to the belief most mid-market security programmes are quietly built on.

Why "We're Too Small to Target" Stopped Being a Strategy

Almost every security leader at a 200 to 2,000 person company has thought some version of this. It is not stupid. For a long time it was mostly true, in the narrow sense that no analyst at a foreign intelligence service was building a dossier on your company. The problem is that the sentence assumes somebody is choosing.

Mass internet fingerprinting removed the choosing. Services like FOFA, Shodan and Censys index the reachable internet continuously by banner, header, favicon hash, JARM signature and TLS certificate. An operator with a fresh PoC does not ask "who is worth attacking?" They ask "who returns this fingerprint?" and get a list back in seconds. Selection is by signature match. These services do expose filters for country, ASN and organisation, so a motivated operator can narrow by geography or sector. What they cannot do is rank you by how interesting you are, and in mass exploitation nobody bothers to try. Your headcount and revenue are not what puts you on the list.

A second mechanism cuts the other way. Mid-market companies hold credentials, API keys and integration access into much larger customers, which makes you a route rather than a destination. The June 2026 Mastra compromise is the shape of it: a malicious dependency was added across more than 130 packages in the Mastra AI framework ecosystem after a former contributor's npm account, whose access had never been revoked, was hijacked. CrowdStrike attributes that activity to the DPRK-nexus actor it tracks as STARDUST CHOLLIMA; Microsoft attributes the same campaign to the cluster it calls Sapphire Sleet. Note the mechanism honestly, because it is the transferable lesson: the entry point was not a clever exploit, it was stale access that nobody had cleaned up. Compromise something small and widely trusted, inherit everything downstream. If you sell to enterprises, your value to an attacker is not your data. It is your position.

Then there is the asymmetry. A 40,000-person company facing a fresh PoC has a threat intel function, an asset inventory somebody owns full time, and a bridge call at 7am. A 400-person company has one or two people who can answer "do we run that", and one of them is on leave. The tempo is identical. The capacity to respond to it is not. That, not target selection, is the real mid-market disadvantage.

So if the window is 48 hours and you are inside it, what does a real response look like?

The 48-Hour Response, Honestly Costed

Here is the sequence, hour by hour. Mark which steps your team could complete on the stated clock.

Only one of those five steps has a vendor on the other end of it. The rest are questions about your own estate, and there are two honest ways to get better at them. Option A is to reduce time-to-answer: maintain a current, evidenced inventory of what you run and what is externally reachable. Option B is to reduce blast radius: segmentation, zero trust, removing management interfaces from the public internet entirely. Option B is the more permanent fix and an 18-month capital programme with a business case, a vendor selection and a migration plan. Option A, weighed honestly, looks like this.

Both belong on the roadmap. Only one starts on Monday.

Which makes the state of your inventory a question worth answering before the next advisory rather than during it.

Can You Answer These in Thirty Minutes?

Run this against your own estate. Every item is either true or it is not. There is no partial credit, because in the first two hours of an advisory response, "mostly" is the same as "no".

Very few teams at this size tick all eight, and the ones that do are usually the ones who have already been through a bad advisory weekend. We are not going to put a percentage on that, because we have not measured it and neither has anyone else who quotes one at you.

That is not a failure of diligence. It is what happens when the estate grows faster than the documentation, which is what estates do. Acquisitions arrive with infrastructure. Marketing stands up a landing page on a subdomain. A contractor leaves a staging environment running. None of it is negligence and all of it is invisible.

But every unticked box is hours added to a 48-hour clock, and the clock does not care why.

Where an Independent Test Fits (and Where It Does Not)

This is the part where a vendor tells you their product solves the problem. Ours does not.

What an independent test produces is the thing that makes steps one through three faster: an evidenced record of what was tested within your declared scope, what was found reachable, and what findings were produced against it, captured at a known date by somebody other than you. When a new advisory lands, that record tells you which product classes and surface areas were in scope, what the test produced against them, and where the boundaries of that assessment sat. That narrows the search considerably. It is the pre-work, not the answer, and its value is precisely that it exists before the advisory rather than being assembled during it.

Be precise about the bound, because this is exactly where vendors, ours included, are tempted to overclaim. A scoped test tells you the truth about the estate you declared. It is not a discovery service that surfaces the subdomain nobody remembers provisioning, and a provider implying otherwise is selling you a reassurance you did not actually buy. CyberOrbit handles the systematic 80%: the externally reachable surface, scoped and run by us, tested the same way every time, evidenced end to end, and independently signed. Novel business-logic attacks and deep configuration review still need a specialist working alongside it. Getting to an accurate scope in the first place is work you own, and the checklist above is where that starts.

The test also produces something a self-run scanner structurally cannot: a signed, third-party attestation about a defined scope at a defined time, which is what auditors, cyber insurers and enterprise procurement teams ask for. A dashboard you host yourself, however current, does not answer the question "was this assessed by an independent qualified party, and when".

The cadence question follows from the compression. Because the interval between significant advisories is now measured in weeks, the useful question is no longer "when is our annual test scheduled". It is "is our picture of the attack surface current enough to act on today". PCI DSS 11.4 already encodes this: testing at least every 12 months and after any significant change. That second clause was always the more demanding one, and significant changes now arrive faster than an annual cadence can absorb. We have written separately on what CTEM means for testing cadence and what PCI DSS 11.4 now requires, and as we saw with the August Fortinet advisories, the scoping question tends to arrive before the patching question does.

What to Do This Week

Three things. None of them require budget approval.

1. Pull your vulnerability management policy and read the stated patch window out loud. If it says 30 days for critical, it is describing 2018. Whether you can move it is a separate conversation. Knowing that it is fiction is this week's job.

2. Run the checklist above against your own estate and count the boxes. Do not grade generously. Whatever the number is, that is your real starting position, and it is more useful than any maturity score you will pay a consultancy for.

3. Pick the single unticked box that cost you the most hours in the last advisory you responded to, and fix that one first. Not the most important one in the abstract. The one that actually burned your Wednesday.

The next PoC is already written. The only variable you control is how long it takes you to find out whether it applies to you.

Frequently Asked Questions