Every vulnerability CISA has confirmed used in a ransomware campaign, and what an exploit of it must do on the host. Mimic's ground is the enterprise server — and on that ground, most of these have an answer.
CISA maintains a catalog of vulnerabilities confirmed to have been exploited in the wild, including those confirmed used in ransomware campaigns. This page takes that set and asks a different question of it: not which vulnerability was used, but what an exploit of that class has to do on a host in order to succeed.
Tracking vulnerabilities individually produces a list that grows faster than anyone can remediate it. Tracking what exploits have to do produces a much shorter list, because the number of distinct actions is small even when the number of vulnerabilities is not. An exploit generally has to write something, load something, modify something, or elevate something. Those categories are stable even as the CVE list is not.
If the required actions are a short and stable list, they can be constrained directly. Known-good enforcement evaluates each attempted change against a verified baseline of the system's authorized state and blocks anything outside it at the kernel, before it executes. That decision does not require knowing which CVE is being exploited, whether a proof of concept has been published, or whether a vendor fix exists.
It is worth being precise about the limit. Enforcement constrains what an exploit can do on a protected host. It does not remove the vulnerability, and it is not a substitute for patching where patching is available.
Related reading: The Patch Window, The Server Threat Library, and Mimic Virtual Patching.
Records are drawn from the CISA Known Exploited Vulnerabilities catalog and its ransomware-campaign flag. The live view below is updated as CISA publishes.
Loading the catalog…
How these figures are made. An AI model reads CISA's description of each CVE, assigns it an exploitation class, and records the host actions that exploit cannot avoid — a process start, a file write, a connection, or none at all — judged against the description rather than copied from the class, with the clause that justifies any departure quoted on the row. The protection claim attaches to those actions — how a Mimic node would be configured against them — not to a test of the individual CVE. Columns marked with a sparkle are model-derived; expand any row to check the inference against the CISA record it came from.
Mimic doesn't judge an action suspicious. It profiles what a server actually does — the applications that matter and the resources they own — and can deny anything outside that profile. These are the controls an intrusion has to get past once the exploit has landed.
Hover a row's How Mimic protects cell to see how these apply to that entry. Decisions are made on image paths and baseline era — not hashes, signers, users or command lines — as policy committed to the kernel in advance rather than a verdict computed per event, so every denial is attributable to the rule that caused it.
Two things this does not say. It is not a per-CVE test: which actions an entry trips is read off CISA's description, and the explanatory text for a control is the same for every entry that trips it. And some entries trip none of these at the moment of exploitation — a file read, a process over-reading its own memory, or an exploit whose whole payoff stays inside the process. Those rows say so, with the reason.
Loading…
| CVE | Vendor / product | Exploitation class | What it must do next | Platform | How Mimic protects | Added |
|---|
Source: CISA's Known Exploited Vulnerabilities catalog, reproduced as published. The exploitation classes, the commentary, and every statement about Mimic on this page are ours alone. Mimic is not affiliated with, endorsed by, or sponsored by CISA or the US Department of Homeland Security, and nothing here should be read as CISA assessing, validating, or recommending any product. KEV is a floor rather than a ceiling — absence from it means "not yet proven and published", not "not exploited".