AI Finds Vulnerabilities Faster Than We Patch: How Teams Keep Up

A security team keeps up with AI-driven vulnerability discovery by changing what it tries to keep up with. You will not fix every new CVE, and you should not try. Rank by known exploitation, reachability and exposure before severity, automate the fix rather than the ticket, measure findings closed against findings opened, and have a plan for components whose maintainers will never ship the fix you need.

This guide is for the people who consume patches: heads of AppSec, vulnerability management leads, engineering VPs and CISOs. It covers how much volume has really grown, why most new findings will never touch your code and how to prove it, what throughput means, how patch SLAs should change now that exploitation often starts before a patch ships, and what to tell a board about a backlog that grows while the team works harder. For the disclosure side, see our posts on Patch the Planet and AI agent coordination and on whether maintainers can keep up at Mythos scale.

Key takeaways

• Volume really is up. One public analysis counts 35,364 CVEs published in the first half of 2026, about 49.5% more than a year earlier. NIST says NVD submissions rose 263% from 2020 to 2025.
• Very little of it is exploited. Only 85 of those CVEs, about 0.24%, were in CISA's Known Exploited Vulnerabilities catalog by midyear.
• Nobody can say exactly how much growth is AI-found. The signals are strong, but no CVE field records how a bug was discovered.
• Triage order: known exploited, then reachable, then exposed, then severity. CISA's June 2026 federal directive sorts work on almost exactly those factors.
• Throughput is the metric. If findings opened per week exceed findings closed, the backlog grows no matter how hard people work.
• Automate the change, not the ticket. Most dependency fixes are a version bump plus a test run, which a machine can draft and a human can approve.
• End of life lines need a plan. Override, backport, maintained patched build or isolation. Waiting is not on the list.
• Report exposure to the board, not counts. Show the time from "fix available" to "fix running" for exploited and reachable issues.

How much has CVE and advisory volume grown in 2026, and how much is AI-found?

The volume numbers

Jerry Gamblin's midyear analysis of CVE data, excluding rejected records, counts 35,364 CVEs published from 1 January to 30 June 2026. That is about 195 a day and about 49.5% more than the 23,656 in the same window of 2025. His projections put the full year at roughly 71,000 to 72,000. June was the busiest month, with 7,454.

The severity mix matters as much as the total. Gamblin reports 10.0% of those CVEs rated critical and 39.1% rated high, with a median CVSS score of 7.1. That is about 17,000 high or critical CVEs in six months. Any policy that says "fix every high and critical within 30 days" was written for a different decade.

The public infrastructure that enriches these records is straining too. In April 2026, NIST said NVD submissions rose 263% between 2020 and 2025 and moved NVD to a risk based model. It now aims to enrich CVEs in CISA's KEV catalog within one business day and prioritizes federal and critical software. Other CVEs are labelled "Lowest Priority" and are not scheduled for immediate enrichment, backlogged CVEs published before 1 March 2026 were moved to "Not Scheduled", and NVD no longer adds its own severity score when the CVE Numbering Authority already supplied one. If your tooling assumed every CVE would arrive with NVD's product matching and score, many will not.

How much of the growth is AI-found?

Nobody can give you a reliable percentage. A CVE record says what is affected and who assigned the identifier, not whether a human, a fuzzer or a language model found the bug. Other forces push volume up at the same time: more CVE Numbering Authorities, more projects using GitHub's advisory flow, and researcher attention on fashionable targets. Gamblin's data shows GitHub Security Advisories as the largest assigner, with 6,801 CVEs, and one AI agent project, OpenClaw, collecting 537. He attributes that cluster to researcher attention rather than code quality.

The public signals of AI-assisted discovery are still large:

• Firefox. Mozilla's Firefox 148 advisory in February credited 22 CVEs to Anthropic's team, according to Davi Ottenheimer's line by line comparison of the advisories. Mozilla's 21 April blog post, as quoted there, said Firefox 150 fixed 271 vulnerabilities found with an early version of an Anthropic model. The Firefox 150 advisory, MFSA 2026-30, lists 43 CVE entries; three individual entries credit reporters "using Claude from Anthropic", and three memory safety roll ups each bundle dozens to over a hundred bug reports. How 271 maps to those entries is disputed.
• curl. According to reporting on Daniel Stenberg's announcement, curl will handle low and medium severity reports as public GitHub issues from 26 October 2026. Stenberg says more than 90% of submissions could quickly be judged below high, that the share of confirmed vulnerabilities fell from above 15% to below 5% during 2025, and that the change is "entirely triggered" by report volume.
• Patch the Planet. OpenAI launched the program with Trail of Bits in June 2026, according to InfoWorld, covering projects including Python, Go, cURL and Sigstore. OpenAI says the work has found "hundreds of security issues" and merged dozens of patches.
• PHP. In October, critical PHP flaws found by researchers working with AI tools led some government sites to go offline while operators waited for the fix, as TechCrunch reported citing Reuters. See what AI-found bugs mean for defenders.

