What Share of Vulnerabilities Actually Get Exploited?

A small share. Of more than 300,000 CVEs published since 1999, CISA's Known Exploited Vulnerabilities catalog lists 1,754, roughly half of one percent. Broader measures that count any observed exploitation activity land between about 1% and 3%. The count of exploited vulnerabilities keeps rising each year, but the share mostly does not, because new CVEs grow faster.

That answer is useful, and it is also easy to misuse. "Only 2% get exploited" is a good reason to stop treating every critical CVSS score as an emergency. It is a bad reason to tell a board that 98% of your backlog does not matter. This post covers where the numbers come from, why they disagree, which flaws make up the exploited slice, how to turn the base rate into a remediation order, and how to report it upward without understating risk.

Key takeaways

• CVE volume is at a record. One widely cited independent review counted 48,185 CVEs published in 2025, up 20.6% from 39,962 in 2024, and 308,920 since 1999. NIST says CVE submissions rose 263% between 2020 and 2025.
• Confirmed exploitation is rare. CISA's KEV catalog held 1,754 entries on 21 October 2026. In 2025 CISA added 245, of which about 151 were CVEs disclosed that year. That is roughly 0.3% of the year's CVEs.
• Broader signals give bigger, still small, numbers. FIRST says about 2 to 3% of published vulnerabilities show exploitation activity in any 30 day period. One exploit intelligence firm's ratio of newly exploited CVEs to new CVEs was 1.4% in the first half of 2026, down from 1.9% a year earlier.
• The count rises, the share mostly does not. One threat intelligence firm counted 215 actively exploited vulnerabilities in the first half of 2026, up 34% year on year, while the CVE denominator grew even faster.
• The exploited slice is lopsided. Edge devices, remote access, content management systems and operating systems dominate; library CVEs are rarer.
• Severity is a poor filter on its own. 39.4% of 2025 CVEs were rated critical or high. Patching by CVSS alone means treating about 40% of everything as urgent to catch a slice that is a few percent.
• Not exploited yet is not the same as safe. One firm found exploitation was reported an average of 564 days after disclosure. Defer with a written trigger to revisit, never indefinitely.

How many CVEs are published per year now?

The CVE program publishes more records every year, and 2025 was another record. An independent annual review of CVE data counted 48,185 published CVEs in 2025, excluding rejected records, against 39,962 in 2024. That is growth of 20.6% in one year. The same review puts the cumulative total since 1999 at 308,920.

The pace has not slowed in 2026. When NIST changed how it enriches records in the National Vulnerability Database in April 2026, it said CVE submissions had grown 263% between 2020 and 2025 and that the first three months of 2026 were nearly a third higher than the same period in 2025. FIRST's guidance on using EPSS refers to roughly 61,000 CVEs published over a recent 12 month period. NIST said it enriched 42,000 CVEs in the previous year and still could not keep up.

The severity mix matters for the rest of this post. The same 2025 review breaks the year's CVSS scores down like this:

Nearly 19,000 CVEs a year score critical or high. Compare that with how many get exploited.

The most common weakness in 2025 was cross site scripting (CWE-79), with 8,207 CVEs, much of it in small web plugins. And the NVD no longer enriches everything. NIST now prioritises CVEs added to KEV, software used by federal agencies and critical software as defined under Executive Order 14028. Unenriched CVEs published before 1 March 2026 moved to a "Not Scheduled" status. If your tooling depends on NVD product mappings to match CVEs to software, some new records will arrive without them. For more on that gap, see NVD enrichment delays and vulnerability database strategy.

How many vulnerabilities show evidence of exploitation?

There is no single official answer, because "exploited" is measured in different ways. Here are the main sources, from narrowest to broadest.

CISA KEV: confirmed exploitation with a clear fix

CISA adds a vulnerability to its Known Exploited Vulnerabilities catalog only when three conditions hold. It must have a CVE ID. There must be reliable evidence that it has been actively exploited in the wild; attempted exploitation counts, but scanning, security research and proof of concept code do not. And there must be clear remediation guidance, such as a vendor update or, for an end of life product, removing it.

On 21 October 2026, the catalog's JSON feed (version 2026.10.21) listed 1,754 entries. Coverage of the 2025 year end put the catalog at 1,484 entries, up from 1,239 at the end of 2024. Annual additions were 185 in 2024 and 245 in 2025. Subtracting the year end figure from today's count suggests about 270 net additions so far in 2026, a derived figure that ignores any removals.

What does that mean as a share?

• Against all CVEs ever published: 1,754 out of more than 308,920 is about 0.57%. Because the denominator excludes 2026 CVEs, the true share is a little lower.
• Against one year: of the 245 entries added in 2025, 94 were CVEs disclosed in 2024 or earlier. That leaves roughly 151 that were disclosed in 2025, which is about 0.3% of the year's 48,185 CVEs.

KEV is narrow on purpose: every entry is confirmed and has a fix. It undercounts exploitation of products without a clear remediation, flaws without a CVE, and attacks nobody reported to CISA.

Vendor and threat intelligence counts: broader evidence

Commercial intelligence firms keep their own catalogs from incident response cases, honeypots, malware analysis and public reporting. They usually count more than KEV because they do not require a remediation.

Two recent figures show the scale:

• One threat intelligence firm counted 215 actively exploited vulnerabilities in the first half of 2026, up 34% on the same period a year earlier. It also reported that exploitation was reported or detected an average of 564 days after disclosure, which says attackers keep using older flaws.
• One exploit intelligence firm counted 495 CVEs with first time evidence of exploitation in the first half of 2026. It put the ratio of those newly exploited CVEs to newly published CVEs at 1.4%, down from 1.9% in the first half of 2025.

Those counts differ by more than a factor of two over the same six months, which the next section explains.

EPSS: exploitation activity seen by sensors

The Exploit Prediction Scoring System, maintained by a special interest group at FIRST, estimates the probability that a CVE will see exploitation activity in the next 30 days. Scores run from 0 to 1, come with a percentile, and are published daily for every CVE.

EPSS is trained on exploitation activity collected by nearly a dozen data partners across endpoint malware telemetry, honeypots, intrusion detection and prevention systems, and threat intelligence feeds. FIRST is explicit that this records exploitation attempts, not necessarily successful compromise.

FIRST's guidance gives the base rate directly: roughly 2 to 3% of published vulnerabilities show exploitation activity in a given 30 day period. The mean EPSS score is about 2.8% and the median about 0.7%. FIRST also notes that a model which predicted no exploitation for anything would be 97 to 98% accurate, which tells you how rare the event is. A paper from the EPSS special interest group reported that the newer machine learning model gave an 82% performance improvement over earlier versions, but no model removes the uncertainty that comes with such a rare event.

Zero days: exploited before a fix exists

Zero days are a small, important subset. One major threat intelligence group tracked 90 zero days exploited in 2025, up from 78 in 2024 and below the record 100 in 2023. A large hacking competition in Ireland this October produced 98 new zero day findings in a single event, with $1,262,000 paid out. Those competition bugs go to vendors under a 90 day disclosure window, so they are not exploited in the wild, but they show how many unknown flaws sit in widely used products at any time.

AI found vulnerabilities

The exploit intelligence firm cited above tracked 1,061 CVEs discovered with AI tools and found real world exploitation evidence for 14 of them, or 1.3%, in line with the overall base rate. More discovery raises the denominator first. For the operational side of that, see AI is finding vulnerabilities faster than we can patch.

Why do the numbers differ so much between sources?

Executives often see 0.3%, 1.4%, 2%, 5% and "one in four" quoted for what sounds like the same question. They are usually all correct, because each one measures something different. Six choices drive the gap.

A few concrete consequences:

1. KEV versus a vendor count. KEV requires a CVE and a clear remediation. A firm that counts exploitation of unpatched products or flaws without CVEs will always report more.
2. Per period versus ever. The 1.4% figure divides newly exploited CVEs by newly published CVEs in six months. The KEV share divides everything ever confirmed by everything ever published. Different questions.
3. Selection effects. "One in four" style headlines usually describe a filtered population, such as vulnerabilities exploited on or before the day their CVE was published, as a share of the exploited set. That is a statement about speed among exploited flaws, not about what share of all CVEs get exploited. Always ask what the denominator is. Showing the denominator covers how to read and present these percentages.
4. Attempts versus compromise. EPSS learns from attempts, which is useful for prediction but is not a breach count.

Pick the definition that fits the decision you are making. For "what must we patch this week", KEV plus your own exposure is the right narrow filter. For "what is likely to be next", EPSS is the right forward looking one. For "how big is the problem", give the range and say how each number was measured.

Is the exploited share rising, or just the absolute count?

Mostly the count. The evidence points the same way across sources:

• KEV additions went from 187 in 2023 and 185 in 2024 to 245 in 2025, and about 270 in 2026 so far.
• One threat intelligence firm's first half count rose 34% year on year.
• Zero days tracked by one group moved from 78 in 2024 to 90 in 2025.

Over the same period CVE publication grew by about a fifth per year, and NIST reported submissions in early 2026 running a third above early 2025. The one source that publishes a ratio over matching periods, the exploit intelligence firm's newly exploited to newly published measure, shows the share falling from 1.9% to 1.4%.

So the honest summary is this. Attackers are exploiting more distinct vulnerabilities each year. Defenders and researchers, increasingly helped by automation, are publishing far more CVEs each year. The second number is growing faster, so the exploited share is flat to slightly down.

Two consequences follow. A team that tries to fix every critical CVE falls further behind each year. And the work that does matter still grows in absolute terms: more exploited vulnerabilities means more emergency patch cycles, whatever the percentage says. For more on how the timing shifts, see is time to exploit really shrinking, or is the mix changing.

Which kinds of vulnerabilities get exploited most?

The exploited slice is not a random sample of all CVEs. It is concentrated in products that are reachable from the internet, trusted by everything behind them, and hard to monitor.

Edge devices and remote access

VPN gateways, firewalls, load balancers, file transfer appliances and remote support tools appear again and again. The threat intelligence firm behind the 215 count said gateway products such as SSL VPNs, firewalls and virtualisation layers were frequently exploited in the first half of 2026, alongside remote access utilities and other edge devices. In the 2025 zero day review, 43 of the 90 zero days (48%) hit enterprise technology, the highest share on record. Of those, 21 were in security and networking products and 14 in edge devices such as routers, switches and gateways. The group noted that edge device numbers are likely an undercount, because these appliances rarely run endpoint detection. Coverage of CISA's 2025 additions lists OS command injection, deserialisation of untrusted data, path traversal and improper authentication among the most common weaknesses, which fits this profile.

Content management systems and web runtimes

The exploit intelligence firm found content management systems were the most targeted category in the first half of 2026, with 163 newly exploited vulnerabilities. These are internet facing, widely deployed and extended by thousands of plugins, many of which generate CVEs. Web runtimes and frameworks belong in the same bucket when an application exposes them directly.

Operating systems and browsers

Operating systems were the single most exploited category in the 2025 zero day review, with 39 flaws, often used for privilege escalation after initial access. Browsers accounted for under 10% of zero day activity in 2025.

Open source library CVEs

Library CVEs are the bulk of what a software composition analysis tool reports, and they are underrepresented in KEV. Most library flaws need a specific code path, configuration or input to be reachable, and many are denial of service bugs or issues in features few applications use. KEV does contain library and framework entries, Log4Shell being the best known, and those few cases are severe because one library sits in thousands of products at once.

So the pattern looks like this:

For an engineering leader: most exploited risk by count lives in infrastructure you buy and run, while most finding volume lives in libraries you build with. They need different processes.

What does this mean for a dependency backlog of thousands of findings?

