When does CISA's weekly vulnerability bulletin end?

CISA announced on 16 September 2026 that the weekly vulnerability bulletin would be discontinued on 28 September 2026. Subscribers were directed to the Known Exploited Vulnerabilities catalog, to CISA's cybersecurity alerts and advisories, and to CVE.org for vulnerability records.

What replaces the CISA weekly vulnerability bulletin?

CISA's notice points to three sources: the Known Exploited Vulnerabilities catalog for vulnerabilities with observed exploitation, its cybersecurity alerts and advisories for actionable guidance, and CVE.org for the vulnerability records themselves. Existing subscribers were asked to update their subscription preferences accordingly.

Why prioritise by exploitation rather than severity?

Because a severity score describes how bad a vulnerability could be under general assumptions, while exploitation evidence indicates whether it is being used now. They often disagree: many high-scoring issues are never widely exploited, and some moderate ones are attacked immediately because they are easy and widespread.

Should every vulnerability finding become a ticket?

No. A queue that receives every scanner finding teaches people to ignore the queue, and that habit extends to findings that matter. File automatically where there is evidence of exploitation or real exposure, and keep the remainder in a reviewable list with recorded decisions.

What is the best metric for vulnerability management?

Time to remediate vulnerabilities with evidence of active exploitation affecting exposed systems. Counts of open findings are dominated by items that will never be exploited, so they move mostly with scanner coverage rather than with risk, which makes them misleading as a progress measure.

Where to Get Vulnerability Data Now

CISA announced on 16 September 2026 that its weekly vulnerability bulletin ends on 28 September 2026, directing subscribers to the Known Exploited Vulnerabilities catalog, its advisories, and CVE.org. The shift reflects prioritising vulnerabilities by evidence of exploitation and exposure rather than by severity score alone.

What changed

CISA published a notice on 16 September 2026 stating that its weekly vulnerability bulletin would be discontinued on 28 September 2026. The notice pointed existing subscribers to the Known Exploited Vulnerabilities catalog and to CISA's cybersecurity alerts and advisories, and referenced CVE.org for vulnerability records themselves.

The stated rationale is a move from severity-based to risk-based vulnerability management, aligned with a binding operational directive on prioritising security updates based on risk, which directs federal agencies to prioritise according to real-world risk such as evidence of exploitation and actual exposure rather than severity scores alone.

One point of confusion worth noting: at least one outlet described the retirement as affecting a monthly bulletin. CISA's own notice refers to the weekly bulletin, and the primary source is the one to rely on.

The underlying argument is sound regardless of the administrative detail. A weekly digest of everything published, ordered by score, has a structural problem: the volume is far beyond what any team can act on, and the ordering is not correlated with what will actually be attacked. Reading it produces a feeling of coverage and very little prioritisation.

Why exploitation evidence outranks severity

A severity score is computed from the properties of a vulnerability under general assumptions about deployment. It answers how bad this could be for a typical installation. Evidence that a vulnerability is being exploited answers a different and more decision-relevant question: is someone actually using this now. The two frequently disagree. Plenty of high-scoring vulnerabilities are never exploited at scale because exploitation is impractical or the affected configuration is rare, while some moderate-scoring ones are attacked immediately because they are easy and the software is everywhere.

Building an intake that works

Start from your inventory, not from the feed. The question is not what was published this week, it is what was published that affects software you run and expose. That inversion reduces the volume dramatically, and it requires an inventory accurate enough to match against. Where you build software, a bill of materials generated at build time is the most reliable source for that match.

Subscribe to exploitation signals first. A catalog of vulnerabilities with observed exploitation is a short, high-signal list, and treating an addition to it that affects your estate as an interrupt is a defensible policy. Its brevity is the feature.

Use vendor and distribution advisories as the authority for their products. They state which builds are affected and which fix it, often earlier and more precisely than central records, and distribution advisories are the correct input for backported packages, where upstream version numbers do not reflect patch state.

Treat central records as the reference, not the queue. They are what you consult to understand a specific vulnerability. Streaming all of them into a ticket queue is how teams end up with thousands of open items nobody reads.

Add exposure as a filter you own. Internet-reachable, authenticated only, not deployed, behind a mitigating control. No external source knows this, and it changes priority more than any score does.

Keep a path for the unscored and the unnumbered. Some issues matter before a record is enriched or an identifier is assigned, particularly where a vendor discloses directly. An intake that only accepts scored, identified vulnerabilities will miss the fastest-moving ones.

Record decisions, including dismissals. Why something was judged not applicable, with the date and reasoning. Without that, the same false match is investigated repeatedly on every scan.

What this means for the ticket queue

Do not auto-file everything. A queue that receives every scanner finding trains people to ignore the queue, and the credibility loss extends to the findings that matter. Auto-file what is exploited or exposed; hold the rest in a reviewable list.

Give vulnerability tickets a different shape. They need the affected asset, the fix version, the exposure assessment, and the deadline. A generic incident template collects none of that, so the information gets rediscovered by whoever picks the ticket up.

Set deadlines by category, agreed in advance. Exploited and exposed in days, exposed but not known exploited in weeks, everything else on a patch cycle. Negotiating urgency per vulnerability consumes more effort than the patching does.

Measure time to remediate for the exploited category only. Aggregate counts of open vulnerabilities are a bad metric because they are dominated by items that will never be exploited. Time to remediate the ones with evidence of active exploitation is a number worth reporting.

Expect the volume to feel wrong at first. Moving from a comprehensive digest to a narrow high-signal list feels like reduced coverage. The coverage was never real: a list nobody can act on is not protection, it is documentation of the problem's size.

Frequently asked questions

When does CISA's weekly vulnerability bulletin end?: CISA announced on 16 September 2026 that the weekly vulnerability bulletin would be discontinued on 28 September 2026. Subscribers were directed to the Known Exploited Vulnerabilities catalog, to CISA's cybersecurity alerts and advisories, and to CVE.org for vulnerability records.
What replaces the CISA weekly vulnerability bulletin?: CISA's notice points to three sources: the Known Exploited Vulnerabilities catalog for vulnerabilities with observed exploitation, its cybersecurity alerts and advisories for actionable guidance, and CVE.org for the vulnerability records themselves. Existing subscribers were asked to update their subscription preferences accordingly.
Why prioritise by exploitation rather than severity?: Because a severity score describes how bad a vulnerability could be under general assumptions, while exploitation evidence indicates whether it is being used now. They often disagree: many high-scoring issues are never widely exploited, and some moderate ones are attacked immediately because they are easy and widespread.
Should every vulnerability finding become a ticket?: No. A queue that receives every scanner finding teaches people to ignore the queue, and that habit extends to findings that matter. File automatically where there is evidence of exploitation or real exposure, and keep the remainder in a reviewable list with recorded decisions.
What is the best metric for vulnerability management?: Time to remediate vulnerabilities with evidence of active exploitation affecting exposed systems. Counts of open findings are dominated by items that will never be exploited, so they move mostly with scanner coverage rather than with risk, which makes them misleading as a progress measure.