The federal government is quietly flagging vulnerabilities as ransomware-related without telling anyone. In 2025, 59 CVEs silently changed status. Here’s what security teams need to know.

The Silent Intelligence Gap

Picture this: Your security team meticulously reviews CISA’s Known Exploited Vulnerabilities (KEV) catalog. You prioritize patches based on what’s actively exploited. You check if vulnerabilities are used in ransomware campaigns to determine urgency. You think you have a handle on threat intelligence.

You don’t.

CISA is making critical updates to the KEV catalog—updates that fundamentally change how you should prioritize vulnerabilities—and they’re doing it without any announcement, alert, or notification. These “silent flips” are quietly changing the ransomware association status of existing vulnerabilities, and unless you’re actively monitoring for changes, you’ll never know.

In 2025 alone, 59 vulnerabilities silently changed from “Unknown” to “Known” for ransomware use. No press release. No email alert. No RSS notification. Just a field change in a JSON file that most organizations never notice.

If a tree falls in the forest and nobody hears it, does it make a sound?

If CISA updates a vulnerability’s ransomware status and nobody’s watching, does it change your risk posture?

Yes. It absolutely does.

How We Got Here: A Brief History of the KEV Ransomware Column

The Birth of the Ransomware Flag

In October 2023, CISA announced an update to its Known Exploited Vulnerabilities catalog as part of the Ransomware Vulnerability Warning Pilot (RVWP) program. They added a new column: “Known To Be Used in Ransomware Campaigns.”

The stated goal was noble: help organizations prioritize more effectively by identifying which vulnerabilities ransomware operators were actively leveraging. Organizations enrolled in CISA’s vulnerability scanning service would get early warnings, and now everyone could see this intelligence in the public catalog.

CISA Associate Director of Vulnerability Management Sandra Radesky and Lead Operations Risk Advisor Gabriel Davis announced the change, stating: “All organizations have access to this information in our known exploited vulnerabilities (KEV) catalog as we added a column titled, ‘known to be used in ransomware campaigns.’”

What they didn’t emphasize—what almost nobody noticed—was that this field would be updated silently for existing entries as new intelligence emerged.

The Quiet Part Out Loud

When a new CVE is added to KEV, CISA issues an alert. Organizations that follow CISA’s feeds get notified. Security teams can react.

But when CISA updates an existing entry—when they flip that ransomware flag from “Unknown” to “Known”—nothing happens. No announcement. No changelog. No notification mechanism of any kind.

As security researcher Glenn Thorpe of GreyNoise wrote in his February 2026 analysis: “When that field flips from ‘Unknown’ to ‘Known,’ CISA is saying: ‘We have evidence that ransomware operators are now using this vulnerability in their campaigns.’ That’s a material change in your risk posture. Your prioritization calculus should shift. But there’s no alert, no announcement. Just a field change in a JSON file.”

The Scope of the Problem: 59 Silent Flips in 2025

Thorpe didn’t just complain about the problem—he quantified it. By pulling daily snapshots of the KEV catalog throughout 2025 and comparing them for changes, he identified exactly how many vulnerabilities had their ransomware status silently updated.

The results were staggering.

By the Numbers

| Metric | Value |
| Total CVEs that silently flipped | 59 |
| Most affected vendor | Microsoft (27% - 16 CVEs) |
| Edge/network device CVEs | 34% (19 CVEs) |
| Legacy CVEs (pre-2023) | 39% (23 CVEs) |
| Fastest time-to-ransomware flip | 1 day |
| Longest time-to-ransomware flip | 1,353 days |
| Peak month for silent flips | May (41% of all flips) |
| Most common vulnerability type | Authentication Bypass (14%) |

Let that sink in. Over a third of these vulnerabilities target the very edge devices—firewalls, VPN concentrators, remote access gateways—that organizations deploy to protect their networks. And 39% were legacy vulnerabilities, some dating back years, that suddenly became ransomware-relevant.

