A model invented 31 CVE numbers in our data. Here’s the list and the fix.

What we found

We checked every CVE number we’d ever published against the official NVD database, and against MITRE for anything NVD didn’t have. That’s 151 unique IDs across our briefings and weekly reports.

120 were real. 31 were not. Those 31 identifiers had never been assigned to anything. They simply didn’t exist.

And they weren’t scattered. They came in neat sequential runs: CVE-2026-45201 through 45204, CVE-2026-51847 through 51850, and a cluster in the CVE-2026-2284x range. One detail from that last run is worth pausing on – CVE-2026-22844, sitting right in the middle of the invented ones, is a real CVE. The model had bracketed a genuine identifier with fabricated ones. That is exactly why eyeballing the format doesn’t work.

The full list

Here is every one of the 31, grouped by the weekly report it appeared in. This list is generated directly from our public withdrawal data – if a number is here, it is gone from the live site.

Why it happened

All 31 traced back to the same early version of our pipeline, before we added a rule that every CVE number has to match a real source record instead of being written as part of the summary.

The sequential runs are the fingerprint of a language model inventing things that look correct. When you ask a model to summarize vulnerability activity without forcing each ID to tie back to a verified record, it produces numbers that look plausible. Right format, sensible year, tidy sequence. None of them pointed to a real vulnerability. It was confident, well formatted fiction. The one piece of good news is that none of these reached our actual daily briefings, which already pulled from verified feeds. They only lived in the older weekly-report path that came before the verification step.

What we did

Two things. One was cleanup, the other was a permanent fix.

For cleanup, we pulled every fake ID off the site. Of the 31, 26 had dedicated pages built for them; those now return a 410 Gone. The other 5 had only ever appeared inline in a single early weekly report, so they never had their own pages – each is now flagged in place in that archive. We stripped all 31 out of our public API, our feeds, and our sitemap. On the old archived reports we kept the pages but added a note next to each fake one saying the identifier couldn’t be verified against NVD, because deleting them quietly felt wrong.

For the permanent fix, we added a check that runs before anything publishes. If a CVE number isn’t in NVD and isn’t in CISA’s KEV list, it gets checked against MITRE. Anything confirmed fake gets pulled automatically and logged. If MITRE happens to be down, the check lets the content through rather than risk deleting something real, but everything now runs through one shared list so our pages, API, and sitemap can never disagree about which CVEs are real. The full method is on our methodology page.

Why we’re posting this

Two reasons. If you read AI-generated security content from anyone, us included, this is worth knowing about. A model naming a CVE is not proof the CVE exists. The format is easy to fake convincingly. If it matters, check the number against NVD or MITRE yourself, especially for older content from before a site had verification in place.

The other reason is that when you find something like this in your own data, the right move is to say so, show the list, and show the fix. The full list of all 31 is above; how our verification works is on our methodology page. Our data and which CVEs we actually track is in our open API.

If anyone wants to poke holes in the rest of our corpus, please do.