There is a public list of software flaws being used against people in the wild — not theoretical vulnerabilities, but ones with evidence of active exploitation.
The list's contents might surprise you. They do not quite fit the image that "actively exploited" brings to mind.
What the list is
The US cyber-defence agency publishes a catalogue of known exploited vulnerabilities. Getting on it takes evidence that the flaw is being used, and each entry carries a date it was added and a date by which federal agencies must fix it.
Everyone else can read it too, and most people should. It is the closest thing available to a ranked answer to "what should I patch first", and it is free.
We took the published feed and computed over it. 1,665 entries, running from November 2021 to the day we measured.
The number that reframes it
A CVE identifier carries the year the flaw was first reserved, so comparing that with the date it entered the catalogue gives you how long it had been public before anyone recorded it being exploited.
The median is 1 year. Only 42.6 per cent were added in the same year they were identified.
And 365 of them — 21.9 per cent — were 5 years old or more. The oldest entry was a full 20 years old, a flaw from 2002 that was added to the catalogue in 2022.
What that means for what you do on Monday
The phrase "actively exploited" usually brings zero-days to mind — vulnerabilities unknown until they were used. But that describes only a minority of this list.
The majority describes something less dramatic and much more actionable. A flaw was found, a patch was published, and years later attackers were still getting in with it — because the patch had not been applied.
This inverts the usual anxiety. Instead of asking whether you can respond fast enough to a brand-new threat, the real question is whether that thing you did not get around to patching in 2021 is still running.
That is a much easier problem, and a much duller one, which may be why it stays unsolved.
The deadlines are not one deadline
Every entry carries a date by which US federal agencies must remediate it. Those windows are published in the data, so we measured them rather than reading the policy.
The median is 21 days, and 1,025 entries sit exactly there. But the range runs from 1 day to 184, and 112 entries — 6.7 per cent — are given a week or less.
The catalogue is not a flat list; it carries an urgency signal. A one-day deadline is the agency flagging something quite specific about a particular flaw, which makes that field the most important one for prioritising.
Two more things the data says plainly
339 entries — 20.4 per cent — are flagged as having known ransomware use. One in five of the flaws actually being exploited has been part of a ransomware campaign, which is a useful corrective to treating ransomware as a separate category of problem. It arrives through the same unpatched doors.
The catalogue is also concentrated, with Microsoft alone accounting for 383 entries, 23 per cent of the total. That is not a claim about Microsoft's security relative to anyone else's — it substantially reflects how much Microsoft software exists to attack. But if you have a limited patching budget, the data shows the distribution is not uniform, and that tells you where to focus.
Use the catalogue against your own inventory, not as a news feed. It is free, machine-readable, and the best ranked answer we have to "what should I patch first". When you do, sort by the remediation window rather than the date added; the 112 entries carrying a deadline of a week or less are the top of the list, and one carries a single day. Check your oldest systems before your newest, because the median flaw here was a year old when it was declared exploited, one in five was at least five years old, and the oldest was twenty. And treat ransomware as a consequence rather than a category: one in five entries has known ransomware use, arriving through the same unpatched software as everything else.
Working with it yourself
The script is committed with this guide and computes everything above from the feed, so you can re-run it against a current snapshot and get current numbers. Our KEV deadline calculator works out the remediation date for a given entry in working days, which is the form the deadline actually takes for a team. For the related arithmetic, which hash for what covers the cryptography that shows up repeatedly in these entries, and your bank is not one domain measures the other end of the same problem — the defences organisations publish about themselves.
- Every figure is computed by a script committed alongside this guide from CISA's public Known Exploited Vulnerabilities feed. No policy text is quoted or reproduced: the remediation windows are measured from the dates in the data rather than read from the directive that sets them.
- ⚠️ THE CATALOGUE IS A SNAPSHOT and changes most weeks. The catalogue version and release date are recorded in the committed facts file so every figure here can be reproduced against the same snapshot rather than a moving target.
- ⚠️ "KNOWN EXPLOITED" IS NOT "EXPLOITED EVERYWHERE". An entry means reliable evidence of exploitation exists. It does not mean every unpatched system was compromised, and nothing here should be read as a probability that any particular system was hit.
- ⚠️ THE AGE FIGURE IS A LOWER BOUND. A CVE identifier carries the year it was reserved, so the gap between that and the date added understates how long the flaw was publicly known rather than inflating it. The real gap is at least this large.
- ⚠️ THE VENDOR DISTRIBUTION IS NOT A SECURITY RANKING. Microsoft's share substantially reflects how much Microsoft software exists to attack. Reading the count as a comparison between vendors' engineering would be unsupported by this data.
- ⚠️ THE REMEDIATION DEADLINES BIND US FEDERAL AGENCIES, not you. They are used here as a published urgency signal, which is what makes them useful to everyone else — not as an obligation anyone outside that scope is under.
This describes what one public catalogue contains, computed from its own feed. It is not a vulnerability assessment of any system, not advice about a specific product, and not a substitute for knowing what software you actually run.
View author profile → · Editorial policy