The Vendor Breakdown

The distribution of affected vendors tells a story about where ransomware operators are focusing their efforts:

Microsoft - 16 CVEs (27%)

  • SharePoint vulnerabilities
  • Print Spooler exploits
  • Group Policy weaknesses
  • Mark-of-the-Web bypasses
  • Windows Kernel vulnerabilities

Ivanti - 6 CVEs (10%)

  • Connect Secure authentication bypasses
  • Command injection vulnerabilities
  • SSRF (Server-Side Request Forgery)
  • Endpoint Manager exploits

Fortinet - 5 CVEs (8%)

  • FortiOS SSL-VPN heap overflows
  • Authentication bypass vulnerabilities

Palo Alto Networks - 3 CVEs (5%)

  • PAN-OS authentication bypasses
  • GlobalProtect command injection
  • Privilege escalation vulnerabilities

Zimbra (Synacor) - 3 CVEs (5%)

  • Email compromise vectors
  • Authentication vulnerabilities

The pattern is clear: ransomware operators are building systematic playbooks around enterprise perimeter devices and Microsoft infrastructure—the exact systems that provide access to high-value targets.

The Edge Device Crisis

Perhaps the most alarming finding is the concentration on network security appliances. Of the 59 vulnerabilities that silently flipped to ransomware association in 2025, 19 target the devices specifically deployed to protect organizations: VPN concentrators, firewalls, and remote access gateways.

This isn’t coincidental. Ransomware operators are economic actors. They invest in exploit development for platforms that offer:

  1. High deployment rates across valuable targets
  2. Direct access to internal networks once compromised
  3. Persistent access that survives standard remediation
  4. Elevated privileges that enable lateral movement

Fortinet SSL-VPN vulnerabilities. Ivanti Connect Secure authentication bypasses. Palo Alto GlobalProtect command injection. Check Point Security Gateway exploits. These aren’t random targets—they’re strategic investments in access.

When CVE-2024-24919 (Check Point Security Gateway) silently flipped to “Known” ransomware use on February 26, 2025, organizations that had deprioritized it because it “wasn’t ransomware-related” suddenly had a problem. And they didn’t know it.

The Legacy Vulnerability Problem

Almost 40% of the silent flips involved vulnerabilities from before 2023. Some dated back years:

  • CVE-2008-2992 (Adobe Reader) - Flipped May 2025, 17 years after disclosure
  • CVE-2012-4681 (Oracle Java) - Flipped May 2025, 13 years after disclosure
  • CVE-2012-1710 (Oracle) - Flipped May 2025, 13 years after disclosure
  • CVE-2014-1812 (Microsoft) - Flipped May 2025, 11 years after disclosure
  • CVE-2015-2291 (Intel) - Flipped April 2025, 10 years after disclosure
  • CVE-2015-7645 (Adobe Flash) - Flipped May 2025, 10 years after disclosure
  • CVE-2019-0708 (Microsoft BlueKeep) - Flipped July 2025, 6 years after disclosure

This demolishes the assumption that “old vulnerabilities are already patched everywhere.” Ransomware operators are actively incorporating legacy exploits into their toolkits because:

  1. Legacy systems persist in enterprise environments far longer than IT teams admit
  2. Patch fatigue leads to skipped updates for “ancient” CVEs
  3. Detection evasion—older exploits may not trigger modern security tools
  4. Supply chain propagation—legacy code lives on in modern products

When an Adobe Reader vulnerability from 2008 suddenly becomes ransomware-relevant in 2025, it’s not because attackers just discovered it. It’s because they’ve found enough unpatched targets to make it worth operationalizing.

The Complete List: 59 CVEs That Silently Flipped in 2025

For security teams, here’s the full inventory of vulnerabilities whose ransomware association changed without announcement in 2025. Check these against your vulnerability management data:

Q1 2025 Flips

