What Is a Zero-Day? Zero-Day vs 1-Day vs N-Day, With Dated Cases

A zero-day is a vulnerability that attackers exploit before the vendor has published a fix. A 1-day is exploited in the short window right after the fix and advisory appear, and an n-day is exploited long after a patch has been available. The label tells you which lever you have: mitigation, patch speed, or inventory.

With a zero-day you cannot patch, so you reduce exposure and watch. With a 1-day you are racing people reading the same patch. With an n-day you are paying for not knowing where a component lives. This post defines each term as the public trackers do, walks the lifecycle, and grounds it in five cases dated from CISA, NVD and the projects' own advisories.

Key takeaways

• Zero-day means exploited in the wild before a patch was publicly available. Google Threat Intelligence Group (GTIG) and Google Project Zero both use a version of that definition, and NIST's glossary describes a zero-day attack as one that exploits a "previously unknown" vulnerability.
• 1-day and n-day are informal terms. Both mean exploitation after a fix exists; "1-day" stresses the first days after the patch, "n-day" any time after, including years later.
• The numbers are real and stable. GTIG tracked 90 zero-days exploited in 2025, 78 in 2024 and 100 in 2023 (its revised counts), and almost half of 2025's targeted enterprise technology.
• Speed has collapsed. Google's time-to-exploit analysis put the average gap between disclosure or patch and exploitation at five days for vulnerabilities disclosed in 2023, down from 63 days in 2018 to 2019.
• The same bug can be all three. A library flaw can be a zero-day in the product where it was caught and an n-day for months in every product that bundles the library.
• Safeguard's role here is the response side. SBOM generation and analysis (GA) and vulnerability management with EPSS and KEV enrichment (GA) find where a component lives; reachability analysis (GA) ranks it; autonomous remediation (GA, ships switched off with every category set to Manual) opens the fix; policies and gates (GA) stop it shipping again; CSAF and VEX upload (GA) records what does not affect you. It does not detect attacks or patch software you do not build.
• For US federal civilian agencies, BOD 26-04 now sets the clock. It revoked BOD 22-01 on 10 June 2026 and replaced fixed deadlines with risk-based timelines built from four factors.

What is a zero-day?

A zero-day is a vulnerability exploited while defenders have had zero days with a fix. There is no single legal definition, and three public definitions differ in ways that explain why counts disagree.

NIST. The NIST Computer Security Resource Center glossary defines a zero-day attack as an attack that exploits a "previously unknown hardware, firmware, or software vulnerability", citing CNSSI 4009-2022. The emphasis is on the flaw being unknown, not on patch status.

Google Threat Intelligence Group. GTIG's annual reviews define a zero-day as a vulnerability that was maliciously exploited in the wild before a patch was made publicly available. The test is the patch: a bug the vendor knew about but had not fixed still counts.

Google Project Zero. The Project Zero "0day In the Wild" tracking spreadsheet counts vulnerabilities detected in real attacks while not known to the public or the vendor. Its notes exclude software that was end of life at the time and opportunistic exploitation in the gap between public disclosure and a patch. Its data starts on 15 July 2014, the day Project Zero was announced.

Put plainly: a vulnerability that attackers find and use before anyone else knows is a zero-day under all three definitions. A vulnerability that is publicly disclosed, has no patch yet, and is then exploited is a zero-day for GTIG but not for the Project Zero tracker. That gap is where many of the worst weeks in incident response happen, because attacker and defender learn about the bug at the same time and only one of them has a working move.

People also mix up the vulnerability (the flaw), the exploit (the technique that turns the flaw into code execution or data access) and the attack (the use of that exploit against a real target). When a vendor bulletin says it is aware that an exploit exists in the wild, that sentence is usually the first public signal a defender sees.

Zero-day vs 1-day vs n-day

The three labels describe the same vulnerability at different moments relative to its fix. This table sets out how they are usually used.

What is a 1-day?

A 1-day is a vulnerability exploited shortly after the vendor publishes a fix. The "1" is not literal. It signals that the patch and advisory are fresh, and that attackers are using them as a map to the changed code. The fix exists, so the only question is how quickly you learn that you are affected, test the update and deploy it. Teams with a reliable inventory and an emergency change path close a 1-day in hours or days. Teams without them turn a 1-day into an n-day without noticing.

