In 2018, the average gap between a CVE going public and the first confirmed exploitation of it in the wild was 2.3 years.
Two years and change. You could see a CVE, log it, groom it, argue about severity, wait for the next maintenance window, get pulled onto something else, come back a quarter later, and still be early.
In 2026 that same average is -23 hours.
That is not a stray em-dash that claude left in here. It is a minus sign. Twenty-three hours on the wrong side of zero, which means exploitation now happens, on average, before the disclosure it is supposed to follow.
The time-to-exploit curve
Nine years, one direction.
Years. 2018, 2019.
A year. 2020.
Months. 2021, 2022, 2023.
Weeks. 2024, 2025.
Popped before disclosure. 2026.
The figures behind that, in order: 2.3 years, 1.7 years, 1.3 years, 10 months, 8.6 months, 4.2 months, 53 days, 21.5 days, -23 hours. The median tells the same story and gets there sooner. It started at 771 days in 2018 and was already sitting on the floor by 2023, where it has stayed.
Two details make this harder to dismiss than the average security stat.
First, that mean is trimmed. The extremes at both ends are thrown out before averaging, which means a handful of dramatic zero-days cannot drag it. For a trimmed mean to go negative, the bulk of the distribution has to have moved to the wrong side of disclosure day.
And this is not one project’s dashboard. Google’s threat intelligence team has been tracking the same collapse for years in its own time-to-exploit analysis, finding that 12% of already-disclosed vulnerabilities were exploited within a single day of a patch shipping, 29% within a week, and 56% within a month. Different dataset, different methodology, same direction.
Second, and worth saying before someone else says it: 2026 is a partial year. A CVE disclosed this spring that gets exploited in 2029 cannot be counted yet, so recent-year TTE is biased downward. Real effect. But that bias can only pull a number toward zero. It cannot manufacture a negative one. Negative requires exploitation that actually happened before disclosure. The magnitude of -23h will drift as the year fills in. The sign will not.
One thing the chart cannot show you
Every point on that chart is a CVE. Which means every point on it is software that many organizations run, disclosed by a vendor, patched by a vendor, and tracked by an industry that built instruments for exactly that situation.
Your own applications are not on the chart. There is no clock for them. No advisory arrives, no vendor ships a patch you are waiting on, and there is nobody upstream to blame when the fix takes six weeks. Your process is the only clock, and you are the one holding the watch.
That distinction is where the money actually lands, so it is worth watching it play out twice. Once in shared software, where the entire industry mobilizes inside a fortnight. Once in a company’s own code, where nobody does, and the company pays for it directly.
Prioritization was a strategy that assumed a window
Every vulnerability management practice built over the last fifteen years is a scheduling system. Severity scores, risk registers, exception workflows, quarterly patch cycles, thirty-day SLAs for criticals and ninety for highs. All of it is machinery for deciding what to fix later.
That machinery was rational. With 2.3 years of runway, triage was the correct move. You had more findings than engineers, so you sorted them and worked the top of the list. The math worked because time was the one resource in surplus.
Run the same machinery against 2026. Exploitation on average precedes the advisory. Median time for an organization to test and deploy a fix: about 20 days.
Zero Day Clock’s math on that gap is that organizations are exposed for 99.9% of the vulnerability lifecycle. Your thirty-day SLA for criticals is not a control. It is a description of how long you plan to be exploitable. And sorting that queue faster does not shrink it.
And the reason the curve fell off a cliff is not that attackers got more numerous. Google’s Big Sleep found an exploitable flaw in SQLite before any human did. Sean Heelan generated more than 40 working exploits for a single bug, defeating ASLR, CFI, hardware mitigations, and sandboxes, for fifty dollars. Yaron Dinkin and Eyal Kraft turned agent swarms loose on Windows kernel drivers and pulled 100+ exploitable vulnerabilities out of AMD, Intel, NVIDIA, Dell, Lenovo, and IBM in 30 days. Four dollars a bug.
Heelan’s line is the one that should ruin your afternoon. The limiting factor on a nation state’s exploit development is token throughput, not headcount.
A CVE is a distribution artifact, not a risk artifact
Here is the part that should actually keep you up, because every number above describes somebody else’s software.
Ask why a vulnerability gets a CVE at all. Not why it exists. Why it gets a name.
It gets a name because thousands of organizations run the same code and need a shared identifier to coordinate around. That is the entire purpose of the system. It is a namespace for widely distributed software. NVD, KEV, EPSS, scanner feeds, Patch Tuesday, your whole vulnerability management stack: all of it is downstream of one precondition, which is that many people run the identical bytes.
So CVE coverage tracks distribution. It does not track exploitability.
Take two real SQL injection flaws.
What happens when the software is shared
In May 2023, the Cl0p ransomware group began exploiting an unknown SQL injection bug in Progress Software’s MOVEit Transfer. Unauthenticated attackers could reach the underlying database, drop a web shell, and exfiltrate everything in it.
Watch what the ecosystem did. Progress published an advisory on May 31. The bug became CVE-2023-34362 on June 2, and CISA added it to the KEV catalog the same day. Fortinet shipped a threat signal, Rapid7 published exploitation telemetry, Microsoft attributed the campaign, and CISA and the FBI released a joint advisory with YARA rules and indicators of compromise. Inside two weeks, every scanner vendor, every threat feed, and every board deck in the country had the same line item on it.
What happens when the code is yours
In October 2015, someone ran sqlmap against TalkTalk’s website and found three injectable pages. They pulled a database holding names, addresses, dates of birth, phone numbers, and email addresses for 156,959 customers, plus bank account numbers and sort codes for 15,656 of them. The UK’s Information Commissioner fined TalkTalk ยฃ400,000 and said the attacker got in with ease.
Same vulnerability class. Nothing like the same response.
Nobody assigned it an identifier, because there was nothing to identify. A CVE names a version of a product. TalkTalk’s problem was three of its own pages handing user input straight to a database query, which is not a product and has no version number. So it never reached an advisory, a KEV listing, a threat feed, or a scanner signature. Finding it meant sending an injection at those pages, and the only people doing that were attackers. They had already tried twice that year, in July and again in September, and nobody noticed either time because nobody monitored pages nobody knew existed.
Patching MySQL would not have prevented it
The regulator also faulted TalkTalk for running an outdated MySQL version carrying a bug the vendor had fixed in 2012, and its account has that flaw helping the attacker get past restrictions on the database. Worth separating out, because patching MySQL would not have prevented the injection. An injection reaches the database through an unvalidated parameter in the application. That is a defect in code TalkTalk owned, and no patch to anything running underneath the application closes it. The outdated database software may well have widened what the attacker could reach. The application code is what opened the door.
Which is the point. The part of TalkTalk’s problem that had a name, a version number, and a published fix was at least findable through the standard apparatus, assuming you know what you are running. The part that actually let the attacker in was in first-party code, invisible to every feed and every signature in existence, and answerable only by testing the running application.
Worth noting who did the finding, too. Teenagers, with a free automated tool, in 2015. Ten years of tooling later, that job belongs to an agent.
Every number on that chart is a floor
Those 3,500 confirmed-exploited CVEs are not the population. They are the visible slice, and they are visible precisely because the software was shared. The bugs in software organizations write for themselves are not a smaller category. They are the larger one, and they are entirely unmeasured.
The time to exploit for your own application code is not -23 hours. It is undefined, because no instrument exists that is pointed at it.
You are the vendor and the deployer
Third-party software at least gives you a story. You are the deployer, waiting on a vendor, and the delay is partly someone else’s fault.
Your own application has no upstream. You are the vendor. You are also the deployer. That median 20-day patch cycle is not something happening to you, it is your engineering process. The 99.9% exposure window belongs to your customers, and the only party who can close it is the team that opened it.
Nobody is going to publish an advisory that forces the issue. There is no Patch Tuesday for your codebase. The finding either gets fixed by the people who wrote it or it sits there, exploitable, indefinitely, and the first notification you get is not a CVE.
And the agents do not care that your repository is private. Anthropic’s red team found 500+ high-severity vulnerabilities in open source that had survived decades of expert review, and they went looking at open source because it was available to test, not because it was uniquely broken. That capability points at a running application just fine. Nobody needs your source code to find an injectable endpoint in your API, and finding an issue in source code is not the same as confirming it in a running system.
Which brings us back to the argument we made with CVE publication data a few weeks ago. Finding went exponential in late 2025. Fixing did not. Every automated finder coming online adds to the pile without adding a single unit of remediation capacity.
Zero Day Clock adds the deadline. Finding is exponential, the due date now lands before the start date, and for the code you write yourself there is no due date published at all.
The only fix that ships in time is the one that never becomes a ticket
If exploitation precedes disclosure and remediation takes weeks, there is exactly one way to close the gap, and it is not a faster queue.
The fix has to happen before the code merges. Not shifted left into a scan that files an issue for someone else. Not routed to a security review that adds three days. Fixed in the loop where the code is being written, while the author still has context loaded and the branch is still open.
Your developers are already in that loop. They are shipping with Claude Code, Cursor, Copilot, and Codex, generating more code per week than any review process was built to absorb. That is the same acceleration that flattened the curve above, pointed at your codebase.
It is also the opening. The agent writing the code can fix the code. It just needs to be told what is actually broken, and then told whether the fix worked.
That is the loop Wingman runs. It scans the running application, hands the developer’s coding agent a reproduced, exploitable finding, then re-tests to confirm the fix holds. Scan, fix, verify, inside the pull request. Nothing gets filed, triaged, or scheduled against a thirty-day SLA, because the vulnerability is gone before the branch merges.
Fix time stops being measured in days and starts being measured in the same units as the exploit.
Nobody is going to name it for you
The industry spent twenty-five years building a naming system, a severity scale, and a distribution network for vulnerabilities in software you buy. It works, more or less, and that chart is the evidence that even where it works the timing no longer does.
For the software you write, none of that infrastructure was ever built. There is no clock to watch. There is no list to check. The only number that exists is how long a flaw survives between the commit that introduced it and the commit that removed it, and you are the only one who can measure it.
Start measuring it. Then get it under an hour.
Wingman puts scan, fix, and verify inside your coding agent’s loop, so security findings get resolved before they ever become backlog. See how it works.
