On 28 September 2026, the Cybersecurity and Infrastructure Security Agency (CISA) will stop publishing its weekly Vulnerability Bulletin.
“CISA will discontinue the weekly Vulnerability Bulletin at the end of FY26 (September 28, 2026) as part of a broader shift from severity-based vulnerability management to risk-based vulnerability prioritization. Newly recorded vulnerabilities remain available on CVE.org, and users should rely on the Known Exploited Vulnerability (KEV) Catalog, CISA Cybersecurity Alerts and Advisories, and vendor security alerts for actionable, risk-based updates.”
This is not the end of CISA vulnerability data. It is a change in what the agency considers useful for deciding what to fix first. The practical question is whether that changes anything for teams managing vulnerability queues every day.
What is CISA ending?
CISA is ending the weekly bulletin that summarises newly recorded vulnerabilities. It is not ending the Known Exploited Vulnerabilities (KEV) catalog, cybersecurity advisories, Common Vulnerabilities and Exposures (CVE) records, or vendor security alerts.
CISA explicitly directs bulletin users to those continuing sources. Teams already consuming them through vulnerability-management tools or internal feeds will not lose the underlying data. Anyone using the bulletin as a weekly patch list will need to change that habit, but not because the vulnerabilities are disappearing.
Why is CISA ending the vulnerability bulletin?
CISA gives one official reason: vulnerability management is moving from severity-based management to risk-based prioritisation.
In Binding Operational Directive 26-04, issued in June for federal civilian agencies, CISA turns that principle into four inputs: asset exposure, KEV status, exploit automation, and technical impact.
Severity and risk are not the same thing. The Common Vulnerability Scoring System (CVSS) describes technical severity. It does not tell you whether a vulnerability is being exploited, whether the affected asset is exposed, or what that asset means to your organisation. A CVSS score remains useful, but it cannot order the queue by itself.
Volume makes that limitation harder to ignore. CVE.org’s publication metrics show that annual published CVE Records rose from 16,512 in 2018 to 48,244 across all four quarters of 2025. CVE.org recorded 35,872 in Q1 and Q2 of 2026, compared with 23,710 during the same two quarters of 2025. That is a 51% increase between like-for-like periods.
CISA does not itself name artificial intelligence as the reason for ending the bulletin. The volume story behind the shift is not speculation, though. In July 2026 the CVE Program, the global system for assigning and publishing CVE identifiers, held a community forum on AI-enabled vulnerability discovery. Its published meeting notes describe rapid growth in AI-enabled vulnerability discovery. Participants reported "10x or greater increases in report volume," and the notes name the volume explosion "the defining change," with nearly every major downstream problem tracing back to AI-driven discovery.
Keep the two curves separate. The long climb since 2018 is broader than any single cause. The CVE Program describes AI as a contributor to the recent acceleration, without quantifying how much of the 51% increase it caused. The same notes draw the operational conclusion: more vulnerabilities do not automatically mean more risk. Exploitability, exposure, and organisational context matter more as volume grows.
Prioritising by risk changes both the patch order and the evidence behind it.
Does this matter?
Yes. Not the bulletin itself, but CISA’s reason for sunsetting it.
Risk-based prioritisation is not new. Security teams have used exploit intelligence and environmental context for years. What changed is that CISA is retiring a long-running weekly format and explicitly naming severity-based management as the model it is moving away from.
That does not make CVSS obsolete. It confirms that severity is one dimension, not the decision. A critical vulnerability with no viable path to the affected component may wait. A lower-severity vulnerability that is internet-facing and under active exploitation may not.
Consider the queue that creates. A CVSS 9.8 finding on an isolated internal component may sit beside a CVSS 7.5 finding on an internet-facing service listed in KEV. Sorting by severity alone puts the 9.8 first. Risk-based prioritisation can move the actively exploited, reachable finding ahead while keeping both visible and accountable. The difference is not fewer findings. It is a more defensible order of remediation.
What changes for your team?
If your queue already combines several signals, little changes. Keep using CVSS, but weigh it alongside:
- Exploit probability from the Exploit Prediction Scoring System (EPSS).
- Confirmed exploitation from CISA KEV.
- Exposure, reachability, and the importance of the affected asset.
- Ownership, remediation status, and evidence that the fix held.
A vulnerability management platform that ranks on all four signals automatically saves you from doing this weighing by hand every time a new CVE lands.
If your process still starts and ends with “patch the highest CVSS score,” the bulletin’s retirement is a prompt to change it. Risk-based prioritisation does not mean replacing CVSS with EPSS or another universal number. It means using multiple dimensions to decide what matters in your environment, then recording and verifying that decision through the vulnerability management lifecycle.
Mature teams stopped treating CVSS as gospel years ago. The takeaway is not to replace it with another score. It is to build a defensible remediation order from severity, exploitation, exposure, and organisational context.
Read-only access · Working scan data deleted after each scan · EU-hosted