What is an n-day?

An n-day is a vulnerability exploited at any point after a fix is available. Google's time-to-exploit analysis of vulnerabilities disclosed in 2023 puts it precisely: n-days are first exploited after patches are available, while zero-days are exploited before patches are made available, excluding end-of-life technologies.

N-days are the long tail, and the reason CISA's Known Exploited Vulnerabilities catalog contains bugs from 2017 and earlier. Every n-day in your estate is a fix that already exists and has not reached the running system.

Two patterns blur the lines. A variant is a new bug closely related to a known one, such as a bypass of an earlier fix. An incomplete fix closes one path to the bug but leaves another. Both create a new CVE and a new clock, and two of the cases below show it.

The vulnerability lifecycle, stage by stage

Every vulnerability, whatever its eventual label, moves through roughly the same stages. The order of the middle stages is what decides whether it is a zero-day, a 1-day or an n-day.

1. Introduction. A flaw enters the code through a commit, a dependency update or a design choice.
2. Discovery. The vendor, a researcher, an automated tool or an attacker finds it.
3. Exploit development. Someone turns the flaw into something usable, possibly before anyone else knows it exists.
4. Vendor awareness. Through a private report, its own testing or detected attacks.
5. CVE assignment. A CVE Numbering Authority reserves an identifier, often before disclosure.
6. Fix release. A fixed version ships, sometimes after a configuration workaround.
7. Public disclosure. An advisory is published, in coordinated disclosure with or just after the fix.
8. Enrichment. NVD publishes the record and affected ranges; CISA adds the CVE to KEV if it has reliable evidence of active exploitation.
9. Public exploit. A proof of concept appears, widening the pool of attackers.
10. Mass exploitation. Automated scanning follows for internet-facing products.
11. Remediation in the field. Users find and update affected systems, the slowest stage by far.
12. Long tail. Unpatched copies keep running for years and keep getting exploited.

If an attack happens before stage 6, you have a zero-day. If stage 10 starts within days of stage 6, a 1-day. If attacks on stage 12 systems show up years later, an n-day. The same CVE can show all three patterns at once, because "patch available" is a global fact while "patch applied" is a local one.

A useful way to read any timeline is to look for four clocks: when exploitation started (often revised later), when the fix shipped, when the public signals appeared (advisory, NVD, KEV), and your own clock, from learning you were affected to fixing the last system. The first three are outside your control. The fourth usually decides the outcome.

Five real cases, with dates

Each date below comes from a primary source: CISA, NVD or the project's own advisory. Where a date was not in a fetched source, it is left out rather than estimated.

MOVEit Transfer, CVE-2023-34362: a zero-day by every definition

CVE-2023-34362 is a SQL injection in the MOVEit Transfer file transfer web application that, per NVD, could let an unauthenticated attacker reach the database.

According to the joint FBI and CISA advisory AA23-158A, citing open source information, the CL0P ransomware group began exploiting this previously unknown vulnerability beginning on 27 May 2023. Internet-facing servers were infected with a web shell the advisory names LEMURLOOT, which was then used to steal data from the underlying databases.

Why it is a zero-day: exploitation began before a fix was public, meeting all three definitions.

What it teaches: for a zero-day in an internet-facing product, the first moves are knowing which instances you run, whether they face the internet, and whether they show signs of compromise. The follow-up CVE ten days later is typical: when attention lands on a component, more bugs are found.

libwebp, CVE-2023-4863: a zero-day in one product, an n-day in many

CVE-2023-4863 is a heap buffer overflow in libwebp, the open source library that decodes WebP images. NVD describes it as affecting Google Chrome before 116.0.5845.187 and libwebp before 1.3.2.

Chrome's stable channel update of 11 September 2023 credits the report to Apple Security Engineering and Architecture and The Citizen Lab at the University of Toronto's Munk School, dated 6 September 2023, and states that "Google is aware that an exploit for CVE-2023-4863 exists in the wild."

Why it is a zero-day: an exploit existed in the wild before the fix shipped.

Why it matters for software supply chains: libwebp is a library, bundled into other applications, desktop frameworks, mobile apps and container images. For every product that ships its own copy, the fix arrived only when its maintainers updated the library and released a new build. Until then, the bug was a known, fixed flaw in their shipped code: an n-day.