The defensible summary: published CVEs are rising fast, AI-assisted research is clearly one driver, and the share of real, serious findings varies hugely by source. curl's numbers show both sides. AI tools generate a lot of noise, and they also find real bugs in mature code.

Why will most new findings never matter to my code, and how do I prove it?

The most important number in this post: of the 35,364 CVEs published in the first half of 2026, Gamblin counts 85 in CISA's KEV catalog by midyear, about 0.24%. He calls that a floor that will rise, and CISA also adds older CVEs; it added 146 KEV entries in the half, 17 tied to ransomware campaigns. Still, the overwhelming majority of new CVEs will never be seen exploited.

Separately, a CVE in a package you install is not a vulnerability in your application. There are four common reasons a finding does not apply:

1. The component is not really present. It is a dev or test dependency that never ships.
2. The vulnerable code is not present. Your version or build does not include the affected module.
3. The vulnerable code is present but never called. Nothing in your code path reaches the vulnerable function.
4. An attacker cannot control the input. The function runs, but only on data your service never accepts from outside.

Saying "this does not affect us" in a meeting is not proof. You need evidence for an auditor and a machine readable statement your customers' scanners can consume.

Reachability is the evidence

Reachability analysis builds a call graph from your code through your dependencies and asks whether any path reaches the vulnerable function. The Go project's documentation describes the idea plainly: govulncheck reports only vulnerabilities that affect you, "based on which functions in your code are transitively calling vulnerable functions". Run it on a Go module and compare its output with every advisory that matches your go.sum. The difference is usually large.

The principle carries to other ecosystems, with more difficulty in dynamic languages. Static reachability can miss calls made through reflection, dynamic imports or plugins, so treat "not reachable" as strong evidence, not a guarantee, and add a runtime or configuration check for anything critical.

VEX is the proof you can hand to others

Vulnerability Exploitability eXchange (VEX) is the standard way to record that a finding does not apply; CISA published minimum requirements for VEX in April 2023. The OpenVEX specification defines four statuses, not_affected, affected, fixed and under_investigation, and a not_affected statement needs a justification or an impact statement:

A minimal OpenVEX document:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026-10-22-001",
  "author": "AppSec team, Example Corp",
  "timestamp": "2026-10-22T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2026-00000" },
      "products": [ { "@id": "pkg:oci/payments-api@sha256:abc123" } ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "The affected parser function is never called; verified by call graph analysis on build 4812."
    }
  ]
}

Tie each statement to a build or image digest, not a product name, and re-check it when the code changes. One new call can turn not_affected into affected overnight.

What should the triage order be now?

The old order was CVSS score, highest first. The new order is known exploited, then reachable, then exposed, then severity. Each step removes most of what is left.

1. Known exploited. Is the CVE in CISA's KEV catalog, or do credible reports show exploitation? KEV requires a CVE ID, reliable evidence of exploitation in the wild (attempts count; scanning, research and proof of concept code do not) and a clear remediation action. CISA recommends every organization, not only federal agencies, build KEV into its vulnerability management plan.
2. Likely to be exploited. FIRST's Exploit Prediction Scoring System gives each CVE a daily probability, from 0 to 1, of exploitation in the next 30 days, plus a percentile. It is a forecast, so use it to order the queue, not to close findings.
3. Reachable. Does your code call the vulnerable function? This filter cuts the most dependency volume.
4. Exposed. Is the service internet facing, handling untrusted input, or running with privileges that matter?
5. Severity. Only now does CVSS help, as a tie breaker on impact.

CISA now ranks federal work the same way

On 10 June 2026 CISA issued Binding Operational Directive 26-04, which revokes BOD 22-01 and BOD 19-02. Its remediation timelines depend on four factors: whether the asset is publicly exposed, whether the CVE is in KEV, whether an adversary can automate every step of exploitation, and whether exploitation gives partial or total control. In the most urgent cases agencies must remediate or mitigate within three days and forensically triage the asset for prior compromise. At the other end, some fixes can wait for the next scheduled upgrade or rebuild. Secondary coverage reports intermediate tiers of two weeks and two months; we could not read those from CISA's page, where the timeline table is an image.