Take a realistic example. A mid sized organisation scans 300 services and gets 4,000 open dependency findings. Using the 2025 severity mix as a rough guide, about 1,600 of those would be critical or high. Now apply the base rates:

• If roughly 0.5% of distinct CVEs are in KEV, a backlog of 4,000 findings that maps to, say, 900 distinct CVEs might include four or five KEV entries.
• If 2 to 3% show any exploitation activity in a month, that might be 20 to 25 CVEs with recent activity.
• Of those, only some will sit in code your services actually call, in a version that is actually deployed, in a service exposed to untrusted input.

These numbers are illustrative, not predictions. The shape matters: a few dozen findings deserve attention this week, a few hundred a planned upgrade, and several thousand can go through routine dependency updates, as long as the routine exists.

What that means in practice:

1. Stop treating the CVSS band as the queue. Sorting by CVSS puts about 40% of all findings into the urgent pile. That is not a priority, it is a backlog with a different label.
2. Deduplicate by CVE and by package version first. One vulnerable version of a popular package in 200 services is one decision and one upgrade, not 200 tickets.
3. Separate "fix now" from "fix by upgrade". The small exploited and reachable slice needs a deadline in days. Everything else can ride a scheduled upgrade train that keeps dependencies current, which retires most findings without anyone triaging them individually.
4. Keep the long tail moving. Today's non urgent pile is where next year's exploited flaws come from.

How many CVEs are in KEV and what they share goes deeper on the KEV side of this, and CVEs from 2019 to 2023 still being exploited in 2026 shows why old findings are not automatically safe.

How do exploitation signals, reachability and exposure combine into a priority?

No single signal gives you a good queue. Each answers a different question:

FIRST's own guidance supports combining them. It says to treat KEV listed vulnerabilities as actively exploited and prioritise them regardless of EPSS score, and that confirmed and recent exploitation evidence should take precedence over the score when it exists. It also says EPSS scores are population level and should be combined with asset inventory and local context.

CISA's BOD 26-04, issued on 10 June 2026, turns that logic into federal policy. It replaces the older KEV deadlines in BOD 22-01 and the internet facing rules in BOD 19-02 with timelines driven by four factors:

1. Asset exposure: is the vulnerable asset publicly reachable by unauthenticated or untrusted parties?
2. KEV status: is the CVE in the KEV catalog?
3. Exploit automation: can an attacker automate every step of exploitation?
4. Technical impact: does exploitation give partial or total control of the asset?

The most urgent combinations require remediation within three days plus a forensic triage to check whether the asset was already compromised. At the other end, some combinations can wait for the next scheduled major upgrade or rebuild, unless conditions change. Timelines are dynamic: taking an asset off the internet can lengthen its window, and a new KEV listing can shorten it. CISA publishes KEV status, automatability and technical impact for CVEs through its Vulnrichment programme. Agencies had 60 days to update processes and 180 days to meet the new timelines. Private organisations are not bound by it, but CISA encourages everyone to adopt similar practices. More detail is in CISA BOD 26-04 KEV remediation timelines and forensic triage.

CISA's SSVC model uses a similar idea, with outcomes running from Track (remediate within standard timelines) to Act (leadership meets and remediation happens as soon as possible).

Here is a simple version you can adopt for application dependencies, adapted from those ideas:

Reachability deserves a closer look because it is the signal that applies most to library CVEs. A package level match says "this version is installed". A function level analysis asks whether your code ever calls the vulnerable function, through any path. For many library advisories the answer is no, and that is a legitimate reason to move a finding down a tier. It is not a reason to close it, because code changes. See reachability analysis explained: function level versus package level for how the two approaches differ.

Where Safeguard fits

Safeguard's vulnerability management matches dependencies from repositories, container images and SBOM files against vulnerability sources including NVD, GitHub advisories, OSV, CISA KEV and vendor bulletins, and enriches findings with EPSS and KEV status. Its reachability analysis and prioritisation combine those exploit signals with static, dynamic and configuration reachability and with runtime and business context into a single priority, so the small exploited and reachable slice rises to the top of the list. Griffin, Safeguard's remediation models, can then turn that slice into fix pull requests. Remediation ships switched off, so your team chooses what runs automatically.