| CVE ID | Vendor | Product | Date Added | Date Flipped |
| CVE-2024-24919 | Check Point | Security Gateway | 2024-05-30 | 2025-02-26 |
| CVE-2023-23376 | Microsoft | Windows | 2023-02-14 | 2025-03-17 |
| CVE-2023-48365 | Qlik | Sense Enterprise | 2025-01-13 | 2025-03-17 |
| CVE-2024-55591 | Fortinet | FortiOS | 2025-01-14 | 2025-03-17 |
| CVE-2025-24472 | Fortinet | FortiOS | 2025-03-18 | 2025-03-19 |
| CVE-2025-26633 | Microsoft | Windows | 2025-03-11 | 2025-03-31 |

Q2 2025 Flips (The May Surge)

May 2025 saw an extraordinary concentration of silent flips—41% of the year’s total occurred in a single month:

| CVE ID | Vendor | Product | Date Added | Date Flipped |
| CVE-2022-27925 | Synacor | Zimbra | 2022-08-11 | 2025-04-03 |
| CVE-2022-37042 | Synacor | Zimbra | 2022-08-11 | 2025-04-03 |
| CVE-2022-42475 | Fortinet | FortiOS SSL-VPN | 2022-12-13 | 2025-04-07 |
| CVE-2024-3400 | Palo Alto | PAN-OS | 2024-04-12 | 2025-04-07 |
| CVE-2024-30051 | Microsoft | Windows DWM | 2024-05-14 | 2025-04-07 |
| CVE-2024-38094 | Microsoft | SharePoint | 2024-10-22 | 2025-04-07 |
| CVE-2018-8639 | Microsoft | Win32k | 2025-03-03 | 2025-04-07 |
| CVE-2025-31161 | CrushFTP | CrushFTP | 2025-04-07 | 2025-04-09 |
| CVE-2025-29824 | Microsoft | CLFS Driver | 2025-04-08 | 2025-04-09 |
| CVE-2015-2291 | Intel | Ethernet Diagnostics | 2023-02-10 | 2025-04-26 |
| CVE-2019-11580 | Atlassian | Crowd | 2021-11-03 | 2025-05-12 |
| CVE-2021-22205 | GitLab | CE/EE | 2021-11-03 | 2025-05-12 |
| CVE-2014-1812 | Microsoft | Group Policy | 2021-11-03 | 2025-05-12 |
| CVE-2015-7645 | Adobe | Flash Player | 2022-03-03 | 2025-05-12 |
| CVE-2008-2992 | Adobe | Reader | 2022-03-03 | 2025-05-12 |
| CVE-2022-30190 | Microsoft | MSDT (Follina) | 2022-06-14 | 2025-05-12 |
| CVE-2022-41091 | Microsoft | Mark-of-the-Web | 2022-11-08 | 2025-05-12 |
| CVE-2017-6884 | Zyxel | EMG2926 | 2023-09-18 | 2025-05-12 |
| CVE-2024-0012 | Palo Alto | PAN-OS | 2024-11-18 | 2025-05-12 |
| CVE-2024-55550 | Mitel | MiCollab | 2025-01-07 | 2025-05-12 |
| CVE-2024-41713 | Mitel | MiCollab | 2025-01-07 | 2025-05-12 |
| CVE-2025-0282 | Ivanti | Connect Secure | 2025-01-08 | 2025-05-12 |
| CVE-2025-23006 | SonicWall | SMA1000 | 2025-01-24 | 2025-05-12 |
| CVE-2025-22457 | Ivanti | Connect Secure | 2025-04-04 | 2025-05-12 |
| CVE-2021-43890 | Microsoft | AppX Installer | 2021-12-15 | 2025-05-13 |
| CVE-2022-21999 | Microsoft | Print Spooler | 2022-03-25 | 2025-05-13 |
| CVE-2022-2294 | WebRTC | Chrome/Edge | 2022-08-25 | 2025-05-13 |
| CVE-2025-31324 | SAP | NetWeaver | 2025-04-29 | 2025-05-15 |
| CVE-2024-57727 | SimpleHelp | Remote Support | 2025-02-13 | 2025-05-27 |
| CVE-2012-4681 | Oracle | Java | 2022-03-03 | 2025-05-29 |
| CVE-2012-1710 | Oracle | Fusion Middleware | 2022-05-25 | 2025-05-29 |
| CVE-2022-27924 | Synacor | Zimbra | 2022-08-04 | 2025-05-29 |
| CVE-2022-30333 | RARLAB | WinRAR | 2022-08-09 | 2025-05-29 |
| CVE-2021-44529 | Ivanti | EPM Cloud | 2024-03-25 | 2025-05-31 |
| CVE-2023-43208 | NextGen | Mirth Connect | 2024-05-20 | 2025-06-03 |
| CVE-2024-21762 | Fortinet | FortiOS | 2024-02-09 | 2025-06-09 |