The KEV entry carries a second lesson. It names the product as Chromium WebP. A team matching KEV only against product names would see a browser and stop. The question that finds the real exposure is "where do we ship libwebp, and at what version?", which only a component inventory can answer. The libwebp explainer covers the bug itself.

Log4Shell, CVE-2021-44228: disclosed with a fix, exploited at once

CVE-2021-44228 is the JNDI lookup flaw in Apache Log4j 2 that became known as Log4Shell. The Apache Logging Services security page rates it 10.0 critical, lists log4j-core as the affected component and gives the fixed versions as 2.15.0 for Java 8 and later, 2.12.2 for Java 7 and 2.3.1 for Java 6.

Was Log4Shell a zero-day? That depends on whether exploitation before the fixed release is proven, and this post does not rely on unverified reports. The record shows CISA listed it in KEV, on reliable evidence of exploitation, the same day NVD published it. The weeks that followed were a textbook 1-day at internet scale.

The follow-up matters as much as the original. Apache's page explains that the 2.15.0 fix was incomplete when a non-default Pattern Layout used a Thread Context lookup, which led to CVE-2021-45046 and the 2.16.0 release (with 2.12.3 and 2.3.1 for older Java). Teams that upgraded on day one had to do it again four days later. The page also notes that applications using only the log4j-api JAR, without log4j-core, were not affected by CVE-2021-45046: exactly the component-level fact an inventory must capture.

KEV added the follow-up more than a year after publication, a reminder that KEV is evidence driven. Absence from KEV means CISA has not recorded reliable evidence of exploitation, not that nobody is exploiting it. And Log4j was often pulled in by other libraries, so many teams did not know they shipped it until they looked. The Log4Shell lessons post goes further.

PHP-CGI, CVE-2024-4577: the 1-day pattern, and a bypass of a bypass

CVE-2024-4577 affects PHP when running with Apache and PHP-CGI on Windows under certain code pages, where Windows "Best-Fit" character replacement could let crafted input reach the PHP command line. NVD lists affected versions as 8.1 before 8.1.29, 8.2 before 8.2.20 and 8.3 before 8.3.8.

The PHP changelog entry for 8.3.8, dated 6 June 2024, describes the fix as a bypass of CVE-2012-1823, an argument injection in PHP-CGI from twelve years earlier. So the 2024 bug was itself a variant of a very old one.

Why it is a 1-day: the fix shipped first, and exploitation strong enough for a KEV listing was recorded within a week.

What it teaches: the "fixed" line moved twice. The 2012 fix was bypassed in 2024, and the 2024 fix was bypassed later the same year. Record the version that fixed a vulnerability and keep watching for follow-up CVEs against the same component. More detail is in the CVE-2024-4577 explainer.

Apache Struts, CVE-2017-5638: the n-day that kept going

CVE-2017-5638 is the Jakarta Multipart parser flaw in Apache Struts 2, published by the project as security bulletin S2-045. It rates the flaw critical, lists Struts 2.3.5 to 2.3.31 and 2.5 to 2.5.10 as affected, recommends 2.3.32 or 2.5.10.1, and offers a servlet filter workaround that rejects suspicious Content-Type values.

Why it is an n-day: a fix and a workaround existed from the day the record was published.

What it teaches: KEV's first batch, published with BOD 22-01 on 3 November 2021, included bugs four or more years old, because attackers were still using them. The cost of an n-day is the gap between "a fix exists" and "every copy is fixed". The Struts explainer covers the bug itself.

The five cases side by side

Four of the five sit in open source components that other software bundles, which is why a component inventory is the first thing to reach for, whatever the label.

What the public data says about volume and speed

How many zero-days are exploited each year?

GTIG publishes an annual zero-day review. Its 2025 review, "Look What You Made Us Patch", published on 6 March 2026, counts 90 zero-day vulnerabilities exploited in the wild in 2025. It gives revised counts of 100 for 2023 and 78 for 2024, and says the yearly total has stayed within a range of 60 to 100 over the previous four years.