What it does not do: it does not predict which CVE will be exploited next with any guaranteed accuracy, and it does not replace your vendor's patch for an appliance, a hosted service or an operating system you do not build.

Step by step: build an exploitation aware queue from your own findings

The walkthrough below uses free, public data and standard tools. Adapt the commands to your ecosystem.

1. Pull the KEV catalog

CISA publishes KEV as JSON. Save the list of CVE IDs:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  -o kev.json
jq -r '.catalogVersion, .count' kev.json
jq -r '.vulnerabilities[].cveID' kev.json | sort -u > kev-cves.txt
wc -l kev-cves.txt

2. List the CVEs in your dependencies

Use the scanner you already have. Some examples:

# Python: pip-audit reports CVE aliases for each advisory
pip-audit -f json -o pip-audit.json
jq -r '.dependencies[].vulns[]?.aliases[]? | select(startswith("CVE-"))' pip-audit.json \
  | sort -u > my-cves.txt

# Go: govulncheck reports only vulnerabilities whose symbols your code calls
govulncheck ./...

# Maven: find which modules pull in a given library version
mvn dependency:tree -Dincludes=org.apache.logging.log4j

# Node.js: list the installed versions of a package across the tree
npm ls lodash --all

With the Safeguard CLI you can scan a directory, an image or an SBOM file in one step. Results are written as JSON under ./output:

safeguard scan --dir .
safeguard scan --image registry.example.com/payments:2026.10.20
safeguard scan --sbom sbom.cdx.json

3. Intersect with KEV

comm -12 my-cves.txt kev-cves.txt > my-kev-hits.txt
cat my-kev-hits.txt

Every line in my-kev-hits.txt is a candidate for the top tier. Check whether the affected service is exposed and whether the code path is reachable, then act.

4. Add EPSS scores

FIRST provides a free API. You can query a batch of CVEs in one call:

CVES=$(paste -sd, my-cves.txt)
curl -s "https://api.first.org/data/v1/epss?cve=${CVES}" \
  | jq -r '.data[] | [.cve, .epss, .percentile] | @tsv' \
  | sort -k2 -gr > my-epss.tsv
head -20 my-epss.tsv

For long lists, split into batches of a hundred or so. Sort by EPSS, but remember the scores are probabilities for a 30 day window, not verdicts. A KEV entry with a low EPSS score still belongs at the top.

5. Add reachability and exposure

For Go, govulncheck already separates called from merely imported vulnerabilities. Elsewhere, use a reachability capable scanner, and record which services are internet facing. Even a column that says "public", "internal" or "batch only" beats sorting by CVSS.

6. Assign tiers and dates

Apply the tier table above. Write the target date next to each finding, and for anything you defer, write the trigger that would bring it back.

7. Keep it fresh in CI

KEV changes several times a week. A scheduled workflow can recheck your lockfiles against it daily and fail loudly when a new listing touches something you ship:

name: kev-watch
on:
  schedule:
    - cron: "17 6 * * *"
  workflow_dispatch:
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Fetch KEV
        run: |
          curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json -o kev.json
          jq -r '.vulnerabilities[].cveID' kev.json | sort -u > kev-cves.txt
      - name: Audit dependencies
        run: |
          pip install pip-audit
          pip-audit -r requirements.txt -f json -o audit.json || true
          jq -r '.dependencies[].vulns[]?.aliases[]? | select(startswith("CVE-"))' audit.json | sort -u > my-cves.txt
      - name: Fail on KEV match
        run: |
          comm -12 my-cves.txt kev-cves.txt > hits.txt
          if [ -s hits.txt ]; then echo "KEV listed CVEs in dependencies:"; cat hits.txt; exit 1; fi

