Another analysis of fake CVEs: https://x.com/JFrogSecurity/status/2082473593770782753

MITRE apparently takes a CVE from anybody at any time, without any kind of validation. But boy do they require validation to get one taken down!

Fwiw that combined with mass llm nonsense is a major reason several high profile projects recently became CNAs (curl in 2024, rust in 2025, the Linux kernel in 2026, I’m sure there are others).

Yup. Yet another sign that MITRE needs to use a validation process on CVEs before publishing them. Obviously, MITRE doesn't have the equipment to reproduce the problem reported, but the fake reports themselves have things in common which should raise red flags.

It's rather annoying that a few CVEs against SQLite have been valid. But the advantages of opting out are increasingly apparent.

What is a CNA? Not a Certified Nursing Assistant, to be sure. Computer Network Attack? Nah. My internet search-fu fails me.

CVE Numbering Authority, i.e. "we police our own CVEs".

Hey hey,

out of curiousity, did MITRE reach out to SQLite regarding these (as would have been required by CNA rules)?

No. MITRE did not make any attempt to contact the SQLite devs.

Note, however, that as a result of all the pushback from multiple sources (not from SQLite - they ignore what we say), the fake CVEs have been taken down now.

In case you want to explore that option, https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/guides/becoming-a-cna-as-an-open-source-org-or-project.md documents becoming a CNA. It is a somewhat involved process but would put CVE assignment for sqlite entirely under SQLite’s remit.

Yikes, that's a lot of process. I think I have enough process in my life already without having also deal with the CVE bureaucracy.

Yep, sadly I’m not sure there is an other way to get control over CVE allocation.

If you have close / friendly contacts at redhat using them to get in touch with their CNA people and chatting with them might surface other options (redhat is a CNA, a root, and a CNA of last resort so they are very experienced with all that) but I don’t know that they would allow third parties influence over allocation save through becoming CNAs as that is the “correct” process.

For what it’s worth, having worked not too far from people who handled that at a company which was a CNA it felt like getting certified is a chore and a half but once that’s done the overhead is pretty low. I don’t have direct experience with it though so ymmv.

Maybe some one should create a CVE about the vulnerability in the CVE system of it not properly checking its inputs and being able to output incorrect (and potentially dangerous) results.

Generated by a general-purpose LLM and including a detailed analysis of MITRE's hallucinated source code, of course.

I'm involved in another project which attracts CVEs, many of which are based on incorrect facts or reasoning.

Simplified description, leaving out details:

MITRE is a US not-for-profit organisation. It handles CVEs more as a librarian than as a participant. It doesn't originate them, it doesn't vet them, it doesn't check them out. It doesn't even supply the numbers for them: that's done by various CVA Numbering Authorities (CNAs). The most it does – rarely – is spot duplicates and either merge two reports together, or tell whoever reported the second one their report is a duplicate.

Because of this, MITRE doesn't care whether CVEs are accurate, convincing, or even plausible. It's like a newspaper of record: "So-and-so said something.". It doesn't care whether 'something' is true.

So in a normal situation, you don't complain to MITRE. You complain to whoever made the report. As you can imagine, a big corporation like Oracle will afford to devote money and personnel to keeping its reputation free of CVEs. The SQLite development team cannot.

If someone came up with a good – funded – replacement for CVEs, it could be a success. But it would be a boring, thankless task for anyone not interested in vulnerabilities. And the people who are most interested in vulnerabilities are the ones who want to exploit them.

This isn't quite correct. MITRE wears multiple hat in the CVE program (which is part of the problem):

• MITRE is (effectively) tasked with running the program through their Secretariat role
• They are the Root CNA for pretty much any non-US-government CNA & CNA-LR for that tree
• They are also just performing normal CVD tasks as a normal CNA

In this particular case the CVEs were assigned by MITRE in their "normal CNA" role, this is not MITRE in a "librarian" role. As such, in these cases, they are indeed responsible for correctness of the CVE records they publish & communication with the supplier, as per CNA rules.

Unfortunately MITRE is... not very good at this role. I don't even mean this specific case, but in general.

For example: MITRE in general (for at least some of their reporting flows) fails to set the Affected fields in the CNA container to anything useful, instead setting it as n/a. The need to do this comes from this being a required field.

Another example: For years MITRE CVE records contained hallucinated reference links for vendors/products - sometimes correct, sometimes non-existent, sometimes pointing to an existing but completely unrelated domain. These were not provided by the original reporters, to the best of my knowledge, but added by MITRE in their CNA role. I'm currently still chasing some because MITRE couldn't be bothered to clean up the unpublished records for any such occurrences, they just cleaned up the ones I found & told them about.