Note the revision. The 2024 review, published a year earlier, reported 75 for 2024 and 98 for 2023. Both numbers went up later as more past incidents came to light. GTIG says so directly: the numbers may adjust as forensic investigations surface older exploitation. Any single year's figure is a floor, not a ceiling.

What is being targeted?

The 2024 review recorded a shift toward enterprise technology: 37 percent of zero-days targeted enterprise products in 2023, rising to 44 percent in 2024, driven mainly by security and networking software and appliances. The 2025 review puts the share at 48 percent, or 43 vulnerabilities, a new high, and says just over half of attributed zero-day exploitation by state-sponsored espionage groups focused on edge devices and security appliances, while detected browser exploitation fell to historical lows.

For an AppSec team, the reading is this: many zero-days land in products you buy and run, where your response depends on the vendor. But many 1-days and n-days, including four of the cases above, land in open source components inside software you build, and that part is yours to find and fix.

How fast does exploitation follow disclosure?

Google's analysis "How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends", published on 16 October 2024, looked at 138 vulnerabilities disclosed in 2023 that were tracked as exploited in the wild. Of those, 97 were exploited as zero-days and 41 as n-days. Its time-to-exploit measure, the average time taken to exploit a vulnerability before or after a patch is released, fell from 63 days in 2018 to 2019, to 44 days from 2020 to the start of 2021, to 32 days across 2021 and 2022, and to five days in 2023. It notes actual times are almost certainly earlier.

Five days is shorter than most monthly patch cycles, which argues for a separate fast lane for newly disclosed, internet-facing, exploited vulnerabilities.

How big is CISA's KEV catalog now?

The KEV JSON feed at version 2026.10.23, released on 23 October 2026, lists 1,756 vulnerabilities. Counting its "dateAdded" field by year gives 311 additions in 2021 (the catalog launched on 3 November that year), 555 in 2022, 187 in 2023, 186 in 2024, 245 in 2025 and 272 so far in 2026. Many additions in any year are old n-days with fresh evidence of exploitation.

Why the counts disagree between trackers

GTIG, Project Zero and KEV give different numbers because they measure different things. Project Zero excludes exploitation in the gap between disclosure and a patch, and software that was end of life; GTIG includes the gap. KEV covers zero-days, 1-days and n-days alike, whenever CISA has reliable evidence of exploitation. All of them are revised as evidence appears. State the source and the definition with any number you use.

Why the label changes what you do

The point of classifying a vulnerability is to pick the right first move.

• Zero-day, or disclosed and unpatched. You cannot update. Apply the vendor's mitigations, reduce exposure, increase monitoring and check for compromise. You still need to know every place the product or component runs.
• 1-day. Patch speed is everything. Know within hours which builds carry the affected version and which are exposed, and use an emergency change path for exploited, exposed, high-impact bugs.
• N-day. The fix exists and you are late. Find every copy, assign an owner, fix it, and stop the old version shipping again.

BOD 26-04: the federal clock is now risk based

For US federal civilian agencies, CISA's Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk", dated 10 June 2026, sets the remediation clock. It revokes BOD 19-02 and BOD 22-01, the 3 November 2021 directive that created the KEV catalog, whose fixed due dates are now history.

BOD 26-04 decides urgency from four variables:

• Asset exposure. Is the vulnerable asset publicly exposed?
• KEV status. Is the CVE in CISA's KEV catalog?
• Exploit automation. Can an adversary automate every step of exploitation?
• Technical impact. Does exploitation give partial or total control of the asset?

CISA publishes the last three for every CVE ID through its Vulnrichment program. Table 1 sets timelines from the answers. Its notes explain that cells marked "& forensic triage" require remediation or mitigation within three days plus a forensic triage of the asset, and that "fix on system upgrade" means remediating at the next scheduled major upgrade or rebuild. The clock starts when CISA adds the CVE to KEV or when the agency identifies it on an asset, whichever comes first.

The directive binds only federal civilian systems, but its four questions are a sensible triage model for anyone. The post on BOD 26-04 timelines and forensic triage goes deeper.

How Safeguard helps on the response side, step by step

This section covers the response side only: shortening "your clock", the time between a public advisory and the moment you know, and fix, every affected place in the software you build and ship. The steps follow Safeguard's documentation. Commands are shown as the docs show them; they were not run for this post.

