M37

Every vulnerability the U.S. government listed as exploited in August 2026

This is the material behind the video. Each row is one vulnerability with every layer of the public record beside it: what CISA’s catalogue says, what the CVE record says, and what the model that estimates exploitation said the day before the listing and again afterwards. Every value is what one of those records states, and where a record states nothing the cell says so instead of showing a zero.

Harvested 2026-09-01 from catalogue version 2026.09.01, which held 1,687 entries in total.

The numbers in the video

How this was put together

Every entry CISA added to its Known Exploited Vulnerabilities catalogue with a date in August 2026 was taken from the catalogue's own JSON feed. For each one we asked FIRST's EPSS API twice, once for the score published on the day before CISA listed it and once for the score on 1 September 2026, and we asked the NVD for the CVE record's severity rating, weakness type, publication date and references. Nothing below was retyped from a screen. The table is generated from the stored responses, and the numbers in the video come out of the same file. Each row also links the vendor advisories the catalogue lists in its own notes field, with CISA's directive links filtered out because they sit on nearly every entry. All 78 distinct advisory links were fetched on the day this was put together and every one of them answered.

The catalogue itself is at cisa.gov/known-exploited-vulnerabilities-catalog, and it is updated on CISA’s own schedule, so a row below can look different there later.

What these numbers cannot tell you

• A CVSS base score is a severity rating, not a prediction and not a risk score.
• 22 of these rows carry a CVSS 3.1 base score and 9 carry a CVSS 4.0 base score. They are not necessarily on one scale.
• EPSS estimates the probability of observed exploitation activity over a forward window. A low score followed by a KEV listing is not by itself an error, because exploitation is rare and a calibrated model has to give low probabilities to almost everything.
• The 'day before' column is the last EPSS score computed before the listing was public. Where it is absent, the CVE record had not been published yet, so no score existed.
• The 'now' column was read after every one of these was public, so it is not a forecast of anything. It is what the model says today about a vulnerability already known to be exploited.
• CISA lists a vulnerability on evidence of exploitation. The catalogue does not say whose evidence, or who was affected.
• The ransomware column reads Unknown for all 31 entries. That is a published field left empty, not a finding.
• Nothing on this page is computed. Every value is what a record stated, and an absence is shown as absent rather than as a zero.

What we could not get

• Who was affected. CISA lists a vulnerability on evidence that it is being exploited and does not publish the evidence, the target, or the reporter. No column here can tell you who was hit or how many.
• Company disclosures. We searched the SEC's EDGAR full-text index for 8-K filings citing Item 1.05, the cybersecurity incident item, across the whole of August 2026. Three documents came back and one of them was actually filed under that item; the other two carry the phrase inside an attached exhibit. Most organisations running this software never file with the SEC, and a company that does file can disclose under a different item, so that count describes the filing record and says nothing about how many incidents there were.

The month, row by row

31 vulnerabilities, one row each. You can sort by any column heading, and the box below narrows the table to rows containing a word you type. Opening a row shows the catalogue’s own name for it, the weakness type, when the CVE record was published, the deadline it carries, and every advisory the catalogue points at.

Both EPSS columns hold the probability the model published, between 0 and 1. The left one is the last score computed before the listing was public and the right one was read on 2026-09-01, after every entry here was already known to be exploited.

Ask us to make one of these

Most of the work behind this video was reading a public record carefully and checking what it does and does not support. If your organisation keeps a record like that, a catalogue, a register, a filing history, a dataset you publish, we can build the same kind of explainer out of it, with the working shown on a page like this one.

Tell us which record and what you would want somebody to understand at the end of it. We read everything and we answer, including when the answer is no. If we take something on, the method is written down before the work starts and published with the result, whichever way the result goes.