CISA's broader decision model is Stakeholder Specific Vulnerability Categorization (SSVC), which weighs exploitation, technical impact, automatability, mission prevalence and public well-being to reach Track, Track*, Attend or Act. Since June 2026, NVD carries SSVC data from CISA in its feeds and API.

A decision table you can adopt

The targets are ours, not CISA's. Tune them, but keep the shape: two small urgent tiers and a large tier that rides along with routine upgrades.

What does remediation throughput mean, and how do I measure it?

Throughput is the rate at which findings leave the queue because they were fixed, mitigated or proven not to apply. The arithmetic is unforgiving. If 400 qualifying findings arrive in a week and 300 close, the backlog grows by 100 a week regardless of effort. Queueing theory says the same thing: the average number of open items equals the arrival rate times the average time each stays open. Double arrivals at a flat closure time and the backlog doubles.

So "AI is finding vulnerabilities faster than we can patch" is a throughput problem, not a motivation problem. There are three levers: fewer arrivals into the work queue (triage), less time per fix (automation), and more capacity (people). Only the first two scale.

Measure by tier, never in aggregate. A team can post a beautiful overall closure rate by clearing hundreds of low risk findings while one exploited finding ages. And count closures by evidence: a "won't fix" without a VEX justification is debt with a different label.

To start this week, export findings with creation date, closure date, tier and closure reason. Group arrivals and closures by week and tier, plot net flow for the last 12 weeks, and for each closed finding with a fixed version compute the days from that version's release to your deployment. If the top two tiers show positive net flow and short exposure windows, you are keeping up where it matters, even with a large total backlog.

Can we automate the fix itself, not just the ticket?

Yes, for most dependency findings. A typical fix means finding the manifest that pulls the vulnerable version, choosing the lowest compatible safe version, changing it or adding an override, regenerating the lockfile, running tests and opening a pull request. Every step is mechanical. The judgment is in the review and merge, which is where a human should stay.

Ticket automation, by contrast, moves work around without doing it. A scanner that files 300 tickets a week adds arrivals to someone else's queue, and net flow does not change.

A sensible automation ladder:

1. Generated pull requests for direct dependency bumps within the same major version. Lowest risk, highest volume.
2. Generated pull requests for transitive fixes, using overrides or resolutions when the parent has no fixed release yet.
3. Grouped pull requests per repository, so a team reviews one change a week instead of fifteen.
4. Auto merge for a narrow class you define: patch level bumps, tests green, no new licenses, internal services first.
5. Major version upgrades stay human driven, with a generated pull request as the starting point.

Gate everything with tests and policy. One generated change that breaks production costs more trust than a month of manual fixes. If AI coding agents do this work, keep their scope narrow and a human approving each state changing command; our guides on whether Claude Code is safe to use at work and on whether AI coding agents add vulnerable dependencies cover those limits.

Step by step: a triage and fix pass you can run today

This pass takes one repository from "the scanner says 140 findings" to a short, ordered list with fixes in flight.

1. Produce an inventory of what you ship

Scan built artifacts as well as source, because base layers and build steps add packages no manifest mentions.

# Every installed version of a package in a Node project
npm ls lodash --all

# Production dependencies only, with a severity floor
npm audit --omit=dev --audit-level=high

# Python: audit a requirements file (PyPA's pip-audit)
pip-audit -r requirements.txt

# Maven: where does a vulnerable artifact come from?
mvn dependency:tree -Dincludes=org.apache.commons:commons-text

# The runtime inside the image you deploy
docker run --rm --entrypoint node my-app:latest --version

With Safeguard, safeguard scan --dir ., safeguard scan --image my-app:latest and safeguard scan --sbom sbom.json produce the inventory and write JSON results under ./output.

2. Mark what is known exploited

CISA publishes KEV as a JSON feed. Pull it daily and join it with your findings.

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json -o kev.json

jq '.vulnerabilities[] | select(.cveID=="CVE-2021-44228") | {cveID, dateAdded, dueDate, knownRansomwareCampaignUse}' kev.json

3. Add the exploitation forecast

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" | jq '.data[] | {cve, epss, percentile}'

Sort by percentile rather than raw score, because raw EPSS values cluster near zero.

4. Check reachability, then tier and write VEX

For Go, the official tool does the call graph work:

go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

Elsewhere, use a reachability capable scanner or, at minimum, search for imports of the affected module and calls to the function named in the advisory. Record the result with the commit hash, apply the tier table, and write OpenVEX statements for everything you have shown is not affected.

5. Fix transitive cases without waiting for the parent package

In npm, the overrides field in the root package.json replaces a package version anywhere in the tree; npm's documentation notes that only the root file's overrides count.

