Exploited zero-days 2024 to 2026: what GTIG and Project Zero data shows

Public data says exploited zero-days have settled into a steady band rather than a spike. Google Threat Intelligence Group (GTIG) tracked 90 in 2025 and 78 in 2024, and a record 48% of 2025's hit enterprise products. Big platforms still lead by vendor count. Every zero-day is exploited before a patch exists, so response speed after the advisory is what you control.

This post reads the two most cited public sources line by line: GTIG's annual zero-day reviews for 2024 and 2025, and Google Project Zero's "0day In the Wild" tracker, which we pulled on 25 October 2026 and counted ourselves for 2024, 2025 and 2026 to date. Every figure below names its source and year. Where the two sources disagree, we say so and explain why. At the end we cover what an AppSec or product security team can do with the data, including where Safeguard fits on the response side and where it does not.

Key takeaways

• The yearly count is stable, not exploding. GTIG's 2025 review (published March 2026) counts 90 exploited zero-days in 2025, 78 in 2024 and 100 in 2023, and describes a 60 to 100 range over the previous several years.
• Counts get revised. GTIG's 2024 review (published April 2025) first reported 75 for 2024 and 98 for 2023. Its 2025 review raised them to 78 and 100. Quote the year of the report, not just the number.
• Enterprise share is at a high. GTIG reports 44% of 2024 zero-days hit enterprise technology in its 2024 review, and 48% (43) in 2025 in its 2025 review. Security and networking products made up about half of the enterprise share in 2025.
• Operating systems are the single largest category. GTIG's 2025 review puts desktop and mobile operating systems at 44% (39) of 2025 zero-days, while browsers fell below 10%.
• Project Zero's tracker is narrower than GTIG's count. By our count of the tracker on 25 October 2026, it lists 36 CVEs from 2024, 43 from 2025 and 25 from 2026 so far, because it only covers products Project Zero researches.
• Time to exploit is negative by definition. GTIG defines a zero-day as exploited before a patch is publicly available. The useful clock for defenders starts at the advisory.
• Safeguard's role is response, not discovery. In this post Safeguard appears only for finding exposure and fixing it: SBOM generation and analysis (GA), vulnerability management with KEV and EPSS (GA), reachability analysis (GA), policies and gates (GA), autonomous remediation (GA, ships switched off), CSAF and VEX upload (GA) and fork and patch (GA). The CLI (GA), local runner (GA) and the Claude connector (GA) are the ways in.

Where do the numbers come from?

Two public datasets carry most of the weight in any honest conversation about exploited zero-days. They measure different things, and mixing them without saying so is the most common error in vendor reports and conference slides.

GTIG's annual zero-day reviews

GTIG publishes a yearly analysis on the Google Cloud threat intelligence blog. The 2024 analysis, "Hello 0-Days, My Old Friend", was published on 29 April 2025. The 2025 analysis, "Look What You Made Us Patch", was published on 6 March 2026.

Both reports use the same definition. GTIG calls a vulnerability a zero-day when it "was maliciously exploited in the wild before a patch was made publicly available". Both reports also carry the same caveats, and they matter for everything that follows:

• The counts are based on detected and disclosed zero-days only. Exploitation nobody caught or nobody disclosed is missing.
• GTIG combines its own research and incident response findings with open source reporting it cannot always confirm independently.
• The numbers can change as forensic work uncovers older incidents. The 2025 review used a cutoff of 31 December 2025 and notes that every zero-day in its 2025 dataset now has a patch available.

Project Zero's "0day In the Wild" tracker

Google Project Zero maintains a public spreadsheet of zero-day exploits detected in the wild, with one row per CVE and columns for vendor, product, bug type, description, patch date, advisory and who reported it. The tracker's own notes set its scope tightly:

• It generally includes targets Project Zero has investigated or plans to investigate. Plenty of real zero-days in other products are left out on purpose.
• It excludes software that was explicitly end of life when the exploit was discovered.
• It excludes bugs exploited in the gap between public disclosure and a patch, because those were not secret at the time.
• It includes exploits that were leaked or found in a form that strongly suggests in-the-wild use, even if no breach was observed.

That scope is why the tracker's yearly totals sit well below GTIG's. Neither is wrong. GTIG counts across the whole market it can see. Project Zero's tracker is a deep, consistent record of the platforms Project Zero studies, mostly operating systems, browsers, mobile chipsets and office software.

How we counted the tracker

For this post we downloaded the tracker's combined sheet on 25 October 2026 and grouped rows by the year in the CVE identifier. That is close to, but not the same as, the year of disclosure. Four of the 36 CVEs from 2024, for example, carry a patch date in 2025. We also merged spelling variants of the same bug type, such as "Memory corruption" and "Memory Corruption". When this post says "Project Zero tracker, 2025", it means rows with a 2025 CVE identifier in the tracker as fetched on that date.

How many zero-days were exploited each year?

Here is every yearly figure the two sources give for 2022 onwards, with the report year attached so nobody has to guess which version a number came from.

Three readings stand out.

First, GTIG frames the trend as stabilisation. Its 2025 review says yearly totals have fluctuated within a 60 to 100 range over recent years and remained above pre-2021 levels. The 2024 review called the same pattern a slow but steady upward trendline. Neither report describes runaway growth.

Second, revisions are normal. GTIG's 2024 review reported 75 zero-days for 2024. Less than a year later, its 2025 review gave 78 for the same year and moved 2023 from 98 to 100. Both reports warn that numbers may change as past incidents come to light. If you cite a count in a board paper, cite the report and its date.

Third, the Project Zero tracker runs at roughly half of GTIG's count in recent years. That gap is mostly the enterprise appliance and enterprise software exploitation GTIG counts and the tracker does not try to cover. It is a scope difference, not evidence that one source missed half of the exploits.

Which product types are attackers targeting?

GTIG splits zero-days into two families. End-user platforms and products covers phones, desktop operating systems and browsers. Enterprise technologies covers software and appliances used mainly in business settings, including security and networking products.

Enterprise technology keeps growing as a share

GTIG's 2024 review found enterprise technology rose from 37% of zero-days in 2023 to 44% in 2024. Its 2025 review found 48% in 2025 and calls the shift structural. The reports give a clear reason. Security and networking devices sit at the edge with high privileges, they often cannot run endpoint detection tools, and a single bug in them can give an attacker code execution or administrative access without the multi-bug chains that phones and browsers now require.

GTIG's 2025 review adds that common flaws in these products were basic ones: missing input validation and incomplete authorisation checks. It describes them as systemic failures that are fixable with proper implementation standards.

The vendor spread matters too. GTIG's 2024 review counted 18 distinct enterprise vendors among 20 total vendors with exploited zero-days that year, compared with 22 of 23 in 2023. Its 2025 review says 20 vendors were exploited by exactly one zero-day each in 2025. In other words, the target list is long and varied, which makes inventory more important than any single vendor watchlist.

Operating systems are the largest single target

The 2025 review names operating systems, desktop and mobile together, as the most exploited product category of 2025, at 39 zero-days and 44% of the total. The 2024 review had already flagged desktop operating systems rising from 17 to 22, and Windows specifically climbing from 13 in 2022 to 16 in 2023 to 22 in 2024.

Browsers fell and mobile bounced back

GTIG's 2024 review reports browser zero-days falling from 17 to 11 and mobile from 17 to 9 between 2023 and 2024. The 2025 review then records mobile rebounding to 15, explaining that recent exploit chains used three or more vulnerabilities each and that researchers recovered more complete chains than in the past. Browsers dropped below 10% of 2025's total. GTIG reads that as partial evidence that browser hardening works, while noting that better attacker operational security may also hide some activity.

Two related details from the 2024 review are useful for product teams that build on Android or ship hardware. Exploit chains made of multiple zero-days were used almost entirely against mobile devices, around 90% of the time. And third-party components keep showing up in Android zero-days: three of seven in 2024 and five of seven in 2023 were in components from outside the core platform.

Which vendors show up most?

Vendor counts depend heavily on market share and attacker goals, so treat them as a picture of where attackers spend effort, not as a security ranking. GTIG says this directly in its 2024 review: exploitation does not necessarily reflect a vendor's security posture.

