A zero-day is a vulnerability nobody has patched. It sounds like the worst case and it makes every headline.
It is almost certainly not what will breach you.
The vulnerability that gets you is far more likely to be one that was disclosed, patched, and publicly documented weeks before, and that you had not deployed the fix for yet.
That interval has a name. It is the patch window, and it is a security control that most organisations do not measure.
What this changes operationally: CodeAnt AI runs attack surface management continuously rather than on a scan schedule, correlating the National Vulnerability Database, the CISA Known Exploited Vulnerabilities catalog, and EPSS scoring daily. A window measured in days cannot be covered by an assessment measured in quarters.
What is a zero-day vulnerability?
A zero-day vulnerability is a security flaw that is unknown to the party responsible for fixing it, which means no patch exists at the time it is being used.
The name refers to the number of days the vendor has had to produce a fix. Zero.
Three related terms get used loosely and are worth separating.
Zero-day vulnerability. The flaw itself, unknown to the vendor.
Zero-day exploit. Working code that leverages that flaw.
Zero-day attack. The use of that exploit against a real target before a patch exists.
Why zero-days are rarer than the coverage suggests
Zero-days are expensive. Discovery requires skilled research time, weaponisation requires more, and the asset is perishable, because the moment it is used at scale it gets detected, analysed, and patched.
That economics shapes who uses them. Zero-days are concentrated in the hands of well-resourced actors targeting specific high-value objectives, because burning one on a broad campaign is a poor return.
The practical implication for most organisations.
If a nation-state actor is spending a zero-day on you specifically, patch cadence was never going to be the deciding control. For everyone else, the risk lives elsewhere.
What is an n-day, and why it is more likely to hit you
An n-day vulnerability is one that has been publicly disclosed and for which a patch exists, where n is the number of days since disclosure.
Every zero-day becomes an n-day the moment it is patched. And an n-day is dangerous for a reason that is almost counterintuitive.
Disclosure creates the exploit. Before disclosure, an attacker has to find the bug. After disclosure, the vendor has told them where it is, and often exactly what changed.
The cost collapses. Exploiting an n-day requires no original research. The vulnerability class, the affected component, and often proof-of-concept code are public.
The target list is public too. Internet-wide scanning identifies unpatched instances within hours of a disclosure.
The result is that n-day exploitation is cheap, scalable, and available to actors who could never develop a zero-day. Which is why it accounts for the overwhelming majority of exploited-vulnerability incidents.
Zero-day | N-day | |
|---|---|---|
Patch available | No | Yes |
Attacker cost | Very high | Low |
Who uses it | Well-resourced, targeted | Broad, including commodity actors |
Scale | Narrow, specific targets | Mass scanning and exploitation |
Your defence | Detection, segmentation, blast radius | Patch speed |
Frequency in real incidents | Low | High |
The uncomfortable conclusion. The vulnerability you are most likely to be breached by is one you already knew about.
CodeAnt's own research disclosures illustrate the mechanism from the other side: CVE-2026-28292, a CVSS 9.8 remote code execution bug in simple-git, is what the industry would classify a re-emerged n-day, because it survived two prior patch attempts on the same underlying flaw. Each incomplete patch reset the clock on the window without actually closing it.
How patch diffing turns a fix into an exploit
This is the mechanism that makes n-days dangerous, and it is under-understood outside offensive research.
A vendor ships a security update. The advisory says a memory corruption issue was addressed. It names no function, no file, and no root cause.
The vulnerability is simultaneously public knowledge, in that a patch exists, and completely private, in that nobody outside the vendor knows what it was.
Diffing the two builds recovers it.
Why a naive diff fails
Comparing the two binaries byte by byte reports that almost everything changed. A recompile shifts function addresses, reorders code, and changes register allocation, so the signal is buried in noise.
How structural diffing works
Structural diffing matches functions across builds on properties that survive recompilation rather than on bytes.
Control flow graph shape is the primary signal, because the arrangement of basic blocks and branches within a function is stable across compiles.
Call graph position, the set of string literals referenced, and the count of basic blocks all reinforce the match.
Tools including BinDiff and Diaphora implement this. The workflow is short.
Match every function across the two builds. Sort by similarity ascending. Discard the noise from inlining decisions and register churn. Read the handful of functions with a genuine logic change.
A newly added bounds check on a length field, a changed comparison operator, or a new null check is the vulnerability, described more precisely than any advisory would have.
For open-source software it is even simpler
Where the source is public, there is no diffing required. The commit is the disclosure.
A security fix merged to a public repository tells any reader exactly what was wrong, in the maintainer's own words, in a diff. Commit messages frequently describe the defect explicitly.
This is why open-source security fixes are sometimes merged with deliberately vague messages, and why some projects batch security changes into larger releases. Both are attempts to slow exactly this analysis.
That said, a vague commit message does not stop a careful reader from re-deriving the defect from the diff itself. CodeAnt's own pac4j-jwt disclosure, CVE-2026-29000, CVSS 10.0, was found by running exactly this kind of patch-diff analysis against prior CVE fixes in the library, checking whether the code change actually closed the hole the advisory claimed it did rather than taking the fix at face value.
How long is the exploitation window really?
The window opens when the fix becomes publicly analysable and closes when you have deployed it everywhere.
Two things have compressed it dramatically.
Analysis is now fast. Structural diffing that once took a skilled researcher days is now substantially automated. Model assistance accelerates the reading of decompiled output further.
Scanning is instant. Identifying unpatched instances across the internet is a routine, commoditised capability.
The practical shape of a modern window looks like this.
Stage | Typical elapsed time |
|---|---|
Fix merged or advisory published | Day 0 |
Patch analysed, root cause recovered | Hours to days |
Working proof of concept circulating | Days |
Mass scanning for unpatched instances | Days |
Typical enterprise patch deployment | Weeks to months |
The mismatch between the last two rows is the entire problem. Attacker capability is measured in days and enterprise deployment is measured in weeks.
Note also that this is why the disclosure-to-enrichment gap matters.
If your process starts when your scanner flags a finding, and your scanner waits for enriched CVE data, your clock starts after the window has already opened. CodeAnt's vulnerability database exists specifically to keep that starting point closer to the vendor advisory or public commit than to the delayed, enriched NVD record.
Why a merged fix is not a shipped fix
There is a worse case than a slow patch cycle, and it happened publicly in September 2026.
A fix for a consensus-level range-proof caching bug in Elements, the open-source codebase underlying Blockstream's Liquid Network, was merged to public branches around September 1 to 3, 2026.
It was not included in any tagged release.
Every production build in the federation therefore remained exploitable while the fix sat readable in a public repository.
On September 6, roughly 4,000 BTC, worth about $320 million, left the Liquid federation wallet in a single transaction. That was about 95% of the network's reported bitcoin reserves.
No private key was compromised. The 11-of-15 multisig produced genuine signatures, because the withdrawal was valid under the consensus rules in force at that moment.
Three lessons transfer directly to any organisation.
Merged is not deployed, and dashboards measure the wrong one. By any standard vulnerability metric, that fix was done. Closing a ticket is a statement about a repository, and only deployment is a statement about production.
An unreleased public fix is worse than an undiscovered bug. The commit disclosed the vulnerability to anyone reading the log, while providing no protection to anyone running a release.
Delivery is part of remediation. Liquid's functionary codebase had reportedly not been updated in more than two years, which is a delivery problem rather than a code problem.
CodeAnt's full walkthrough of the attack path, including how a checked-in commit becomes a validated exploit path rather than a theoretical one, is in The Liquid Network Hack Explained.
How to measure your own patch window
You cannot shorten what you do not measure, and almost nobody measures this correctly.
Mean time to remediate is the common metric and it is measured from the wrong start point.
Most implementations start the clock when a scanner reports a finding, which is already downstream of the window opening.
Measure these four instead.
Window open to deployed. From public fix availability, meaning vendor advisory or public commit, to full deployment across your estate. This is the real number and it is usually worse than the reported MTTR.
Detection lag. From public fix availability to the finding appearing in your own tooling. Any gap here is time you were exposed without knowing.
Merged-to-shipped lag. For software you build, the time from a security fix merging to it being live in production. This is the Liquid failure mode measured in your own environment.
Coverage completeness. The percentage of your estate confirmed patched, not the percentage of tickets closed. Those differ by exactly the amount you should be worried about.
Report the distribution rather than the average. A mean of fourteen days hides a tail of assets sitting at ninety, and the tail is where the breach happens.
Patch management practices that shorten the window
Seven changes, ordered by impact relative to effort.
Subscribe to upstream advisories directly. For your critical stack, monitor vendor security feeds and repository releases rather than waiting for enriched CVE data to arrive in a scanner.
Treat the CISA KEV catalog as a separate emergency lane. It is populated on evidence of active exploitation rather than on enrichment status, which makes it faster and more decisive than severity scoring.
Pre-authorise emergency changes. The most common cause of a long window is a change advisory board meeting on Thursdays. Define in advance which conditions bypass the normal process.
Automate the safe majority. Most patches are low risk. Automating those frees review capacity for the ones that genuinely need it.
That gate is what "automate the safe majority" looks like in practice: PRs touching a low-EPSS dependency merge on the normal cadence, and PRs touching one with a rising exploit-probability score get held for the review capacity this section is asking you to free up.
Track merged and deployed as separate states. Your workflow should not permit a security item to reach "done" on a merge.
Measure and publish the tail. Report your ninety-fifth percentile window, because the average conceals the assets that actually get exploited.
Know your inventory. You cannot patch what you do not know you run. Statically linked libraries and components copied into images without a package record are invisible to conventional inventory, which is a binary composition analysis problem.
Where CodeAnt AI fits
Two capabilities address the window directly.
Continuous surface monitoring. Attack surface management maps the external footprint daily, correlating the National Vulnerability Database, the CISA Known Exploited Vulnerabilities catalog, and EPSS scoring.
The relevant property is cadence rather than source count. A window that opens on a Tuesday and is exploited by Friday is not covered by a quarterly assessment.
Detection lag is also the component of the window that typically goes unmeasured.
Engagement speed that matches release speed. A full AI penetration testing engagement completes in roughly thirty to ninety minutes of wall-clock time rather than one to four weeks, covering reconnaissance, exploitation, and a reported, evidence-backed deliverable in one pass. The full technical walkthrough of that pipeline breaks down each phase.
That changes what cadence is possible. Testing per release, or after a significant architectural change, becomes viable in a way that hourly-billed manual engagements never allowed, and a re-scan after a fix ships is fast enough to actually confirm the merged-to-deployed gap closed rather than assuming it did.
There is also a warning worth repeating from the same period.
Liquid partner Boltz Exchange disabled its swap service weeks before the incident and warned that AI-assisted vulnerability probing was outpacing patching. That warning aged about as well as a warning can.
The patch window checklist
Measurement
Start the clock at public fix availability, not at scanner detection.
Measure detection lag separately. The gap between a public fix and your tooling noticing is exposure you did not know about.
Track merged versus deployed as distinct workflow states for software you build.
Report the ninety-fifth percentile, not the mean.
Intake
Monitor upstream advisories and repository releases directly for your critical stack.
Run the CISA KEV catalog as a separate emergency lane with its own service level.
Watch for security commits with no corresponding release tag in dependencies you ship.
Response
Pre-authorise emergency change conditions before you need them.
Automate low-risk patching so review capacity goes where it is needed.
Confirm coverage by asset, not by ticket closure.
Inventory
Derive your component list from artifacts, not only from manifests, so statically linked and vendored code is visible.
Where this leaves you
The security industry pays disproportionate attention to zero-days because they are dramatic, and comparatively little to the interval that actually determines most outcomes.
That interval is measurable. It starts when a fix becomes publicly analysable and it ends when the fix is running everywhere you run the software.
Measure it honestly, including the tail. Then ask whether it is shorter than the few days it now takes an adversary to go from a public commit to a working exploit.
Related reading on CodeAnt AI: Continuous Penetration Testing vs Annual Pentesting for the same window problem viewed from the testing-cadence side, and the IDOR guide and Dolibarr research pillar for what a shipped-but-unpatched authorization gap looks like at the code level rather than the binary level.