{
  "overrides": {
    "vulnerable-lib": "^2.4.3",
    "parent-lib": {
      "other-lib": "1.9.2"
    }
  }
}

npm install
npm ls vulnerable-lib --all
npm test

In Python, put the safe version in constraints.txt and install with pip install -r requirements.txt -c constraints.txt. In Maven, declare it in dependencyManagement. In Go, go get example.com/vulnerable-lib@v1.4.2 then go mod tidy raises the minimum for the whole module graph.

6. Stop the vulnerable version from coming back

name: dependency-gate
on:
  pull_request:
  schedule:
    - cron: "0 6 * * *"
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 24
      - run: npm ci
      - run: npm audit --omit=dev --audit-level=high
      - uses: actions/setup-go@v5
        with:
          go-version: stable
      - run: go install golang.org/x/vuln/cmd/govulncheck@latest
      - run: govulncheck ./...

The scheduled run matters as much as the pull request trigger. A dependency that was clean on Monday can have a new advisory on Wednesday without any change in your code.

What do we do when the fix lands only in a version we cannot upgrade to, or in an end of life line?

Upstream projects fix supported lines. On a line that is out of support, the fix may never come. The Node.js project's end of life page says such lines get no further updates, including security patches, and that bugs fixed in newer lines may still affect them; it lists 20.x as end of life. PHP's supported versions page, read on 22 October 2026, shows 8.2 and 8.3 in security only support, with 8.2's ending on 31 December 2026; older branches get nothing. In the Hacker News discussion of Patch the Planet, one commenter noted that an AI can draft a backport, but releasing packages for discontinued release streams is "a human problem".

Whatever you choose:

• Make the patch reproducible. Commit patch files, publish patched builds to a private registry, or pin a fork by commit hash.
• Keep scanners honest. A backport keeps the old version number, so scanners will still flag it. Use a version suffix your tools understand and publish a VEX fixed statement for the patched build.
• Track every local patch with a reason and an owner, review the list monthly, and remove each patch when upstream catches up.

How should patch SLAs change when disclosure to exploit times shrink?

Shorter at the top, longer at the bottom.

Mandiant's M-Trends 2026 report, as summarized by Help Net Security, estimates the mean time to exploit in 2025 at minus seven days: on average, exploitation began about a week before a patch existed. The same series measured minus one day in 2024 and 63 days in 2018, and exploits were the top initial infection vector at 32% of investigations with a known vector. Those figures describe the vulnerabilities attackers chose, which skew toward edge devices and widely deployed software. For that small set, a 30 day SLA is a policy of being late. Meanwhile the bottom of the queue is enormous and mostly harmless, and holding it to the same clock spends capacity in the wrong place.

Restructure SLAs around tiers:

• Emergency: hours to mitigate, days to fix, plus a check for prior compromise, mirroring BOD 26-04's three day tier.
• Urgent: one to two weeks.
• Standard: one to two months, closed mostly by automated pull requests.
• Track: next planned upgrade or rebuild, with VEX in the meantime.

Three habits make the short tiers achievable. Pre-approve the emergency change: decide who can approve an out of band upgrade and who can take a service offline. Mitigate first when fixing takes longer, with a WAF rule, a feature flag or a network restriction, labelled as a mitigation with the clock still running. Rehearse: on a quiet day, pretend a common library in your stack has an exploited flaw and time how long it takes to find every instance and ship the fix. That time, not the SLA on paper, is your real capability.

What should we tell the board about a backlog that grows while the team works harder?

Tell them the truth in a form they can act on. The count of open CVEs is driven by the industry's publication rate and will keep rising. A one page view that works:

• Exposure, not volume. "4 Emergency and 19 Urgent findings this quarter. All Emergency items mitigated within 24 hours and fixed within 3 days; 17 of 19 Urgent items met target."
• Exposure window trend for the top two tiers, quarter over quarter.
• Net flow in the top tiers. Zero or positive means you are keeping up where it matters.
• What you chose not to fix, and why. The Track tier with VEX evidence, framed as a documented decision.
• Structural risks. End of life runtimes still in production, each with a plan and a date.
• Capacity. The share of fixes produced by automation, which turns a headcount argument into an investment argument.

Add one sentence of context: published CVEs grew by roughly half in early 2026, NVD moved to risk based enrichment, and CISA now prioritizes federal patching by exploitation, exposure, automatability and impact. "We triage the way CISA now asks federal agencies to" is a reference point a board can trust.

Common mistakes