Q3-Q4 2025 Flips

| CVE ID | Vendor | Product | Date Added | Date Flipped |
| CVE-2019-6693 | Fortinet | FortiOS | 2025-06-25 | 2025-07-14 |
| CVE-2019-0708 | Microsoft | RDP (BlueKeep) | 2021-11-03 | 2025-07-18 |
| CVE-2025-49704 | Microsoft | Windows | 2025-07-22 | 2025-07-24 |
| CVE-2025-49706 | Microsoft | Windows | 2025-07-22 | 2025-07-24 |
| CVE-2025-53770 | Microsoft | Windows | 2025-07-20 | 2025-08-04 |
| CVE-2025-5777 | Citrix | ADC/Gateway | 2025-07-10 | 2025-08-15 |
| CVE-2025-10035 | Fortra | GoAnywhere | 2025-09-29 | 2025-10-07 |
| CVE-2025-61882 | Oracle | E-Business Suite | 2025-10-06 | 2025-10-07 |
| CVE-2023-46805 | Ivanti | Connect Secure | 2024-01-10 | 2025-10-08 |
| CVE-2024-21887 | Ivanti | Connect Secure | 2024-01-10 | 2025-10-08 |
| CVE-2024-21893 | Ivanti | Connect Secure | 2024-01-31 | 2025-10-08 |
| CVE-2024-21412 | Microsoft | SmartScreen | 2024-02-13 | 2025-10-08 |
| CVE-2025-61884 | Oracle | E-Business Suite | 2025-10-20 | 2025-10-22 |
| CVE-2024-9474 | Palo Alto | PAN-OS | 2024-11-18 | 2025-10-30 |
| CVE-2024-1086 | Linux | Kernel | 2024-05-30 | 2025-10-31 |
| CVE-2025-55182 | Meta | React | 2025-12-05 | 2025-12-12 |
| CVE-2024-53704 | SonicWall | SonicOS | 2025-02-18 | 2025-12-19 |

Why Isn’t CISA Announcing These Changes?

This is the question security professionals have been asking since the pattern was identified. CISA maintains RSS feeds for new KEV additions. They issue alerts when particularly critical vulnerabilities are added. Why not do the same for ransomware status changes?

Several theories circulate in the security community:

Theory 1: Resource Constraints

Creating a formal changelog or notification system requires development resources. CISA is already stretched thin, and building additional infrastructure for what amounts to a field change in an existing system may not be prioritized.

Counterpoint: The community has built solutions (like GreyNoise’s RSS feed) in days. This isn’t a technically complex problem.

Theory 2: Intelligence Sensitivity

Some ransomware attribution comes from classified sources or ongoing investigations. Announcing “this CVE is now confirmed ransomware-related” might reveal intelligence methods or tip off threat actors.

Counterpoint: The data is already public in the JSON/CSV feeds. Anyone who cares can diff daily snapshots and see the changes. Obscurity isn’t security.