This is a starting point that catches the narrowest, most urgent slice automatically.

Does "not exploited yet" mean it is safe to defer, and for how long?

No, it means it is reasonable to defer with conditions. Three facts argue against treating "no exploitation seen" as "safe":

• Exploitation often comes late. One threat intelligence firm reported that exploitation in the first half of 2026 was reported or detected an average of 564 days after disclosure. Attackers come back to old flaws, especially in edge devices that stay unpatched.
• Some exploitation comes first. Zero days are exploited before any fix exists, and a meaningful share of known exploited vulnerabilities are exploited on or before the day their CVE is published. Can attackers exploit a vulnerability before it is disclosed? covers that timing.
• The signals lag and sample. FIRST notes that EPSS only sees what its partners' sensors observe, that brand new CVEs have sparse signal, and that low scores mean rarity, not zero risk. KEV only lists what CISA can confirm.

A defensible deferral has four parts:

1. A reason. Not reachable, not exposed, compensating control in place, or no fix available yet.
2. An owner. Someone whose name is on the decision.
3. A review date. For not reachable and not exploited findings, the next dependency upgrade cycle is a sensible ceiling, often 30 to 90 days. For reachable findings with no exploitation, shorter.
4. Triggers that end the deferral early. A KEV listing, a jump into a high EPSS percentile, a public exploit, a change that makes the service internet facing, or a code change that makes the vulnerable path reachable.

BOD 26-04's "fix on system upgrade" tier works on the same principle: low risk combinations wait for the next scheduled rebuild unless conditions change. The phrase "unless conditions change" is the important part.

How should you report this to a board without understating risk?

Boards hear "thousands of vulnerabilities" and "only 2% matter" in the same quarter and lose trust in both. Report in a way that holds up when someone checks.

1. Show both numbers and the denominator. "We have 4,000 open dependency findings across 300 services. Of those, 6 are in CISA's known exploited list, and 2 of those 6 are in internet facing services where our code calls the vulnerable function." Every percentage gets its base.
2. Report time, not just counts. Median days to remediate KEV listed findings in exposed services is the metric that tracks real risk. Counts go up whenever scanners improve; time to fix the dangerous slice should go down.
3. Show the long tail is moving. Track the age of the oldest open critical finding.
4. Name what you cannot see, such as appliances and hosted services, and say how you track their advisories.
5. Do not promise prediction. "We prioritise using exploitation evidence, reachability and exposure" is accurate. "We know which 2% will be exploited" is not, and nobody can say it honestly.

A useful framing for executives: the exploited share is small, the absolute number is growing, and the cost of missing one exploited, reachable, exposed flaw is high. That justifies a fast lane for a few findings, a steady upgrade train for the rest, and a budget that pays for both.

Common mistakes

• Quoting a percentage without its definition. "2% get exploited" means nothing until you say exploited how, measured against what, over which period.
• Using CVSS as the queue. With about 40% of CVEs rated critical or high, a CVSS only queue buries the exploited slice in noise.
• Treating EPSS as a pass or fail threshold. FIRST says scores are probabilities, not thresholds, and that a 50% cut off would deprioritise almost everything because the base rate is about 2%.
• Closing findings as "not reachable" forever. Reachability changes with every release. Reassess on each build.
• Deferring without a trigger. "Low priority" with no review date becomes "never".
• Assuming your scanner sees everything. With NVD no longer enriching every CVE, product matching can lag. Use more than one vulnerability source.
• Forgetting the infrastructure you do not build. The most exploited categories are edge devices, gateways and remote access tools. A dependency programme does not cover them.

Fix it without waiting for upstream

The exploited slice is small, but when one of its CVEs lands in a library you ship, the clock starts on the day it is listed, not on the day a maintainer finds time to release. These are the ways to close that gap.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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.

FAQ

What percentage of CVEs are actually exploited?

