Exposure validation when the exploit arrives in hours

The gap between a CVE going public and a working exploit shrank from 756 days to minutes. Weekly scanning and a CVSS-ordered queue no longer keep up with that clock.

· #exploitability · #exposure validation · #CTEM · #AEV

Exposure validation is the confirmation, with evidence, that a discovered exposure can be exploited on the asset where it was found, in the state that asset is in. It answers what a scan leaves open: out of thousands of queue items, which ones have an open path right now. Gartner named the market category for this practice on 24 March 2026, under the label adversarial exposure validation (AEV).

The adversary's clock went from 756 days to minutes

756 days in 2018. Roughly 32 days by 2022. Around 5 days by late 2023.

That is the interval between a flaw being disclosed and a working exploit existing, in the series the Cloud Security Alliance published on 25 April 2026, in The Collapsing Exploit Window: AI-Speed Vulnerability Weaponization.

What changed in kind over the past year sits in the same paper. A language model writes working proof-of-concept code for a published CVE in ten to fifteen minutes, at about one dollar per attempt. CVE-Genie, an experiment cited there, reproduced 51% of the 2024 and 2025 CVEs with a functional exploit at 2.77 dollars each. Work that used to require a researcher with weeks of free time now fits on a prepaid card.

The more uncomfortable number comes from another house. In State of Exploitation 2026, dated 21 January, VulnCheck found that 28.96% of the vulnerabilities with observed exploitation in 2025 were already being exploited on or before the day their CVE was published. The prior year's figure was 23.6%. For close to a third of cases, disclosure day already arrives late.

And volume followed. The FIRST forecast released in June 2026 points to roughly 66,000 CVEs for the year, driven in good part by AI-assisted discovery on the research side. More flaws published each month, exploited faster, against the same team as always.

That clock can be read from the inside. ThreatSensor tracks the CVEs that already carry a signal of exploitation, and the cut by publication year shows the curve turning. Between 2020 and 2025, somewhere between 29% and 44% of them showed up exploited within five days. In 2026 it is 62%. The share already being exploited on publication day went from 24% in 2025 to 52% in 2026.

One caveat before anyone makes it for us: 2026 is a year in progress, and a recently published CVE has not had time to accumulate late exploitation, which pushes the near end up. The distance from the six previous years stays far too large for that to be all of it.

What scheduled scanning can actually answer

Scheduled scanning answers an inventory question: what existed in the estate the last time the scanner ran. The question is legitimate. The answer carries the granularity of the cycle, seven days on a weekly scan, thirty on a monthly one.

While exploits took weeks to appear, that rounding was tolerable. With exploits shipping in hours, Monday's report describes a state that changed before anyone opened the file.

There is a second effect, quieter than the first. The PDF freezes the queue at the moment it was generated. If a medium-scored CVE enters an active campaign on Wednesday, the document circulated on Monday still shows that item at position 400, and a team working top down will not reach it before the next cycle. The ordering ages faster than the content.

The exposure window measures that distance in hours or days, per asset. When the estate median is a week, every new asset handed the adversary six days of head start. No amount of prioritization recovers that delay afterwards.

Why a CVSS-ordered queue gets worse as volume grows

CVSS measures technical severity under conditions ideal for the attacker. It says nothing about the probability of anyone trying, or about your environment. With 66,000 CVEs forecast for 2026, sorting by theoretical severity places tens of thousands of candidates in a queue whose order bears little relation to what will be used against you.

The slice that matters is small and does not coincide with the top of that queue. VulnCheck identified 884 vulnerabilities with first evidence of exploitation in 2025, spread across 518 vendors and 672 products, while CISA catalogued 245 in the same period. Between a forecast of 66,000 publications and a few hundred with observed exploitation there are two orders of magnitude, and that is the distance prioritization has to cross.

In our own base the same mismatch shows up from another angle. Of the 917 CVEs with a score assigned that sit under observed exploitation, 450 score below CVSS 9, and 97 are medium or low severity. Close to half of what is being used against someone never comes near the top of a severity-ordered queue.

Verizon's DBIR 2026 shows the cost of not crossing it. Median time to remediate rose from 32 to 43 days, and only 26% of the flaws in CISA's known exploited catalogue were fully remediated. The queue got slower precisely in the subset already known to be under attack.

What exposure validation adds to a scan

Exposure validation adds evidence to the finding: a demonstration that the path exists on that asset. A scanner compares component versions and concludes the CVE applies. Validation checks whether the vulnerable component answers from where the adversary stands, whether the CVE's preconditions hold there, and whether a sequence exists leading to the described effect. Those three conditions are laid out in the exploitability validation entry.

Evidence varies in quality, and the finding has to say which kind carried the conclusion. An out-of-band callback proves the path directly. A difference in response time suggests it, and that is all.

An honest program separates what was proven from what stayed merely probable. A finding without an explicit confidence grade goes back to being an opinion with a score attached.

Validation performed once describes an instant. Configuration drifts. Fixes revert on the next deploy. A new asset goes live on a Tuesday afternoon, and this week's exploit intelligence reclassifies what was theoretical yesterday. The practice only supports a decision when it recurs, which is what the continuous validation entry describes.

AEV: the name Gartner gave this layer

On 24 March 2026 Gartner published the Market Guide for Adversarial Exposure Validation. The document's definition: technologies that deliver consistent, continuous and automated evidence of the feasibility of an attack, performing attack scenarios and measuring the outcome to prove the existence and exploitability of exposures.

The category absorbs two labels Gartner had treated separately in the 2023 Hype Cycle, breach and attack simulation (BAS) and automated penetration testing. The guide projects that by 2029, 60% of organizations will have adopted a structured exposure validation practice inside a continuous threat exposure management program.

The new label solves a cataloguing problem and leaves the execution one where it was. It works as a signal that the validation step left the optional list inside the cycle. It works poorly as a purchasing criterion, because the same word appeared in the material of nearly every vendor in the category over the past twelve months.

Changing cadence without growing the team

The change that fits this year's budget sits in the trigger. Instead of raising the frequency of the full scan, split the work into three layers with different firing conditions.

Event-triggered validation. A new asset answering on the internet, a configuration change on a known asset, and the publication of a CVE with observed exploitation all justify validating on the spot. None of the three waits for the calendar.

Post-fix revalidation. Confirming that a fix still holds after the next deploy costs little and catches silent reversion, which is the most common form of recurrence in an external estate.

Periodic deep testing. Business logic, authorization chains and workflow abuse still take people. That part stays on a cycle, now over a much smaller queue.

The gain across all three layers comes from the same place. The queue reaching the remediation team goes from thousands of items with a score to dozens with evidence behind them.

Three numbers that measure the program

Validation rate. Findings that went through an exploitability check, divided by total findings in the period. In most programs it sits below 5%, and the number does not rise when internal criteria change.

Time to revalidation. How many hours pass between a CVE gaining observed exploitation and your estate being re-examined for it. This is the clock from the first section translated into your own house.

Median exposure window. Hours describe a program running at the cadence of change. A day is acceptable in most contexts. A week means six days of head start handed over with every new asset.

All three fit into an afternoon of data gathering and say more about the program than any count of open findings. The same reasoning appears applied in two tests that separate a preemptive program from a periodic one.

Where CSURFACE comes in, and where it stops

If the exploit ships in hours and a score-ordered queue cannot keep up, the question that matters stops being how many CVEs you have. It becomes which of them an attacker exploits from outside, right now. That is the question CSURFACE answers: we audit the coverage of the scanner the institution already pays for, and prove what is exploitable on the external surface, using evidence the target itself returns.

That claim carries its own measurement. The phenomenon this article quoted from third parties is one we measure with our own telemetry, on ThreatSensor, which is public and free. Where the Cloud Security Alliance speaks of roughly five days to the first exploit, the median across our base is one day. In 56.5% of the monitored cases a public exploit already existed on the day the CVE was published, while VulnCheck's 28.96% counts observed exploitation, a narrower criterion than published code.