Theory 3: Avoiding False Urgency

If every ransomware flag flip triggered an alert, organizations might become desensitized. By keeping it quiet, CISA avoids contributing to alert fatigue.

Counterpoint: Organizations are using this field for prioritization. Failing to alert on changes means organizations are making decisions based on stale data. That’s worse than alert fatigue.

Theory 4: It’s Just an Oversight

The ransomware column was added as an enhancement, and nobody built notification infrastructure for changes to existing entries. It’s not malicious—it’s just incomplete.

Most likely answer: This is probably the truth. The KEV was designed for additions, not updates. The ransomware column was bolted on, and change notification was never part of the design.

The Impact on Security Operations

Understanding the theoretical problem is one thing. Let’s talk about real-world consequences.

Scenario 1: The Deprioritized Patch

Your vulnerability management team follows a risk-based approach. CVE-2024-24919 (Check Point Security Gateway) was added to KEV in May 2024 with “Unknown” ransomware status. Your environment has it, but given competing priorities and the “Unknown” status, you scheduled it for next quarter.

On February 26, 2025, CISA silently flipped it to “Known.” Ransomware operators are actively using it. You don’t know this because there was no alert. Your quarterly patch window comes… in three months.

For those three months, you have a confirmed ransomware entry point that you’ve explicitly deprioritized.

Scenario 2: The Legacy Assumption

Your organization ran a legacy vulnerability cleanup project in 2023, patching everything from 2020 and earlier. Adobe Reader 2008? Patched. Oracle Java 2012? Patched. Case closed.

Except not every system was covered. That air-gapped manufacturing workstation. That legacy application server that “can’t be updated.” That vendor-managed system you don’t have access to.

When CVE-2008-2992 and CVE-2012-4681 flip to ransomware association in May 2025, your assumption that “legacy = irrelevant” proves catastrophically wrong. Those forgotten systems become ransomware entry points.

Scenario 3: The Compliance Gap

Your organization uses KEV as part of compliance reporting. You track patching status for all KEV vulnerabilities and maintain a risk register that notes ransomware association.

Six months later, an auditor asks about CVE-2024-21762 (Fortinet). Your records show “Unknown” ransomware status because that’s what it was when you last imported KEV data. But it flipped to “Known” in June 2025. Your risk register is wrong. Your compliance posture is wrong. Your board reports are wrong.

How to Fix This: Practical Solutions

Complaining about the problem is easy. Let’s talk solutions.

Solution 1: Subscribe to the GreyNoise RSS Feed

Glenn Thorpe didn’t just identify the problem—he built a solution. GreyNoise now maintains an RSS feed that monitors for ransomware status changes:

URL: https://kev.labs.greynoise.io/kev-ransom-feed.rss

The feed checks hourly and will notify you whenever a ransomware flag flips. Add it to your security team’s RSS reader, your SIEM, or your notification system.

This is the lowest-effort solution available. It takes five minutes to implement and solves 90% of the problem.

Solution 2: Build Your Own Monitoring

If you want more control or don’t want to rely on a third party, build your own monitoring:

#!/usr/bin/env python3
"""
KEV Ransomware Monitor
Pull daily KEV snapshots, diff for ransomware status changes
"""

import json
import requests
from datetime import datetime
import os

KEV_URL = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
CACHE_DIR = "/var/cache/kev-monitor"

def fetch_kev():
    response = requests.get(KEV_URL)
    return response.json()

def load_previous():
    cache_file = os.path.join(CACHE_DIR, "previous.json")
    if os.path.exists(cache_file):
        with open(cache_file) as f:
            return json.load(f)
    return None

def save_current(data):
    os.makedirs(CACHE_DIR, exist_ok=True)
    cache_file = os.path.join(CACHE_DIR, "previous.json")
    with open(cache_file, 'w') as f:
        json.dump(data, f)