GTIG's vendor view

GTIG's 2024 review ranks the most exploited vendors of 2024 as Microsoft with 26 zero-days, Google with 11, a VPN and network access appliance vendor third with 7, and Apple fourth with 5. GTIG highlights the third place as a first: a security vendor targeted more often than a major consumer technology vendor. (House rule: we do not name security vendors in our posts. The GTIG report names it.)

GTIG's 2025 review describes the same pattern without restating every count: big technology vendors carry the most zero-days, security and networking vendors follow directly behind, and VPN and virtualisation platforms remain popular targets.

The Project Zero tracker's vendor view

Within its narrower scope, the tracker tells a more detailed story. Our counts from the tracker as fetched on 25 October 2026:

The swing in Google's count from 16 in 2024 to 8 in 2025 is mostly Android. The tracker lists 10 Android entries with 2024 CVE identifiers and only 2 with 2025 identifiers. Windows went the other way, from 9 entries in 2024 to 18 in 2025.

Look past the platform names and the 2025 and 2026 rows contain something AppSec teams should care about: shared components. The tracker's 2025 rows include an entry for the FreeType font rendering library and three GPU driver entries. The 2026 rows include Chrome entries described as flaws in Skia, the graphics library, and Dawn, the WebGPU implementation, alongside V8 and CSS bugs. Libraries like these are embedded in far more software than the product named in the vendor column. When a zero-day lands in a shared component, the question is not only "do we run that browser" but "which of our own products bundle that library".

What 2026 looks like so far

There is no GTIG review for 2026 yet, so the Project Zero tracker is the only per-CVE public source for this year. As of 25 October 2026 it lists 25 CVEs with 2026 identifiers:

• By vendor: Microsoft 14, Google 7, Apple 2, Adobe 1, Qualcomm 1.
• By product: Windows 7, Chrome 7, Office 4, iOS 2, SharePoint 2, Exchange 1, Acrobat Reader 1, a GPU component 1.
• By bug type: memory corruption 13, security feature bypass 8, and one each of authentication bypass, cross-site scripting, information disclosure and pointer authentication bypass.

Two things stand out. Security feature bypasses are a large share, eight of 25, driven mostly by four Office bypasses patched in January and February 2026. And Microsoft's server and identity products appear: two SharePoint entries, one Exchange entry and an identity federation service entry filed under Windows. Those are enterprise systems even though the tracker files them under a consumer vendor.

What kinds of bugs are exploited?

The bug classes have barely changed in years. That is useful, because it means the prevention work is well understood even if it is not always done.

GTIG's 2024 review says remote code execution and privilege escalation together accounted for over half of 2024's zero-days, 42 of them. Its 2025 review says the same ordering held in 2025: code execution first, then privilege escalation.

The practical split is clean. Memory safety bugs dominate the platforms in Project Zero's tracker. Injection, deserialisation, authentication bypass and logic flaws dominate the enterprise appliances and software in GTIG's wider count. GTIG notes in its 2024 review that all three of the most common types stem from development errors that safe coding practices, review and up-to-date libraries can prevent.

Who is exploiting zero-days?

Attribution only covers the share of zero-days GTIG can link to an actor, so these numbers describe a subset.

GTIG's 2025 review adds two observations relevant to defenders. China-nexus espionage groups focused on edge and networking devices that are hard to monitor. And more activity clusters are exploiting bugs close to public disclosure, which GTIG reads as faster exploit development and sharing between groups.

What does the data say about time to exploit?

This is the question most teams actually want answered, and it is where public data is thinnest.

Zero-days are exploited before the patch by definition

GTIG's definition settles the first point: every zero-day in its count was exploited before a patch was publicly available. Time to exploit, measured from the patch, is negative for every row. The meaningful clocks for a defender are different ones:

1. Time from first exploitation to vendor advisory. You do not control it.
2. Time from advisory to knowing whether you are exposed. You control it.
3. Time from knowing to a patch, mitigation or documented "not affected" decision. You control it.