Step 1: Build an inventory you can query

You cannot answer "where do we ship libwebp?" from memory. Safeguard's SBOM generation and analysis (GA) builds a software bill of materials for each target and matches it against vulnerability databases. From the CLI, the docs show one target per scan:

# A local directory
safeguard scan --dir .

# A container image
safeguard scan --image nginx:latest

# An SBOM you already have (SPDX or CycloneDX, detected automatically)
safeguard scan --sbom sbom.json

Results are written as JSON under ./output by default, including vuln.json. To see results in the platform beside your other projects, the docs say to scan from the interactive terminal (/scan .) while signed in; the runner uploads the SBOM and findings, not your source. Run safeguard update first on the day a CVE lands, to refresh the local vulnerability databases. Note that safeguard scan exits 0 whenever the scan ran, whatever it found; gating is done by policy gates (Step 6).

For connected repositories, Safeguard's vulnerability management (GA) runs daily continuous scanning, and per the Vulnerabilities docs, projects are re-evaluated automatically when new CVEs are published. That turns a fresh advisory into a finding against a project you already track.

Step 2: Ask the question in plain words

The platform's Search page lets you query every SBOM, component and vulnerability with natural language. The docs list examples including "What packages are affected by Log4j?" and plain lookups such as a CVE ID or a package name and version. Results are grouped into components (with the projects where each is used and the vulnerability count), vulnerabilities (with severity, CVSS, affected components and fix availability) and projects.

For libwebp, the useful question is "which projects contain libwebp, and at which versions?" For Log4Shell it is "which projects contain log4j-core?", since log4j-api alone was not affected by the follow-up CVE. You can star a search so a recurring sweep is one click away next time. The post on finding affected products fast with SBOMs covers inventory-led response in general.

Step 3: Read the exploitation signals

Each vulnerability record in Safeguard carries the CVE ID, CVSS score, EPSS score, an Exploitable flag, the affected component and version, the fixed version, references and reachability, per the Vulnerabilities docs. The page groups vulnerabilities into Critical, High, Medium, Low and Exploitable, where Exploitable means known active exploitation in the wild based on CISA KEV.

EPSS, run by FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. KEV tells you exploitation has been observed. Together they separate the 1-day you must handle today from the issue you can schedule. Safeguard's compliance library also includes a CISA KEV correlation framework whose scan requirement, KEV-1, checks that no components match KEV entries; per its docs page it is on unless you switch it off in Compliance › Manage.

Step 4: Rank by reachability, not just severity

Reachability analysis and prioritisation (GA) asks whether your code actually calls the vulnerable function. The reachability docs describe static analysis (a call graph from source, lockfile and bytecode), dynamic analysis (what is loaded and invoked at runtime) and configuration analysis (whether framework configuration wires the code in). Each finding is classed as Reachable, Conditionally reachable (needs a flag, route or setting not enabled), Unreachable, or Unknown, which is treated conservatively as potentially reachable.

Those classes combine with EPSS, KEV, runtime context and business context into a priority score, and the docs' default ordering puts reachable, KEV-listed, production findings at the top. In a 1-day, that is the queue you work first. In an n-day cleanup, it is how you sequence a large backlog. Reachability is evidence about your code, not about attackers, so an unreachable library in an internet-facing image still deserves a fix on a normal schedule. The reachability, EPSS and KEV post goes deeper.

Step 5: Ship the fix as a pull request

When a fixed version exists, Safeguard's autonomous remediation (GA) can open a fix pull request through Griffin, for one repository or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own and what waits for a person. On the Vulnerabilities page, the AI Remediate button generates remediation plans you review before pull requests are created, and View Fix shows upgrade options with breaking change warnings.

For the Log4j and PHP cases, where a first fix was followed by a second, continuous scanning raises the follow-up CVE against the same projects and a second pull request moves you again. The autonomous remediation post explains the categories and strategies.

Step 6: Stop the vulnerable version from shipping again

Policies and gates (GA) turn the lesson into a rule. Per the docs, policies evaluate your SBOMs and generate findings, and gates enforce them. Create one under Settings → Policies with Create Policy, using the visual builder or YAML, with conditions such as severity, CVSS score or EPSS score.

Each policy's action decides what a failure does to the gate:

Gates are evaluated by the platform on the scans it runs for connected repositories. With policy outcomes on for your workspace, the docs show this CI command failing a job when a gate fails:

safeguard ci scan --wait --fail-on-gate <gate>

Exceptions need a justification and an expiration date, go to approvers, and are recorded in an audit trail: a controlled way to ship while a zero-day has no fix. The plain English policies post walks through building one.

Step 7: Record what does not affect you

Much of the work in a big disclosure is proving a negative. Safeguard's CSAF and VEX upload (GA) imports advisories and exploitability statements. Per the docs, go to Integrations, filter by Upload, click Connect on the Upload CSAF/VEX card, name the upload, drop in the file, set the project name and version, and click Upload. Supported formats are CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile.

The docs' own OpenVEX example shows the shape of a "not affected" statement:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2024/001",
  "author": "Example Corp",
  "timestamp": "2024-01-15T00:00:00Z",
  "statements": [
    {
      "vulnerability": { "name": "CVE-2024-12345" },
      "products": [ { "@id": "pkg:npm/example-package@1.0.0" } ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present"
    }
  ]
}

Before uploading, safeguard validate checks VEX documents (CSAF and OpenVEX) against their specifications, with --strict to treat warnings as errors. For single findings, the Vulnerabilities page also has Mark False Positive, with a justification and approval if policy requires it, and Accept Risk, with an expiration date. The VEX and CSAF post covers the format choices.

Step 8: Close the loop

When the incident is over, write down the four clocks for your own estate. The first two come from advisories; the last two, when you learned you were affected and when the last build was fixed, are yours to improve. A starred search, a gate on the vulnerable range and VEX records for unaffected products make the next one shorter.

Decision table: what to do for each label

What Safeguard does not do

• It does not detect attacks in your network. Safeguard works on software inventory, vulnerabilities and code. It does not watch traffic, endpoints or logs, and it does not replace detection, threat hunting or forensics.
• It does not patch software you do not build. A zero-day in a vendor appliance, a hosted service or an operating system runtime still needs the vendor's fix.
• It does not replace advisories. The flow here starts from public sources such as NVD, OSV and CISA KEV, which Safeguard ingests. Someone still has to read vendor guidance for the products you run.
• Its inventory is only as complete as what you scan. A service never scanned, or a library copy hidden inside a binary the scanner cannot see, will not show up in a search.
• Reachability is evidence, not a guarantee. Unknown findings are treated as potentially reachable, and a dynamic result only reflects code paths that ran while observed.
• Autonomous remediation needs a fixed version and your approval. It ships with every category set to Manual. For a zero-day with no upstream fix there is no upgrade to propose; the Gold section below covers the fork and patch route for open source.
• It does not set your regulatory clock. Safeguard's KEV correlation and policies help you track against a timeline; deciding which timeline applies to you is yours.

Common mistakes

Treating every scary CVE as a zero-day. If a fix is out, the real problem is patch speed.

Matching KEV against product names only. The libwebp KEV entry names Chromium; the exposure lives wherever the library is bundled.

Stopping at the first fixed version. Log4j 2.15.0 and PHP 8.3.8 were both followed by fixes for incomplete or bypassed patches. Keep the component on watch after the first upgrade.

Assuming "not in KEV" means "not exploited". KEV is evidence driven, and evidence arrives late. CVE-2021-45046 was added more than a year after publication.

Letting exceptions become permanent. An accepted risk needs an expiry date and an owner, or it quietly becomes an n-day.

Patching the repository and forgetting the running system. A merged pull request is not a fixed server. Rebuild, redeploy and confirm the running version.

Ignoring transitive dependencies. Log4j was often pulled in by other libraries. An inventory of direct dependencies only will miss it.

FAQ

What is a zero-day in simple terms?

A security flaw that attackers use before the vendor has released a fix, so defenders have had zero days with a patch. Google Threat Intelligence Group defines it as a vulnerability maliciously exploited in the wild before a patch was made publicly available.

What is the difference between a zero-day and a 1-day?

The patch. A zero-day is exploited before a fix is public; a 1-day just after, often by attackers studying the patch. PHP's CVE-2024-4577 was fixed on 6 June 2024 and added to CISA KEV six days later.