def find_ransomware_flips(current, previous):
    if not previous:
        return []
    
    prev_map = {v['cveID']: v for v in previous['vulnerabilities']}
    flips = []
    
    for vuln in current['vulnerabilities']:
        cve_id = vuln['cveID']
        current_status = vuln.get('knownRansomwareCampaignUse', 'Unknown')
        
        if cve_id in prev_map:
            prev_status = prev_map[cve_id].get('knownRansomwareCampaignUse', 'Unknown')
            if prev_status == 'Unknown' and current_status == 'Known':
                flips.append({
                    'cve_id': cve_id,
                    'vendor': vuln.get('vendorProject'),
                    'product': vuln.get('product'),
                    'description': vuln.get('shortDescription'),
                    'flip_date': datetime.now().isoformat()
                })
    
    return flips

def alert(flips):
    # Implement your alerting here: Slack, email, PagerDuty, etc.
    for flip in flips:
        print(f"RANSOMWARE FLIP: {flip['cve_id']} ({flip['vendor']} {flip['product']})")

def main():
    current = fetch_kev()
    previous = load_previous()
    
    flips = find_ransomware_flips(current, previous)
    
    if flips:
        alert(flips)
    
    save_current(current)

if __name__ == "__main__":
    main()

Run this daily via cron. Integrate with your existing alerting infrastructure.

Solution 3: Integrate with Vulnerability Management Platforms

Many commercial vulnerability management platforms can consume the KEV feed. Work with your vendor to:

  1. Ensure they’re pulling KEV data daily (not weekly or monthly)
  2. Configure alerts for ransomware status changes
  3. Auto-adjust risk scores when ransomware association flips

If your platform doesn’t support this, that’s a feature request worth making.

Solution 4: Stop Using Ransomware Status as a Deprioritization Factor

Here’s the uncomfortable truth: if a vulnerability is in KEV, it’s already being exploited in the wild. The “Unknown” ransomware status doesn’t mean it’s safe—it means CISA doesn’t yet have evidence of ransomware use.

Consider treating ALL KEV vulnerabilities as ransomware-relevant for prioritization purposes. Use the “Known” ransomware flag as an escalation indicator, not a prerequisite for action.

Solution 5: Focus on High-Risk Categories

Based on the 2025 data, prioritize extra attention on:

  • Microsoft vulnerabilities (27% of all flips)

  • Edge/perimeter devices (34% of all flips)

    • Fortinet FortiOS/FortiGate
    • Ivanti Connect Secure/Pulse Secure
    • Palo Alto PAN-OS/GlobalProtect
    • SonicWall SMA/SonicOS
    • Check Point Security Gateway
    • Citrix ADC/Gateway

  • Email servers (Zimbra especially)

  • Authentication bypass vulnerabilities (14% of all flips)

  • Legacy systems that may still exist in your environment

What CISA Should Do

This section isn’t about blaming CISA—they’re doing important work with limited resources. But as a community, we should advocate for better:

1. Create a Changelog

A simple text file tracking all changes to KEV entries, not just additions. Include the date, CVE ID, field changed, old value, and new value. Publish it alongside the JSON/CSV feeds.

2. Add an RSS Feed for Changes

Just like the existing additions feed, create a feed for modifications. Let organizations subscribe to the intelligence they need.

3. Send Email Alerts for High-Impact Changes

When a vulnerability flips to “Known” ransomware use, that’s a high-impact change. Send a notification to organizations enrolled in CISA alerts.

4. Add Timestamps to the Data

The current KEV format includes dateAdded but not dateModified. Adding a modification timestamp would let organizations easily identify what’s changed since their last pull.

5. Document the Change Process

How does CISA decide when to flip a vulnerability to “Known”? What evidence is required? How long is the typical lag? Transparency about the process would help organizations plan.

The Bigger Picture: Intelligence as a Living System