Follow one of those CVEs from the start.

It comes out on a Tuesday with an exploitation score of zero. Nobody looks. There is no public exploit and no news, so it enters the queue exactly where the score put it, near the bottom. Somewhere in the world someone is writing the exploit at that very moment, and none of that shows up anywhere.

Weeks later CISA confirms the flaw is being used in attacks and adds it to the catalogue. The score climbs. In a Tenable or a Qualys that number updates on its own, and the item that sat at position 400 turns up at the top of the dashboard. The tool did its job. What it could not do was raise the item before public evidence existed, and that evidence only appeared because someone had already been attacked.

This is not a one-off. Across the fifty most recent CVEs to enter CISA's catalogue, half were sitting at a score of zero the day before.

Can prediction recover part of that delay? Partly. We took the 82 CVEs that entered the catalogue from 2024 onward and asked how many each signal would have placed at the top of the list before the confirmation. EPSS alone gets 23. Our model gets 35. Together, 44.

That leaves 38, close to half, that neither one saw coming.

It is that last number that decides how the program gets built. For half the cases the warning and the attack arrive on the same day, and no queue, however well ordered, changes that. What is left is knowing what is exposed and proving what can be reached, fast, in exactly the case nobody anticipated. The numbers are from 17 September 2026, and the base is open on the analytics page for anyone who wants to redo the arithmetic.

There is an effect here that is good news dressed as a bad headline. An institution can go months without a single exploitable finding on the outside. That is not the platform idling. It is the answer the auditor and the regulator want to see, and discovery keeps working in the meantime: what surfaces is the asset nobody had inventoried, the group company answering on the internet outside the internal scanner's reach. Proof that you are clean is a compliance deliverable, not an empty quarter.

The numbers in this article came from our own telemetry, and that telemetry is open. The full report, with the year-by-year series, the methodology to redo every calculation and a one-page summary to take to the board, is The Exploit Clock.

A 756-day clock became a clock measured in minutes over eight years. The weekly scan still runs at the same hour it ran in 2018, and that distance is what CSURFACE shows, with proof, on your institution's external surface.

Frequently asked questions

What is exposure validation?

It is the confirmation, with evidence, that a discovered exposure can be exploited on the asset where it was found, in the state that asset is in. A scan points out that a vulnerable version exists. Validation demonstrates that the path to the described effect is open, and hands that demonstration over with the finding.

How is exposure validation different from vulnerability scanning?

Scanning compares versions and configurations against a base of known flaws, producing candidates. Validation tests those candidates on the real asset and returns proof. A queue of 3,000 unvalidated items and one of 40 validated items can describe the same company, with the difference that only the second one is executable.

What is AEV, or adversarial exposure validation?

It is the name Gartner gave the market category in the Market Guide for Adversarial Exposure Validation, dated 24 March 2026. The document defines AEV as technologies delivering consistent, continuous and automated evidence of the feasibility of an attack, and projects that by 2029, 60% of organizations will run a structured exposure validation practice inside CTEM.

How long does it take today between a CVE being published and the first exploit?

For a good share of cases, no time at all. VulnCheck recorded on 21 January 2026 that 28.96% of vulnerabilities with observed exploitation in 2025 were already being exploited on or before the day their CVE was published. Where no exploit exists at disclosure, the Cloud Security Alliance documented in April 2026 that a language model produces working proof-of-concept code in ten to fifteen minutes.

Is scheduled scanning still useful for anything?

It is, and it remains the base of the vulnerability inventory over the known estate. What it does not deliver is cadence and proof. The practical answer is to keep the periodic cycle for broad coverage and add event-triggered validation for whatever changes between one cycle and the next.

Where should a small team start?

With the validation rate for the last quarter. If the number does not exist, that is the gap to close before any refinement of prioritization, because a queue ordered with precision over unverified findings is still ordering noise. The terms used in this article are in the glossary.

Want to see this on your own surface?

Book a demo