It depends on the definition. About 0.5% of all CVEs ever published are in CISA's KEV catalog, which requires confirmed exploitation and a clear fix. FIRST says about 2 to 3% of published vulnerabilities show exploitation activity in any 30 day period. One exploit intelligence firm measured newly exploited CVEs at 1.4% of new CVEs in the first half of 2026.

How many vulnerabilities are in CISA KEV?

The KEV JSON feed listed 1,754 entries on 21 October 2026 (catalog version 2026.10.21). It held 1,484 at the end of 2025, after 245 additions that year.

Is the number of exploited vulnerabilities going up?

Yes in absolute terms. KEV additions rose from 185 in 2024 to 245 in 2025, and one firm counted 34% more actively exploited vulnerabilities in the first half of 2026 than a year earlier. As a share of all new CVEs, exploitation is flat to slightly down, because CVE volume is growing faster.

What is a good EPSS score threshold?

There is no universal one. FIRST says thresholds are a local decision and should be tuned over time. As a starting point, it notes that the CVSS critical population is roughly the 90th EPSS percentile, around a score of 0.04. KEV listed CVEs should be prioritised regardless of their EPSS score.

Should I patch every critical CVE?

You should have a plan for every critical CVE, but not every one needs an emergency patch. With nearly 40% of CVEs rated critical or high, use KEV status, EPSS, reachability and exposure to decide which need days and which can ride your next scheduled upgrade.

Are open source library vulnerabilities exploited as often as VPN and firewall flaws?

Far less often per CVE. Edge devices, gateways, remote access tools and content management systems dominate exploitation counts. Library CVEs need a reachable code path, so most are never exploited, but the few that are can affect thousands of products at once.

How long can I safely defer an unexploited vulnerability?

Until your next scheduled upgrade, as a rule of thumb for findings that are not reachable and not exposed, provided you write down triggers that end the deferral early. A KEV listing, a jump in EPSS, a public exploit or a change in exposure should all bring it back.

What is CISA BOD 26-04?

A Binding Operational Directive issued on 10 June 2026 that sets federal remediation timelines from four factors: asset exposure, KEV status, exploit automation and technical impact. It replaced BOD 19-02 and BOD 22-01. The most urgent cases need remediation within three days plus forensic triage.

See how Safeguard would help

The core of this post is turning thousands of findings into a short list you can fix, and then fixing it with a human approving each change. These demos show that workflow on real tools. To try it on your own repositories, download the apps at safeguard.sh/download and read the CLI documentation.

This first demo is a real Safeguard CLI session. You install the CLI, open the interactive terminal with safeguard, and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow is how you would work through the top tier of an exploitation aware queue, one approved fix at a time.

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

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then runs a scan from the terminal. That gives you the findings list you would intersect with KEV and EPSS in the walkthrough above, produced from code on your own computer.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask questions about your projects and findings in plain language, such as which open findings are in KEV, and keep control over what the assistant can reach.

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

Quick check

Sources

• CISA: Known Exploited Vulnerabilities Catalog and inclusion criteria
• CISA: KEV catalog JSON feed, version 2026.10.21
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: Stakeholder Specific Vulnerability Categorization (SSVC)
• FIRST: Exploit Prediction Scoring System (EPSS)
• FIRST: How EPSS works
• FIRST: Using EPSS
• EPSS Special Interest Group: Enhancing Vulnerability Prioritization, Data Driven Exploit Predictions with Community Driven Insights (arXiv)
• Jerry Gamblin: 2025 CVE Data Review
• SecurityWeek: NIST prioritizes NVD enrichment for CVEs in CISA KEV and critical software (April 2026)
• SecurityWeek: CISA KEV catalog expanded 20% in 2025, topping 1,480 entries
• IT Brief: Supply chain attacks rise as 215 flaws are exploited
• The Register: Zero day attacks on enterprise tech hit a record (March 2026)
• The Hacker News: Weekly recap, 98 zero days at a hacking competition (October 2026)

Last reviewed: 23 October 2026. Exploitation counts change weekly; check the KEV feed and EPSS for current figures.