Your scanner found 228 CVEs for Thunderbird. There are 1,830

A question first. If a vulnerability scanner tells you your Thunderbird has 228 known CVEs in its history, does that sound like a complete answer?

It did to us, for a while.

Some background

Every piece of software in the CVE ecosystem gets a CPE identifier, which is basically vendor plus product name: mozilla:thunderbird, apache:tomcat and so on. Scanners use these names to ask “which CVEs affect this thing”. Simple enough.

The part nobody tells you is that the official CPE dictionary sometimes has more than one name for the same product. Thunderbird has two: mozilla:thunderbird and mozilla:thunderbird_esr. Firefox also has two.

Both names are legitimate, both appear in real CVE records. From what we can see in the data, thunderbird_esr was used mainly in the ESR 10 and 17 era, around 2012 and 2013, and then the analysts mostly went back to filing everything under plain thunderbird, modern ESR releases included. Nobody deprecated the old name. It just sits there in the dictionary, valid, with its own little pile of CVEs attached.

The measurement

We ran into this on a customer tenant where a Thunderbird install had been identified as thunderbird_esr. A correct identification, mind you, it really was the ESR edition. The scan result looked suspiciously clean, so we went to measure how the CVEs are actually distributed between the two names.

Straight against the public NVD API, on August 15, 2026:

curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:mozilla:thunderbird&resultsPerPage=1" \
  | grep -o '"totalResults":[0-9]*'

curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:mozilla:thunderbird_esr&resultsPerPage=1" \
  | grep -o '"totalResults":[0-9]*'

1,830 under thunderbird. 228 under thunderbird_esr. We ran the same for Firefox: 3,285 against 490.

One technical note if you want to repeat this: virtualMatchString compares the product field by exact value, so the thunderbird count does not include the _esr one. The split is clean.

Sit with those numbers for a second. A tool that looks up CVEs under thunderbird_esr only, because that is the name it assigned, sees 228 entries and essentially nothing recent. The other 1,800, including basically all modern ones, are filed under a name it never queries.

The report it produces is not even wrong in any way you could point at. Every single lookup it did was correct.

A known problem

We did not discover some secret flaw here, to be clear. CPE naming inconsistency is a known and studied problem, there is academic work analyzing it as a primary source of false negatives in vulnerability matching, and the most quoted example in the literature is apache versus apache_software_foundation.

We had already been bitten by python versus python_software_foundation and by the jdk, jre, openjdk triangle before Thunderbird came along. Each time the lesson is the same: the names are data about filing habits, not about software identity, and whoever consumes them has to carry a map of which names belong together, with version ranges still checked on every entry.

Our map is a curated table of these equivalences, and every row in it got there the way this one did, from a measurement like the query above.

Which is also my practical suggestion if you are evaluating any scanner, ours included: ask the vendor how it handles thunderbird_esr, then ask how the answer was verified. The second question is where the conversation gets interesting.