CISA Vulnerability Bulletins ended on September 28, 2026, after CISA announced the change on September 16, 2026. The agency described the retirement as part of a shift away from broad severity-based sorting and toward risk-based vulnerability management that gives more weight to exploitation and exposure signals, according to the CISA notice.
What CISA Vulnerability Bulletins Provided
The Old Weekly Digest Model
The discontinued weekly bulletin was a digest. It gathered newly published CVEs from the prior week and grouped them by CVSS severity categories, including High, Medium, Low, and unassigned entries. For many teams, that made the bulletin a predictable weekly reference point. It did not replace vendor advisories, asset inventories, or emergency alerts, but it gave defenders a single page to scan for newly listed vulnerabilities.
The format had a long operating life. The weekly bulletins had been issued since 2004, so the September 28, 2026 retirement ended more than 22 years of publication, as reported by Cybersecurity Dive. That history matters because long-running security routines often become part of ticket templates, weekly review meetings, managed service reports, and classroom examples for explaining CVE triage.
Why CISA Vulnerability Bulletins Became Noisy
The scale of listed vulnerabilities had grown large enough to weaken the value of a simple weekly scan. Research notes for the final full week of September 7-13, 2026 reported 3,783 CVEs in the bulletin, including 1,700 in the High category. The same research notes reported that weekly entries averaged about 2,830 between July and September 2026, compared with about 852 in analogous weeks in mid-2025.
Those figures do not prove that every listed vulnerability created an equal operational risk. CVSS is a severity scoring system, not a live exploitation feed. A high-severity issue in software that an organization does not run should not outrank an actively exploited issue on an internet-facing system that the organization does run. That distinction is central to the change.
Technical Consequences For Patch Triage
Less Single-Page Visibility
The most direct consequence is loss of a stable weekly digest. Teams that built dashboards or review habits around one CVSS-sorted bulletin must now assemble the same visibility from multiple sources. That can increase maintenance work, especially for small teams that do not have dedicated vulnerability engineers. It may also affect instructors who used the weekly bulletin as a simple teaching artifact for comparing CVE volume, severity labels, and remediation planning.
Teams that treated CISA Vulnerability Bulletins as a patch priority list were already facing a technical mismatch. The bulletin format listed new CVEs, but it did not flag whether a vulnerability was being exploited. That means a weekly list could be useful for awareness while still being weak for urgent prioritization. For related classroom discussion about how CISA patch orders can affect affected web services, see our analysis of PHP2Shell vulnerabilities. Readers interested in broader perspectives on technology and network developments can explore more at Abacus News.
More Weight On Exploitation Signals
CISA’s stated replacement emphasis includes the Known Exploited Vulnerabilities catalog, Cybersecurity Alerts and Advisories, the CVE catalog, and Stakeholder-Specific Vulnerability Categorization. These sources answer different questions. The KEV catalog focuses on vulnerabilities known to be exploited. Alerts and advisories can provide time-sensitive defensive context. The CVE catalog remains a record of identifiers and descriptions. SSVC is intended to support decision-making beyond a severity score.
The change does not remove the need to track CVEs. It changes which signals should trigger the fastest response. In one example from the research notes, 14 vulnerabilities added to the KEV catalog for the week of September 7-13, 2026 had already passed federal remediation deadlines before the weekly bulletin was even published. That example shows why a weekly recap can lag behind urgent patch timelines.
| Old Input | Main Use | Limitation |
|---|---|---|
| Weekly CVSS-sorted bulletin | Broad awareness of new CVEs | Did not show exploitation status |
| KEV catalog | Known exploited vulnerability tracking | Only covers known exploited entries |
| Alerts and advisories | Time-sensitive defensive context | Requires separate monitoring |
| SSVC-style prioritization | Risk-based decision support | Depends on accurate local asset context |
Practical Effects For Security Teams And Learners
For Security Teams
Security teams are affected in several practical ways. First, a weekly routine that was easy to delegate now requires more source checking. Second, patch queues need clearer rules for weighting exploitation, exposure, business importance, and vendor availability. Third, reporting may need to explain why a lower-CVSS issue can outrank a higher-CVSS issue if exploitation evidence and asset exposure justify that order.
The change may also expose gaps in asset management. Risk-based prioritization depends on knowing whether affected software is present, whether it is exposed to untrusted networks, whether compensating controls exist, and whether a vendor fix is available. If those facts are missing, a team may still fall back to severity sorting because it is easier to apply. That fallback is understandable, but it can misdirect limited patching time.
For Educators And Entry-Level Analysts
For Tech Basics instruction, the change is useful because it separates three ideas that beginners often combine: vulnerability existence, severity score, and real-world risk. A CVE means a vulnerability has been assigned an identifier. A CVSS score estimates technical severity under a scoring model. A risk-based patch decision also asks whether the system is present, exposed, exploited, and operationally important.
A safe beginner workflow can be taught without offensive detail:
- Identify whether the affected product exists in the local inventory.
- Check whether CISA lists the issue as known exploited.
- Review vendor guidance for fixed versions or mitigations.
- Prioritize exposed and business-critical systems before isolated test systems.
- Record why each patch decision was made, including any accepted delay.
This workflow is more demanding than reading one weekly page, but it teaches a more accurate model of defensive work. It also makes limits visible: without a current inventory, even the best external feed cannot identify which local machines are affected.
Limits Of A Risk-Based Patch Queue
What The Change Does Not Prove
The retirement of the weekly bulletin does not prove that fewer vulnerabilities exist. It also does not mean CVSS scores are useless. Severity still helps describe technical impact, and many organizations will keep using it as one input. The change mainly reduces reliance on a weekly severity-sorted publication as the first stop for prioritization.
It also does not guarantee better outcomes by itself. A risk-based process can fail if the organization lacks inventory data, ignores vendor advisories, or cannot deploy patches within operational windows. Configuration details matter. A vulnerability in unused software is different from the same vulnerability in a public service that handles sensitive work. The external identifier may be the same, while the local risk is not.
What Needs Local Verification
Local verification becomes more important after the bulletin’s retirement. Teams need to confirm product names, affected versions, internet exposure, authentication requirements, and business ownership before ranking remediation. They also need to track whether temporary mitigations are present and whether those mitigations are documented well enough to audit later.
Cost is part of the maintenance picture, even when no purchase is involved. Time spent reconciling feeds, checking inventories, testing patches, and writing exception records is real labor. The end of the weekly digest may reduce dependence on a broad list, but it can increase the value of repeatable internal process. That process should be simple enough for staff to apply under time pressure and clear enough for managers to review.
CISA Vulnerability Bulletins After September 2026
The retirement of CISA Vulnerability Bulletins closed a long-running publication, but it did not end public vulnerability data. The practical shift is from a weekly CVSS-oriented digest toward multiple signals that need to be read together: known exploitation, alerts, advisories, CVE records, asset exposure, and stakeholder impact.
For defenders, the safest reading is cautious rather than dramatic. The old bulletin was useful for visibility but incomplete for urgent patch decisions. The newer model asks teams to prove which vulnerabilities matter in their environment. That is technically sound, but it raises the bar for inventory accuracy, process discipline, and documentation. For learners, the lesson is clear: a vulnerability list is not the same thing as a risk decision.