GTIG's 2025 review gives a concrete case of the first clock. It reports that a financially motivated group exploited flaws in Oracle E-Business Suite, CVE-2025-61882 and/or CVE-2025-61884, as early as 9 August 2025, weeks before a patch was available, with suspicious activity dating back to 10 July 2025. The extortion emails that made the campaign public came in late September. That is roughly two months of exploitation before most defenders could act.

The gap after disclosure is shrinking

GTIG's 2025 review also describes the second half of the timeline. It reports that an increasing number of activity clusters exploit vulnerabilities closer to public disclosure, and describes a shrinking gap between the disclosure of n-day vulnerabilities and their widespread exploitation by multiple groups. In plain terms, once a zero-day is public, other attackers pile on faster than they used to.

The same review's 2026 forecast expects attackers to use AI to speed up reconnaissance, vulnerability discovery and exploit development, which would put more pressure on the advisory-to-fix clock defenders own.

Patch cadence in the Project Zero tracker

The tracker records a patch date for every row, which shows when defenders were first able to act. For the 25 CVEs from 2026, patch dates fall like this, by our count on 25 October 2026:

February stands out, with five Microsoft fixes on a single day, 10 February 2026, plus Apple and Chrome fixes in the same week. That clustering is normal for monthly patch cycles, and it is exactly when teams without an inventory fall behind: several exploited fixes land at once, and the team spends the first day working out where each one applies.

What public data does not tell you about timing

Neither GTIG's reviews nor the Project Zero tracker publish an average time from advisory to mass exploitation for 2024 or 2025. The tracker leaves its "Date Discovered" column unknown for most rows. A separate Google Cloud time-to-exploit study covering 2023 exists, and it is worth reading in full for its method and its outlier caveats, but it is not part of the GTIG or Project Zero data this post relies on. Be wary of any average "days to exploit" figure that does not tell you which vulnerabilities it includes and how it handled outliers. Our earlier post on whether time to exploit is really shrinking or the mix is changing goes deeper on that trap.

How do you read these numbers without fooling yourself?

A few habits keep this data honest when you use it in planning or reporting.

Always cite the report year. "75 zero-days in 2024" and "78 zero-days in 2024" are both GTIG figures. The first is from April 2025, the second from March 2026.

Do not compare GTIG totals with tracker totals as if they measure the same thing. The tracker's scope is the products Project Zero researches. GTIG's count is market wide.

Remember detection bias. GTIG says plainly that edge device numbers likely understate the true scale, because those devices rarely run detection tools. A low count in a category can mean low visibility, not low risk.

Separate exploited zero-days from exploited vulnerabilities in general. Most of the vulnerabilities your teams patch were never zero-days. CISA's Known Exploited Vulnerabilities catalog tracks known exploitation regardless of whether it began before or after a patch, which makes it a better daily input for prioritising than zero-day counts. For US federal agencies, CISA's BOD 26-04, dated 10 June 2026, prioritises security updates based on risk and revokes BOD 22-01, so read older fixed-deadline KEV advice as history.

Use vendor counts for inventory questions, not for procurement verdicts. GTIG warns that exploitation reflects attacker goals as much as vendor quality.

What does the data mean for an AppSec or product security team?

Turn the numbers into decisions about your own estate. Four patterns in the data map to specific work.

1. Edge and security appliances deserve their own inventory

GTIG's two reviews put security and networking products at 20 of 2024's zero-days and 21 of 2025's, with edge devices that lack endpoint tools. Those appliances are usually patched by a network or infrastructure team, not AppSec, and they rarely appear in software bills of materials. Make sure someone owns a current list of every appliance, its firmware version and its management interface exposure.

2. Shared components are where AppSec teams can act fastest

The Project Zero tracker's 2025 and 2026 rows include flaws in a font library, graphics libraries and GPU components that ship inside many products. GTIG's 2024 review found most Android zero-days in 2023 came from third-party components. If you build software, the libraries you bundle are part of your attack surface and your customers' attack surface. A software bill of materials for every product you ship is how you answer "do we include this component, at which version, and where" within minutes.

3. Most bug classes are preventable

