CISA’s Silent KEV Ransomware Updates: 59 CVEs Changed Without Warning in 2025

There’s a field in CISA’s Known Exploited Vulnerabilities catalog that almost nobody watches. It’s called knownRansomwareCampaignUse. In 2025, it flipped from “Unknown” to “Known” 59 times — and CISA sent exactly zero notifications each time.

That’s not a bug. It’s just how the system works. And it’s quietly wrecking your risk prioritization.

What Is the KEV Catalog — and Why Does the Ransomware Flag Matter?

CISA’s Known Exploited Vulnerabilities (KEV) catalog is the government’s official list of CVEs that are actively being exploited in the wild. Federal agencies are required to patch KEV entries within specific deadlines. For everyone else, it’s the closest thing we have to a curated “patch this immediately” signal.

In October 2023, CISA added a knownRansomwareCampaignUse field to each KEV entry. The intent was solid: help defenders distinguish between “exploited by nation-state operators” and “actively being used to deploy ransomware.” Those are different threat profiles that warrant different response urgency.

When that field reads “Known,” CISA is saying they have confirmed intelligence that ransomware groups are using this specific vulnerability in live campaigns. That’s a material change. It means:

  • The exploit is likely commoditized or available in crimeware kits
  • The attacker pool has expanded from skilled threat actors to script kiddies with Ransomware-as-a-Service access
  • The probability of being hit is now statistically higher

Here’s the problem: CISA updates this field silently. No announcement. No changelog. No alert. Just a quiet JSON field change in the catalog file.

59 Silent Flips in 2025

GreyNoise researcher Glenn Thorpe noticed something nobody else had bothered to systematically track: the knownRansomwareCampaignUse field was being updated on existing KEV entries all year long, with no disclosure.

To surface this, Thorpe pulled daily snapshots of the entire KEV catalog throughout 2025 and diffed them. The results were alarming.

59 CVEs flipped from “Unknown” to “Known” ransomware use in 2025 — with no announcements. Here’s the breakdown:

MetricValue
Total silent flips in 202559
Top vendorMicrosoft (27% — 16 CVEs)
Edge/network device CVEs34% (20 of 59)
Legacy CVEs (pre-2023)39%
Fastest flip after KEV entry1 day
Longest flip after KEV entry1,353 days
Peak flip monthMay 2025 (41% of all flips)
Most common vulnerability typeAuthentication Bypass (14%)

The longest delay — 1,353 days — belongs to BlueKeep. More on that in a moment.

The 34% Edge Device Problem

Nearly a third of the silent flips target network security appliances. These aren’t workstations or servers tucked inside your perimeter. These are the devices protecting your perimeter — SSL-VPNs, firewalls, remote access gateways.

The affected platforms read like a who’s-who of enterprise network security:

  • Fortinet FortiOS SSL-VPN — 5 CVEs flipped
  • Ivanti Connect Secure — 6 CVEs flipped (auth bypass, command injection, SSRF)
  • Palo Alto GlobalProtect / PAN-OS — 3 CVEs flipped
  • Check Point Security Gateway — 1 high-profile flip

Ransomware operators have built repeatable playbooks around these devices because the calculus is simple: one successful auth bypass on a VPN concentrator = access to the entire corporate network. That’s a better ROI than phishing through an EDR.

When authentication bypass vulnerabilities flip to “Known Ransomware Use,” that means organized criminal groups have integrated the exploit into their deployment pipelines. Every unpatched instance is a loaded gun pointed at your network.

The BlueKeep Wake-Up Call

CVE-2019-0708 — BlueKeep — is the most dramatic example of why silent flips matter.

BlueKeep is a critical RCE vulnerability in Windows Remote Desktop Services. It was disclosed in May 2019. Microsoft issued emergency patches. CISA warned about it. Security vendors published PoC exploits. It was everywhere in the news. Companies patched it (most of them).

CISA added BlueKeep to the KEV catalog in November 2021 — two years after disclosure.

Then, in July 2025, the knownRansomwareCampaignUse field silently flipped from “Unknown” to “Known.”

That’s 1,353 days after it was added to KEV. Four years after the original vulnerability. Six years after initial disclosure.

Here’s the operational impact: any security team that patched BlueKeep in 2019-2020, flagged it as “handled,” and moved on was flying blind. The threat profile of that CVE changed in July 2025 — and nobody told them. If any unpatched legacy Windows systems were still lurking (and in most enterprise networks, they are), those teams had no new signal to prompt a sweep.

CVE-2022-30190 (Follina) had a similar story — disclosed in May 2022, became a major story, and then silently flipped to ransomware use status in May 2025. Three years of assumed stability, undone by a quiet field change.

The Vendor Breakdown

The full picture of affected vendors shows exactly where ransomware operators are investing:

Microsoft — 16 CVEs

  • SharePoint vulnerabilities (CVE-2024-38094)
  • Print Spooler (CVE-2022-21999)
  • Mark-of-the-Web bypasses (CVE-2022-41091)
  • Group Policy client (CVE-2014-1812 — yes, from 2014)
  • Windows kernel race conditions
  • MSHTML / Follina

Ivanti — 6 CVEs

  • Connect Secure authentication bypass
  • Command injection chains
  • SSRF vulnerabilities
  • Endpoint Manager (EPM) flaws

Fortinet — 5 CVEs

  • FortiOS SSL-VPN heap overflows
  • Authentication bypass chains

Palo Alto Networks — 3 CVEs

  • PAN-OS authentication bypass
  • GlobalProtect command injection
  • Privilege escalation

Zimbra — 3 CVEs

  • Email server compromise vectors — still one of the most reliable initial access paths

Top 25+ Silent Flips: The CVE Table

Here are the highest-impact entries that flipped to “Known Ransomware Use” in 2025, sorted by notability:

CVEVendor / ProductAdded to KEVFlipped to KnownDays Elapsed
CVE-2019-0708Microsoft — Windows RDP (BlueKeep)2021-11-032025-07-xx1,353
CVE-2022-30190Microsoft — MSHTML/Follina2022-06-142025-05-121,063
CVE-2014-1812Microsoft — Group Policy2021-11-032025-05-121,286
CVE-2015-2291Intel — Driver2023-02-102025-04-26805
CVE-2008-2992Adobe Reader2022-03-032025-05-121,165
CVE-2015-7645Adobe Flash2022-03-032025-05-121,165
CVE-2012-4681Oracle Java2022-03-032025-05-291,182
CVE-2012-1710Oracle Java2022-05-252025-05-291,100
CVE-2021-22205GitLab — CE/EE RCE2021-11-032025-05-121,286
CVE-2019-11580Atlassian Crowd2021-11-032025-05-121,286
CVE-2022-42475Fortinet — FortiOS SSL-VPN2022-12-132025-04-07846
CVE-2024-21762Fortinet — FortiOS2024-02-092025-06-09485
CVE-2024-24919Check Point — Security Gateway2024-05-302025-02-26272
CVE-2024-3400Palo Alto — PAN-OS GlobalProtect2024-04-122025-04-07360
CVE-2024-0012Palo Alto — PAN-OS Auth Bypass2024-11-182025-05-12175
CVE-2025-0282Ivanti — Connect Secure2025-01-082025-05-12124
CVE-2025-22457Ivanti — Connect Secure RCE2025-04-042025-05-1238
CVE-2025-31161CrushFTP — Auth Bypass2025-04-072025-04-092
CVE-2025-29824Microsoft — Windows CLFS2025-04-082025-04-091
CVE-2025-31324SAP — NetWeaver RCE2025-04-292025-05-1516
CVE-2024-55591Fortinet — FortiOS/FortiProxy2025-01-142025-03-1762
CVE-2025-24472Fortinet — FortiOS/FortiProxy2025-03-182025-03-191
CVE-2025-26633Microsoft — MMC2025-03-112025-03-3120
CVE-2022-27924Synacor Zimbra2022-08-042025-05-291,029
CVE-2022-27925Synacor Zimbra2022-08-112025-04-03965
CVE-2025-23006SonicWall — SMA2025-01-242025-05-12108
CVE-2023-48365Qlik Sense2025-01-132025-03-1763
CVE-2024-30051Microsoft — DWM Core Library2024-05-142025-04-07328
CVE-2024-38094Microsoft — SharePoint2024-10-222025-04-07167
CVE-2021-44529Ivanti — EPM Cloud Services2024-03-252025-05-31432

That last column is the one that should keep you up at night. These aren’t new disclosures — they’re existing entries where the threat characterization changed without anyone telling you.

Why This Breaks Risk Prioritization

Most vulnerability management programs work roughly like this:

  1. New CVE appears
  2. Check if it’s in KEV → patch with urgency
  3. Check CVSS score → prioritize accordingly
  4. Check “Known Ransomware Use” → escalate if flagged

Step 4 fails completely if you only check the ransomware flag at intake and never re-check existing entries.

This matters because most organizations track their unpatched CVEs by age. A vulnerability that’s been sitting in KEV for two years with no ransomware flag often gets de-prioritized: “We know about it, we’ll get to it, it’s not ransomware.” Then it silently flips. Nothing in your workflow triggers a reassessment.

The CrushFTP example (CVE-2025-31161) shows the other extreme: 2 days from KEV addition to ransomware flip. That’s near-zero warning time for anyone not actively monitoring the field.

How to Actually Monitor This

You have two practical options:

Option 1: Subscribe to the GreyNoise RSS Feed

Glenn Thorpe (the researcher who discovered this problem) built a dedicated monitoring feed:

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

This feed checks the KEV catalog hourly and publishes an RSS entry every time a knownRansomwareCampaignUse field flips. Drop it into your RSS reader, your SIEM, or your ticketing system’s webhook intake.

This is the fastest path from zero to monitored.

Option 2: Build Your Own JSON Diff Monitor

CISA publishes the full KEV catalog as a JSON file:

https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

Here’s a minimal Python script to diff it daily and alert on ransomware flag changes:

#!/usr/bin/env python3
import json
import urllib.request
import sqlite3
import smtplib
from datetime import datetime
from email.message import EmailMessage

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

def fetch_kev():
    with urllib.request.urlopen(KEV_URL) as r:
        return json.loads(r.read())

def init_db(conn):
    conn.execute("""
        CREATE TABLE IF NOT EXISTS kev_state (
            cveID TEXT PRIMARY KEY,
            ransomwareUse TEXT,
            lastChecked TEXT
        )
    """)
    conn.commit()

def check_flips(conn, vulns):
    flips = []
    for v in vulns:
        cve = v["cveID"]
        current = v.get("knownRansomwareCampaignUse", "Unknown")
        row = conn.execute("SELECT ransomwareUse FROM kev_state WHERE cveID=?", (cve,)).fetchone()
        if row:
            if row[0] == "Unknown" and current == "Known":
                flips.append({"cve": cve, "product": v.get("product", ""), "vendorProject": v.get("vendorProject", "")})
            conn.execute("UPDATE kev_state SET ransomwareUse=?, lastChecked=? WHERE cveID=?",
                         (current, datetime.utcnow().isoformat(), cve))
        else:
            conn.execute("INSERT INTO kev_state VALUES (?, ?, ?)",
                         (cve, current, datetime.utcnow().isoformat()))
    conn.commit()
    return flips

def alert(flips):
    if not flips:
        return
    body = "The following CVEs silently flipped to Known Ransomware Use:\n\n"
    for f in flips:
        body += f"  {f['cve']} — {f['vendorProject']} {f['product']}\n"
    print(body)
    # Add SMTP/Slack/webhook alert here

if __name__ == "__main__":
    data = fetch_kev()
    conn = sqlite3.connect(DB_PATH)
    init_db(conn)
    flips = check_flips(conn, data["vulnerabilities"])
    alert(flips)

Run this as a daily cron job. Pipe the output to your ticketing system, Slack, or PagerDuty. The script maintains a local SQLite state so it only alerts on actual changes, not on every run.

Option 3: Integrate into Your VM Platform

If you’re using Tenable, Qualys, or Rapid7, check whether your platform already ingests KEV data and whether it alerts on field-level changes — not just new additions. Most don’t do this by default. File a feature request or build a custom integration using the JSON feed.

The Bigger Blind Spot

This isn’t just a CISA process problem. It’s a symptom of how we consume threat intelligence: we’re good at reacting to new disclosures, decent at tracking active exploitation headlines, but terrible at noticing when the characterization of existing threats evolves.

CISA already has the intelligence. They’re tracking ransomware campaigns, correlating TTPs, and updating their internal assessments. When they update the knownRansomwareCampaignUse field, that’s real intelligence reaching you — silently, in a JSON file, with no fanfare.

The question is whether your detection is tuned to see it.

Actionable Checklist

This week:

  • Subscribe to the GreyNoise KEV ransomware RSS feed: https://kev.labs.greynoise.io/kev-ransom-feed.rss
  • Search your unpatched CVE backlog for every entry in the table above — re-triage immediately
  • Run an inventory sweep for any unpatched edge devices (Fortinet, Ivanti, Palo Alto, Check Point)

This month:

  • Deploy the JSON diff monitoring script as a daily cron job
  • Add a KEV ransomware flip webhook to your SIEM or ticketing system
  • Review your VM program’s intake process — add a step to re-check ransomware status on existing KEV entries quarterly
  • Specifically: find any instance of BlueKeep (CVE-2019-0708) on legacy Windows — it’s now confirmed ransomware-active
  • Hunt for Follina (CVE-2022-30190) exposure — it flipped in May 2025, almost 3 years after disclosure

Ongoing:

  • Treat knownRansomwareCampaignUse flips as a first-class alert, equivalent in urgency to a new KEV addition
  • Add Zimbra to your attack surface monitoring — 3 CVEs flipped in 2025 and it remains a reliable initial access vector
  • Build or buy a capability to diff KEV entries on field changes, not just additions
  • Document this gap in your VM program’s assumptions — “we monitor KEV additions” ≠ “we monitor KEV changes”

Sources: