602-725-2818Licensed, insured & bondedSchedule a Consultation
Call 602-725-2818Consultation

Actively Exploited Windows Vulnerabilities: CISA’s KEV Catalog, Patch Tuesday, and Why Patch Velocity Wins

Every second Tuesday of the month, Microsoft ships a batch of security updates, and somewhere in that batch is almost always a flaw that a threat actor is already using. The uncomfortable truth of modern defense is that the gap between “patch available” and “patch installed” is where most preventable intrusions happen. A vulnerability that Microsoft has already fixed is not a theoretical risk — it is an open door that your patch management program either closed on time or left ajar.

This article is written for the defender who owns a Windows fleet: the IT lead at a small business, the sysadmin at a growing firm, the security manager trying to prove to auditors that endpoints are current. We will walk through Microsoft’s Patch Tuesday cadence, explain exactly what it means when a Windows CVE lands in CISA’s Known Exploited Vulnerabilities (KEV) catalog, break down the bug classes attackers reach for most, and then get practical about running patch management for Windows at scale. The thesis is simple: patch velocity wins. The organizations that shrink the window between disclosure and remediation are the ones that do not become breach headlines.

Patch Tuesday: Microsoft’s Predictable Cadence

“Patch Tuesday” is the informal name for Microsoft’s monthly security update release, which lands on the second Tuesday of every month. Microsoft adopted this predictable rhythm so that administrators could plan maintenance windows around a known date rather than reacting to a chaotic stream of one-off fixes. Updates are delivered through Windows Update, the Microsoft Update Catalog, Windows Server Update Services (WSUS), and modern cloud tooling like Microsoft Intune and Windows Autopatch.

Each release is documented in Microsoft’s Security Update Guide, which lists every CVE addressed that month along with severity ratings, affected products, and an “Exploitation” assessment indicating whether Microsoft has observed the flaw being used in attacks or considers exploitation more likely. A single Patch Tuesday routinely addresses dozens of vulnerabilities spanning the Windows kernel, the graphics subsystem, networking stacks, Office, Edge, and server roles like Exchange and SharePoint.

Two categories deserve special attention on any given Patch Tuesday. The first is the zero-day — a vulnerability that was already being exploited (or publicly disclosed) before a fix existed. When Microsoft flags a bug as “Exploitation Detected,” it is telling you a hacker got there first. The second is the critical remote code execution (RCE) flaw, which can hand an attacker control of a machine, sometimes with little or no user interaction. Between the two, these are the items that should never wait for the next quarterly maintenance cycle.

The cadence is a gift and a trap. It is a gift because predictability lets you build repeatable process. It is a trap because attackers know the schedule too. The moment a patch ships, threat actors begin reverse-engineering it to build working exploits for everyone who has not yet applied it — a practice sometimes called “patch-gapping.” The clock starts the instant Microsoft publishes.

What It Means When a Windows CVE Lands in CISA’s KEV Catalog

The Cybersecurity and Infrastructure Security Agency (CISA) maintains the Known Exploited Vulnerabilities (KEV) catalog: an authoritative, continuously updated list of vulnerabilities for which CISA has reliable evidence of active, in-the-wild exploitation. Not every scary-sounding CVE makes the list. Inclusion requires three things: the vulnerability has a CVE ID, there is reliable evidence it is being actively exploited, and there is a clear remediation action (usually “apply the vendor patch”).

When a Windows CVE lands in KEV, the signal is unambiguous: this is not hypothetical. Someone is using this bug right now to compromise real systems. KEV strips away the guesswork of CVSS-score triage — a flaw with a modest score can still be devastating if attackers have operationalized it, and KEV tells you exactly which ones they have. For defenders, KEV is arguably the single most valuable public feed for prioritizing patch management, because it answers the only question that matters in the moment: is this being exploited?

KEV also carries the weight of federal policy, and that policy just changed in a way every defender should understand.

From BOD 22-01 to BOD 26-04: Risk-Based Prioritization

For several years, CISA’s Binding Operational Directive (BOD) 22-01, issued in November 2021, drove KEV’s operational role. It required federal civilian executive branch agencies to remediate every KEV-listed vulnerability by a specific due date CISA assigned to each entry. It was a flat, KEV-driven mandate: if it is on the list, patch it by the deadline.

As of June 10, 2026, CISA replaced that model. BOD 26-04, “Prioritizing Security Updates Based on Risk,” revokes and replaces BOD 22-01 (along with the older BOD 19-02) and introduces a risk-based prioritization framework. Instead of treating KEV membership as the sole trigger, BOD 26-04 evaluates each vulnerability across four factors:

  • Asset exposure — is the affected system publicly reachable?
  • KEV status — is it on the Known Exploited Vulnerabilities catalog?
  • Exploit automation — can adversaries automate exploitation at scale?
  • Technical impact — would exploitation grant partial or total control of the system?

The combination of those factors maps to tiered remediation timeframes — the highest-risk vulnerabilities (publicly exposed, on KEV, automatable, and enabling total system control) demand action within days, while lower-risk combinations get longer windows, down to “fix on system upgrade” for the least urgent. In the highest-risk scenarios, agencies are also directed to determine whether an asset was already compromised before simply patching over it.

The critical takeaway for the private sector: the KEV catalog is not going away — it remains central, but it is now one input in a smarter risk calculation rather than a flat checklist. BOD 26-04 is binding only on federal agencies, but like its predecessor it functions as a de facto national standard. If you want a defensible, modern patch-prioritization model, CISA just published one. Treat KEV membership plus internet exposure as your “drop everything” signal, and use the four-factor logic to sequence the rest of your remediation queue.

The Bug Classes Attackers Exploit Most

Actively exploited Windows vulnerabilities cluster around a handful of recurring bug classes. Understanding them helps you reason about risk even before a CVE hits KEV.

Privilege Escalation (Elevation of Privilege)

Privilege escalation, or elevation of privilege (EoP), lets an attacker who already has a foothold — say, code running as a standard user after a phishing lure — jump to SYSTEM or administrator rights. EoP bugs rarely make flashy headlines on their own because they are not the initial breach; they are the second move. But they are indispensable to a real intrusion. Ransomware crews in particular love EoP zero-days: once they can execute code on one endpoint, a privilege-escalation exploit lets them disable defenses, move laterally, and deploy their payload domain-wide.

A textbook example is CVE-2025-29824, a use-after-free vulnerability in the Windows Common Log File System (CLFS) driver (CVSS 7.8). It allows a local, authenticated attacker to elevate privileges — and it was exploited in the wild before its patch, earning a place in the KEV catalog with a remediation due date of April 29, 2025. The CLFS driver has been a repeat offender for privilege-escalation bugs, which is exactly why kernel-mode drivers deserve heightened patch scrutiny.

More recently, CVE-2025-62221, a use-after-free in the Windows Cloud Files Mini Filter Driver (CVSS 7.8), was added to KEV with a due date of December 30, 2025. Like the CLFS flaw, it is a local elevation-of-privilege issue in a low-level driver — the kind of bug that turns a limited compromise into full control of an endpoint.

Remote Code Execution (RCE)

Remote code execution is the crown jewel for a threat actor: the ability to run arbitrary code on a target, often over the network and sometimes without any user interaction. RCE flaws in internet-facing Windows services (think Exchange, RDP gateways, or SMB) can be wormable, meaning one compromise can cascade across an entire network. Even RCE that requires a user to open a document is dangerous, because a convincing phishing email closes that gap easily.

CVE-2023-36884, the Microsoft Office and Windows HTML Remote Code Execution Vulnerability (CVSS 7.5), is a well-documented case. It was exploited as a zero-day by the threat actor Microsoft tracks as Storm-0978 (also known for RomCom) against targets including government and defense organizations, delivered through malicious documents. It was added to CISA’s KEV catalog with a due date of August 29, 2023. The lesson: an “RCE that needs user interaction” is not a safe RCE when your users receive email.

The Pattern Behind the Patterns

Kernel drivers, file-system filters, scripting hosts, document parsers, and network-facing services show up over and over. The common thread is attack surface — code that either runs with high privilege or accepts untrusted input. When you triage a Patch Tuesday release, weight those components heavily even before checking KEV. And when one of them does appear in KEV, treat it as an active incident-prevention deadline, not a routine maintenance item.

Building a Patch Program for Windows Fleets

Knowing which vulnerabilities matter is half the battle. The other half is operational: getting patches onto every endpoint quickly, safely, and verifiably. Here is a practical blueprint for a Windows patch management program built around patch velocity.

1. Inventory and Own Your Attack Surface

You cannot patch what you cannot see. The foundation of any patch program is an accurate, continuously updated asset inventory: every workstation, server, laptop, and virtual machine, tagged by role, exposure (internet-facing vs. internal), and business criticality. Unmanaged endpoints — the contractor’s laptop, the forgotten lab server — are where breaches begin. BOD 26-04’s emphasis on tagging and identifying exposed assets is a direct acknowledgment that visibility is prerequisite to prioritization.

2. Prioritize with KEV and Exposure First

Adopt CISA’s risk logic. Your prioritization queue should sort by:

  1. KEV-listed AND internet-exposed — emergency. Patch within days, out of band if necessary.
  2. KEV-listed internal, or critical RCE/EoP flagged “Exploitation More Likely” by Microsoft — expedited, within your shortest routine window.
  3. Everything else — standard monthly cadence.

Subscribe to the KEV catalog feed and Microsoft’s Security Update Guide, and cross-reference every Patch Tuesday against KEV automatically. This single practice — letting active exploitation drive urgency — is the highest-leverage change most organizations can make to their remediation process.

3. Choose the Right Deployment Tooling

Match tooling to your environment:

  • Microsoft Intune — the modern choice for cloud-managed and hybrid endpoints, with update rings, deadline-driven enforcement, and reporting. Ideal for distributed and remote workforces.
  • Windows Autopatch — automates the deployment of Windows, Office, Edge, and driver updates across rings with built-in rollout and rollback, reducing manual effort for eligible fleets.
  • WSUS — the long-standing on-premises option for approving and distributing updates, still common in server-heavy and air-gapped environments. (Note that Microsoft has signaled WSUS is on a deprecation path, so plan a migration to cloud-based management over time.)
  • Third-party patch management platforms — useful when you must also patch non-Microsoft software, which is a frequent blind spot and a favorite attacker entry point.

Whatever you choose, the goal is enforceable deadlines, not optional prompts. A patch that users can indefinitely postpone is not deployed.

4. Use Testing Rings to Balance Speed and Stability

The classic objection to fast patching is “what if the update breaks something?” The answer is deployment rings — a staged rollout that catches regressions before they hit the whole fleet:

  • Ring 0 – Pilot/Canary: IT staff and a small, representative set of endpoints. Deploy within a day of release.
  • Ring 1 – Early adopters: a broader slice (roughly 5–10%) across departments and hardware types. A few days later.
  • Ring 2 – Broad deployment: the general population, with enforced deadlines.
  • Ring 3 – Critical/sensitive systems: production servers and high-availability assets, patched last but still within your risk-based window, after validation.

Rings let you move fast on the majority while protecting fragile systems — and they give you an early-warning tripwire if a patch causes problems. Crucially, for a KEV-listed, actively exploited flaw, you compress or bypass the ring schedule. The risk of a regression is almost always smaller than the risk of an active exploit.

5. Verify, Report, and Close the Loop

Deployment is not remediation until it is confirmed. Use your tooling’s compliance reporting to verify installation on every targeted endpoint, chase down failures, and track your mean time to remediate (MTTR) as a core metric. Reboots matter too: many Windows patches are not fully effective until the machine restarts, so enforce reboot deadlines. Feed unpatched or unreachable assets back into your inventory process as exceptions that require a human decision, not silent gaps.

6. Plan for Emergencies and Compensating Controls

Some months bring out-of-band patches or KEV additions that cannot wait for Patch Tuesday. Have a documented emergency patch process with pre-approved authority to deploy out of cycle. When a patch genuinely cannot be applied immediately — legacy application dependencies, for example — deploy compensating controls: network segmentation to shrink the attack surface, disabling the vulnerable feature, tightening firewall rules, and increasing endpoint detection monitoring on the exposed systems. Compensating controls buy time; they do not replace the patch.

Why Patch Velocity Wins

Attackers operationalize exploits in days, sometimes hours, after a patch drops. Threat intelligence repeatedly shows that a large share of successful intrusions exploit vulnerabilities for which a patch had been available for weeks, months, or even years. The vulnerability itself is rarely the failure — the failure is the unremediated window.

Patch velocity — the speed at which your organization moves from disclosure to verified remediation across the fleet — is therefore one of the most measurable and defensible security metrics you have. It is not about patching everything the instant it ships; BOD 26-04 makes clear that intelligent prioritization beats indiscriminate urgency. It is about closing the doors that attackers are actively walking through, fast, and closing the rest on a disciplined schedule. An organization that can demonstrate a tight, KEV-driven remediation window has removed the single most common precondition for a preventable breach.

The math favors the defender who moves. Every day you shave off your remediation window is a day of exposure you deny to every threat actor scanning for that flaw.

Conclusion

Patch Tuesday is predictable. The KEV catalog tells you what is actually being exploited. BOD 26-04 gives you a modern, risk-based framework for deciding what to fix first. The pieces of a strong vulnerability management program are all on the table — the differentiator is execution. Inventory your attack surface, let active exploitation drive your priorities, deploy through rings with enforced deadlines, verify remediation, and treat KEV-listed, internet-exposed flaws as the emergencies they are.

If your team is stretched thin, patch velocity is exactly the kind of discipline that benefits from a dedicated partner. Honeybadger Solutions LLC — a Service-Disabled Veteran-Owned Small Business providing cybersecurity, digital forensics, incident response, and private investigations — helps organizations build and run vulnerability management and endpoint security programs that keep pace with active threats. Whether you need to stand up a Windows patch program, tighten your remediation timelines, or assess your exposure before an attacker does, we can help you close the window that intrusions depend on. Reach out to start the conversation.

About Honeybadger Solutions

Honeybadger Solutions LLC is a Service-Disabled Veteran-Owned Small Business (SDVOSB) delivering cybersecurity, digital forensics, and investigative services to clients nationwide. Whether you are dealing with a compromised device, a suspected intrusion, or you simply want to get ahead of these threats, our team can help.

What we do:

  • Digital forensics — mobile devices (iPhone, Android) and computers (Windows, macOS, Linux); intrusion reconstruction, evidence preservation, and expert-witness reporting
  • Cybersecurity & incident response — breach investigation, containment, malware and spyware analysis, and remediation
  • Penetration testing & security assessments — finding the gaps before an attacker does
  • Managed IT & endpoint security — hardening, monitoring, and patch management for small and mid-sized organizations
  • Private investigations — including TSCM / technical surveillance countermeasures (“bug sweeps”)
  • Executive & personal protection

📞 (602) 725-2818 · 🌐 honeybadgersolution.com · Veteran-Owned (SDVOSB) · Licensed & Insured

Concerned a device or network may already be compromised? Contact Honeybadger Solutions for a confidential consultation — we handle mobile and computer forensics, incident response, and everything above.

Related from the Honeybadger Windows computer-security series

Part of Honeybadger Solutions’ security-intelligence series. Explore the rest of the Windows coverage:

Sources