Memory safety bugs, injection, missing authorisation and logic flaws account for most rows in both datasets. Secure development practices, code review, memory safe languages for new code and current libraries reduce the next generation of these bugs. That is long work, but GTIG's own reports point to it.

4. The clock you control starts at the advisory

You cannot shorten the period before a vendor publishes a fix. You can shorten the time from advisory to exposure answer and from exposure answer to a fix or documented decision. That is where tooling earns its keep.

How Safeguard helps after a zero-day is disclosed, step by step

Safeguard does not tell you about zero-days before vendors do, and this post makes no claim that it does. What it does is speed up the response clock once an advisory is public, for the software you build and the open source and container components inside it. Each step below uses commands and screens as Safeguard's docs show them.

Step 1: Keep a current SBOM for every product (SBOM generation and analysis, GA)

Exposure questions are only fast if the inventory already exists. The Safeguard CLI (GA) builds an SBOM for a target, matches it against vulnerability data and writes a report. From Safeguard's CLI usage docs:

safeguard scan --dir .
safeguard scan --image nginx:latest
safeguard scan --sbom sbom.json

The docs note that safeguard scan does not fail on findings, so it is safe to run on every build to keep the inventory current. You can also scan an SBOM a supplier sends you with --sbom, as shown above. If your code cannot leave your network, the local runner (GA) scans on your own machine and sends only results.

Step 2: When an advisory lands, find every place the component lives

Once a zero-day affects a library or image you might ship, open the project in Enterprise Software Supply Chain Manager and go to Explore SBOM. The docs describe a Dependencies tab with a tree view and a sortable, filterable table of every component, version and vulnerability count, and a Vulnerabilities tab with a severity breakdown, the affected component details, fix recommendations and an AI Remediate button. Vulnerability management (GA) enriches findings with CISA KEV status and EPSS scores, so an exploited-in-the-wild flaw is visibly different from a theoretical one, and the reachability docs describe a priority column in the vulnerabilities table. If your CI already gates on the CVE (Step 4), failing builds also show you where the component lives.

The SBOM incident response approach is covered in more detail in finding affected products fast with SBOMs.

Step 3: Rank by reachability (GA)

Not every project that includes a vulnerable library calls the vulnerable code. Safeguard's reachability analysis classifies each finding as reachable, conditional, unreachable or unknown. The docs say "unknown" covers cases the analyser cannot decide, such as dynamic dispatch, reflection or native code, and that those are marked conservatively rather than hidden. Call-path depth differs by language, and the docs say Ruby resolution is conservative for metaprogramming, so check the language table before relying on an "unreachable" result.

Use the ranking to order work, not to close tickets on its own. A memory corruption bug triggered by crafted input can be exercised through paths static analysis does not see. The post on prioritising with reachability, EPSS and KEV in Safeguard covers the edge cases.

Step 4: Stop new builds from shipping the vulnerable version (policies and gates, GA)

Safeguard's Policies and Gates docs separate the two: a policy defines a rule, a gate enforces it at a checkpoint such as CI or release. Each policy has an action that decides what a failure does to the gate:

In CI, the docs show the scan and gate step like this:

curl -fsSL https://cli.safeguard.sh/install | bash
SAFEGUARD_API_KEY=... safeguard ci scan --wait --fail-on critical \
  --repository-url "$REPO_URL" --branch "$BRANCH" --commit "$COMMIT"

A sensible zero-day pattern is to set a policy covering the affected component to Warn on the day of the advisory, so teams see it without breaking every build, then move it to Block once a fixed version is available and the first fixes have merged. The policies post in our offering series, plain English security policies to release gates, walks through exceptions.

Step 5: Open the fix pull requests (autonomous remediation, GA, ships switched off)

When a fixed version exists, Safeguard's AI Remediate can propose the upgrade and open a pull request for a single vulnerability, in bulk across projects, or for a whole page of findings. The settings include Auto-Create PRs, Require Approval and Test Integration, and pull requests carry a breaking change rating. Autonomous remediation ships switched off, with every category set to Manual, so nothing opens on its own until your team changes that. More detail is in autonomous remediation in Safeguard.

Step 6: Record "not affected" decisions with VEX (CSAF and VEX upload, GA)

For products that include the component but are not affected, for example because the vulnerable function is not compiled in, record that decision as a VEX statement. Safeguard supports CSAF and VEX upload, so your statements and your suppliers' statements sit beside the findings they explain. Customers asking "are you affected" get a document, not an email thread. See ingesting and sharing VEX and CSAF in Safeguard.

Step 7: Ask the same questions from Claude

If your team works in Claude, add Safeguard from Claude's connector directory, where it is listed as a community connector, sign in, and choose which tools Claude may use. You can then ask questions such as "which projects include the affected version" or "list KEV vulnerabilities in this product" and get answers from your own Safeguard data.

When there is no fixed version yet

For a short time after disclosure there may be no fixed release of an open source component you ship. Safeguard's fork and patch service (GA) covers that gap for open source dependencies; the block further down describes it. For the appliance and operating system zero-days that dominate GTIG's counts, the fix still has to come from the vendor.

Decision table: from data signal to action

What Safeguard does not do

Being specific about limits matters more in a zero-day post than anywhere else.

• It does not tell you about zero-days ahead of vendors. Nothing in this post describes Safeguard finding, predicting or pre-announcing an exploited zero-day. The response steps start when a public advisory or CVE exists.
• It does not patch vendor appliances, operating systems or hosted services. Most of GTIG's enterprise zero-days are in security and networking appliances and enterprise software you buy rather than build. Those fixes come from the vendor; Safeguard can track supplier SBOMs and VEX statements you import, but it cannot change the firmware on your VPN concentrator.
• It does not detect exploitation in your environment. Safeguard tells you where a vulnerable component exists and how to fix it. Finding whether someone already used the flaw against you is incident response and detection work for other tools and teams.
• Reachability can be uncertain. Analysis depth differs by language, and the docs classify undecidable cases as unknown. Treat "unreachable" as a ranking input, not as proof of safety.
• It does not replace your patch management. Endpoint and server operating system patching, including the Windows and mobile zero-days that make up much of the Project Zero tracker, stays with your existing tools.
• It does not make secret scanning or malicious package claims in this context. This post covers known vulnerabilities in components only.
• REST endpoints are not the path today. Safeguard's reachability docs carry a banner saying the /v1 REST endpoints are not yet available. Use the CLI, CI integration, the web app or the Claude connector.

Common mistakes

Quoting a count without its report year. The 2024 total is 75 in GTIG's April 2025 report and 78 in its March 2026 report. Leaving out the report date makes you look wrong to anyone who has read the other one.

Adding GTIG and Project Zero counts together, or comparing them directly. They overlap heavily and measure different scopes.

Reading a falling browser count as "browsers are safe now". GTIG attributes part of the drop to hardening and part to attackers hiding better.

Treating vendor rankings as security ratings. GTIG says exploitation reflects attacker objectives and capability, not necessarily the vendor's development practices.

Ignoring components because the advisory names a product. A Chrome advisory for a graphics library flaw can matter to your desktop app, your PDF renderer or your embedded device.

Waiting for perfect data before acting. The tracker leaves discovery dates unknown for most rows, and GTIG's edge numbers are undercounts by its own account. Act on exposure, not on certainty about attacker timelines.

Using an average "days to exploit" figure from an unnamed dataset. Averages swing hugely with outliers. If the source does not say what it included, do not plan around it.

Letting a Warn policy sit forever. Warn is right on day one. If it is still Warn a month after a fixed version shipped, it has become a permanent exception.

FAQ

How many zero-days were exploited in 2025?

GTIG's 2025 zero-day review, published 6 March 2026, tracked 90 zero-day vulnerabilities exploited in the wild in 2025. Project Zero's tracker, which has a narrower scope, lists 43 CVEs with 2025 identifiers as of 25 October 2026 by our count.

How many zero-days were exploited in 2024?

GTIG first reported 75 in its 2024 review, published 29 April 2025, and revised it to 78 in its 2025 review. Project Zero's tracker lists 36 CVEs with 2024 identifiers by our count on 25 October 2026.

Which vendor had the most exploited zero-days?