• Treating CVE count as the risk metric. Report exposure windows and top tier net flow instead.
• Sorting by CVSS alone. Severity says nothing about exploitation or reachability.
• Closing findings as "not applicable" without evidence. Without reachability results or a VEX justification, the next audit or incident reopens them.
• Writing VEX once. A not_affected statement is true for one build. Re-check it on change.
• Automating tickets instead of changes. More tickets add arrivals without adding capacity.
• Waiting for NVD enrichment. Use the CNA record, the vendor advisory and KEV directly.
• Assuming end of life lines will get the fix. They will not. Plan the upgrade, override, backport or maintained build now.
• Patching the source and forgetting the image. Nothing changes until the image is rebuilt and redeployed.

Fix it without waiting for upstream

When discovery outpaces patching, the slowest step is often the one you do not control: a maintainer's release. Here is how to close that gap on your side.

In incidents like this one, 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.

See how Safeguard would help

These are real product sessions, each covering one part of the throughput loop above: know where you are exposed, make the change, keep a person approving it. Safeguard will not stop an exploit in progress or patch systems you do not build; it shortens the path from advisory to fixed version.

This demo is a real CLI session. You ask the assistant 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, and pushes nothing. That is a Standard tier fix from the walkthrough above, done in minutes with a human approving every step.

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

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. It is the inventory step: when the next advisory lands, which repositories and images carry the affected version is answered from scans you already run, on hardware you control.

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

This demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. A vulnerability management lead can then ask which projects carry a component or which findings matter most, while deciding exactly which tools the assistant may call.

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

You can download Safeguard at safeguard.sh/download and read the CLI documentation at docs.safeguard.sh/docs/cli.

FAQ

Is AI really finding more vulnerabilities, or is it just more noise?

Both. curl says confirmed vulnerabilities fell below 5% of submissions during 2025 as low quality reports rose. Meanwhile Mozilla has shipped fixes for bugs found with AI models, and OpenAI says Patch the Planet has found hundreds of issues. Your triage has to handle both.

How many CVEs will be published in 2026?

Gamblin projects roughly 71,000 to 72,000 from the first half's 35,364. Treat any projection as an estimate until the year closes.

What percentage of CVEs are actually exploited?

A small fraction. About 0.24% of CVEs published in the first half of 2026 were in CISA's KEV catalog by midyear, according to Gamblin. The share rises over time but stays a small minority.

Should we prioritize vulnerabilities by CVSS, EPSS or KEV?

All three, in order: KEV for known exploitation, EPSS for likely exploitation, then reachability and exposure, and CVSS last for impact. They answer different questions.

How do I prove to a customer that a CVE does not affect our product?

Publish a VEX statement with status not_affected and a justification such as vulnerable_code_not_in_execute_path, tied to a specific build or image digest, and keep the reachability evidence on file.

What is a good SLA for patching critical vulnerabilities in 2026?

Tie it to exploitation and exposure, not severity alone. For exploited, exposed and reachable issues, mitigate within a day and fix within days; CISA's BOD 26-04 sets three days plus forensic triage for its most urgent federal tier.

Can AI fix vulnerabilities automatically?

For most dependency findings it can draft the change: bump the version, regenerate the lockfile, run tests and open a pull request. A person should still approve the merge, and major upgrades need an engineer to own the migration.

What do I do if a vulnerable library has no fixed version?

Check whether a newer line has the fix. If you cannot move, consider an override, a backport you maintain, a maintained patched build, a replacement, or isolating the affected path. Document the decision and review it monthly.

How do I know whether my vulnerability program is keeping up?

Compare findings closed with findings opened each week, per tier. If closures match arrivals in the top tiers and the time from fix available to fix deployed is shrinking, you are keeping up where it counts.

Quick check

Sources

• Jerry Gamblin: 2026 CVE data review, first half
• NIST: National Vulnerability Database news and processing updates
• CISA: Known Exploited Vulnerabilities catalog
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: Stakeholder Specific Vulnerability Categorization
• CISA: Minimum Requirements for Vulnerability Exploitability eXchange
• FIRST: Exploit Prediction Scoring System
• OpenVEX specification
• Go: Vulnerability management and govulncheck
• npm Docs: package.json overrides
• Node.js: End of life
• PHP: Supported versions
• Mozilla: Security advisory MFSA 2026-30, Firefox 150
• Flying Penguin: How 22 vulns became 271, or maybe 3
• PBX Science: curl moves low and medium severity reports into the open
• InfoWorld: OpenAI rolls out AI-led push to fix open-source software flaws
• Hacker News: Patch the Planet discussion
• Help Net Security: Mandiant M-Trends 2026
• TechCrunch: The internet is having a very bad cybersecurity day

Last reviewed: 22 October 2026. Vulnerability statistics and federal guidance change often; check the linked sources for current figures.