This issue highlights a fundamental challenge in threat intelligence: intelligence isn’t static. Threat landscapes evolve. Attribution improves. What was uncertain yesterday becomes confirmed today.

The KEV catalog is a living document, and we’ve been consuming it like it’s carved in stone. The infrastructure for consuming threat intelligence needs to evolve:

  1. Differential updates instead of (or in addition to) full downloads
  2. Change notifications for all material modifications
  3. Historical versions for audit and analysis purposes
  4. Machine-readable changelogs that automation can consume

CISA’s KEV is just one example. The same problem exists across threat intelligence platforms: IOC feeds that silently update, threat actor profiles that evolve, and vulnerability data that changes without notification.

As defenders, we need to build systems that expect change—not just react to additions but monitor for modifications across all dimensions of our intelligence feeds.

Recent Updates: What’s Changed in 2026

As of February 2026, CISA continues the pattern of silent updates. Recent additions with “Known” ransomware status include:

CVE-2026-24423 - SmarterTools SmarterMail Missing Authentication

  • Added: February 5, 2026
  • Status: Known ransomware use
  • Risk: Missing authentication for critical function in ConnectToHub API allows command execution

CVE-2025-55182 - Meta React Server Components RCE

  • Added: December 5, 2025
  • Flipped: December 12, 2025 (7 days later)
  • Risk: Remote code execution via flaw in React Server Function payload decoding

The most recent batch of flips occurred on January 28, 2026:

  • CVE-2024-49039: Microsoft Windows Task Scheduler Privilege Escalation
  • CVE-2024-51567: CyberPanel Incorrect Default Permissions
  • CVE-2024-9680: Mozilla Firefox Use-After-Free
  • CVE-2024-30088: Microsoft Windows Kernel TOCTOU Race Condition

These four CVEs sat in KEV for months with “Unknown” status before silently changing. Organizations that deprioritized them based on ransomware status are now behind.

Action Items for Security Teams

Let’s make this concrete. Here’s what you should do this week:

Immediate (Today)

  1. Subscribe to the GreyNoise RSS feed: https://kev.labs.greynoise.io/kev-ransom-feed.rss
  2. Review the 59 flipped CVEs against your vulnerability data
  3. Check for unpatched instances of the edge device vulnerabilities (Fortinet, Ivanti, Palo Alto, SonicWall)

This Week

  1. Update your vulnerability management workflow to not deprioritize based on “Unknown” ransomware status
  2. Build or implement daily KEV monitoring for ransomware status changes
  3. Review legacy vulnerability coverage—are you still patching pre-2023 CVEs?

This Month

  1. Audit your edge device patching program—these are the primary targets
  2. Update compliance documentation to reflect the current ransomware status of KEV entries
  3. Brief leadership on this intelligence gap and your mitigation plan

Ongoing

  1. Advocate to CISA for better change notification (they do listen to feedback)
  2. Check vendor tooling for KEV integration quality
  3. Consider contributing to open-source monitoring solutions

Conclusion: The Sound No One Heard

In the cybersecurity community, we often talk about the importance of threat intelligence. We build elaborate systems to consume, correlate, and act on intelligence feeds. We pay substantial money for commercial threat intel platforms. We train analysts to synthesize information from multiple sources.

And yet, one of the most important, freely available intelligence sources—CISA’s Known Exploited Vulnerabilities catalog—is being updated in ways we’re not monitoring. Fifty-nine times in 2025, CISA told us that a vulnerability was now confirmed ransomware-relevant. Fifty-nine times, that intelligence disappeared into a JSON file without anyone being alerted.

The tree fell. It made a sound. And most of us weren’t listening.

Now you are.

Resources

Official CISA Resources

Community Solutions

Further Reading

  • CISA RVWP Announcement (October 2023)
  • The Record: “CISA plans to share more information on ransomware actors in its exploited vulnerability alerts”
  • SOCRadar: “2023 Review of the CISA Known Exploited Vulnerabilities (KEV) Catalog”