What is an n-day vulnerability?

A known vulnerability exploited at any point after its fix is available, days or years later. Apache Struts CVE-2017-5638 was fixed in March 2017 and is still in CISA's KEV catalog in October 2026.

Is a disclosed vulnerability without a patch a zero-day?

For Google Threat Intelligence Group, yes, because exploitation came before a public patch. The Project Zero tracker excludes exploitation that happens only in the gap between disclosure and a patch.

How many zero-days are exploited each year?

GTIG tracked 90 in 2025, with revised counts of 78 for 2024 and 100 for 2023, and says totals have stayed between 60 and 100 for four years. Counts rise as older incidents are found.

How fast are vulnerabilities exploited after disclosure?

Google's analysis of vulnerabilities disclosed in 2023 found an average time-to-exploit of five days, down from 32 days across 2021 and 2022 and 63 days in 2018 to 2019.

Does being in CISA KEV mean a vulnerability is a zero-day?

No. KEV lists vulnerabilities with reliable evidence of active exploitation, whatever their timing, and many entries are years old.

What should I do first when a zero-day is announced?

Find where you run the product or ship the component. Then apply vendor mitigations, reduce exposure, look for compromise and be ready to patch the moment a fix ships.

What is the difference between a zero-day and a CVE?

A CVE is an identifier for a catalogued vulnerability. A zero-day describes timing. A zero-day may have no CVE when first exploited, and most CVEs are never zero-days.

What replaced CISA BOD 22-01?

BOD 26-04, dated 10 June 2026, which sets federal civilian remediation timelines from asset exposure, KEV status, exploit automation and technical impact.

Most of what decides a zero-day, 1-day or n-day outcome happens after the fix exists, or in the stretch where no fix exists yet. The section below sets out how Safeguard closes both gaps for the open source components and images you build and ship.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to "fix the lodash CVE in this repo". It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test, prints a summary and pushes nothing. That is the 1-day motion in miniature: a known fix, applied and tested, with a person deciding what lands.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. On the day a CVE lands, it is how you re-scan code on a laptop or build host; the scan runs where your code is, and only results go to Safeguard.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to Safeguard. You add Safeguard from Claude's connector directory, where it has a community listing, sign in with OAuth, and choose which tools Claude can use. During a disclosure, you can ask Claude which projects carry a given component version, within the tools your administrator has enabled.

Click through it at your own pace, or open it full screen.

To try the response flow on your own code, download Safeguard or read the Safeguard docs.

Quick check

Sources

• NIST CSRC Glossary: zero day attack
• Google Threat Intelligence Group: Look What You Made Us Patch, 2025 Zero-Days in Review (6 March 2026)
• Google Threat Intelligence Group: A 2024 Zero-Day Exploitation Analysis
• Google Cloud: How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends (16 October 2024)
• Google Project Zero: 0day In the Wild tracking spreadsheet
• Google Project Zero: 0-days In-the-Wild, Root Cause Analyses
• Google Project Zero: 0-days In-the-Wild, About
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: KEV catalog JSON feed, version 2026.10.23
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: BOD 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities (revoked, historical)
• CISA and FBI: Advisory AA23-158A, CL0P exploits MOVEit vulnerability
• NVD: CVE-2023-34362
• NVD: CVE-2023-35036
• NVD: CVE-2023-4863
• Chrome Releases: Stable Channel Update for Desktop, 11 September 2023
• Apache Logging Services: Log4j security vulnerabilities
• NVD: CVE-2021-44228
• NVD: CVE-2021-45046
• PHP 8 ChangeLog (8.3.8 and 8.3.12)
• PHP 8.3.8 release announcement
• NVD: CVE-2024-4577
• NVD: CVE-2024-8926
• Apache Struts: Security bulletin S2-045
• NVD: CVE-2017-5638
• FIRST: Exploit Prediction Scoring System (EPSS)
• Safeguard docs: CLI usage
• Safeguard docs: Search
• Safeguard docs: Vulnerabilities
• Safeguard docs: Vulnerability prioritization (reachability analysis)
• Safeguard docs: Policies and Gates
• Safeguard docs: CSAF/VEX upload
• Safeguard docs: CISA KEV correlation framework
• Safeguard docs: Explore SBOM

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.