In GTIG's 2024 review, Microsoft led with 26 zero-days in 2024, followed by Google with 11. In the Project Zero tracker, Microsoft leads for 2025 with 19 and for 2026 to date with 14.

Are zero-days increasing?

Not sharply. GTIG's 2025 review says yearly totals have stayed within a 60 to 100 range and calls the trend a stabilisation, while still above pre-2021 levels.

What share of zero-days target enterprise products?

GTIG reports 44% for 2024 in its 2024 review, revised to 46% in its 2025 review, and 48% for 2025, the highest share it has recorded.

What is the difference between GTIG's count and Project Zero's tracker?

GTIG counts all exploited zero-days it can track across the market. Project Zero's tracker covers mainly products Project Zero researches, excludes end of life software and excludes bugs exploited only after public disclosure. The tracker is narrower but has per-CVE detail.

What is the most common type of exploited zero-day?

Memory safety bugs. GTIG's 2025 review puts them at roughly 35% of 2025 zero-days, mainly use-after-free and out-of-bounds write. In the Project Zero tracker, memory corruption accounts for 31 of 43 entries with 2025 identifiers.

How fast are zero-days exploited after disclosure?

By GTIG's definition a zero-day is exploited before a patch exists, so there is no "after" for the first attacker. GTIG's 2025 review reports that more groups are exploiting vulnerabilities closer to public disclosure. Neither GTIG's reviews nor the tracker publish an average time-to-exploit figure for 2024 or 2025.

Is there 2026 zero-day data yet?

Only in the Project Zero tracker so far. It lists 25 CVEs with 2026 identifiers patched between 13 January and 13 October 2026, by our count on 25 October 2026. GTIG's 2026 review would normally appear in the first half of 2027.

Can Safeguard find zero-days before they are published?

This post does not make that claim. It describes Safeguard's role after disclosure: finding where an affected component lives, ranking it, gating new builds and opening fix pull requests.

Close the open source gap after disclosure

Public zero-day data shows that the defender's clock starts at the advisory, and for open source components the next delay is waiting for a fixed release to reach your builds. The block below is the standard summary of how Safeguard closes that gap for the dependencies and images you build and ship; it does not apply to vendor appliances.

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

These demos show the response side of the workflow above: checking exposure, fixing a known CVE and asking questions of your own data. None of them shows Safeguard finding unknown vulnerabilities, because this post does not claim that.

The first demo is a real Safeguard CLI session. It opens the interactive terminal, is asked to "fix the lodash CVE in this repo", reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval and prints a summary without pushing anything. After a zero-day advisory in an open source dependency, the same flow applies once a fixed version is published.

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

The second demo shows Claude connected to Safeguard: you sign in with OAuth and choose which tools Claude can use. In practice you add Safeguard from Claude's connector directory, then ask which of your projects include an affected component.

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

The third demo sets up the local runner on your own machine, approves it with its device code and scans from the terminal. Use it when the code that bundles an affected library cannot leave your network.

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

To try the response workflow on your own code, download the CLI or desktop app at safeguard.sh/download and follow the setup guides at docs.safeguard.sh. For related reading, see what a zero-day is, zero-day versus n-day time-to-exploit data, vulnerability exploitation trends in 2024, what KEV, EPSS and exploit databases cannot tell you and VPN and edge appliance zero-days as initial access.

Quick check

Sources

• GTIG: Hello 0-Days, My Old Friend, a 2024 zero-day exploitation analysis (29 April 2025)
• GTIG: Look What You Made Us Patch, 2025 zero-days in review (6 March 2026)
• Google Project Zero: 0day "In the Wild" tracker (fetched 25 October 2026)
• Google Project Zero: 0days In the Wild root cause analyses
• Google Cloud: an analysis of 2023 time-to-exploit trends (October 2024)
• CISA: Known Exploited Vulnerabilities catalog
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: Cybersecurity directives
• Safeguard docs home
• Safeguard docs: CLI usage
• Safeguard docs: Explore SBOM
• Safeguard docs: Vulnerability prioritisation and reachability analysis
• Safeguard docs: Policies and Gates
• Safeguard docs: AI Remediate
• Safeguard download page
• Gold Open Source

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