What actually lands on a release line after it goes end of life

The finding

The number that matters is not the total. It is the gap between two rows of the same table. RabbitMQ 3.12 and 3.13 have accumulated no CVE records since their end-of-life dates. Erlang/OTP — the runtime every RabbitMQ node executes on — has accumulated twenty-two against its 24 line alone, including CVE-2025-32433 at CVSS 10.0.

Most vulnerability management treats the broker as the unit of risk. It fingerprints the RabbitMQ version, finds nothing outstanding, and moves on. The advisories are one layer down — in the TLS implementation, the SSH application, the crypto libraries and the standard library the broker calls into — and a scanner that reports on the application rarely reports on the runtime beneath it.

This is not a RabbitMQ-specific problem. It is the general shape of the thing: risk accumulates fastest in the layer nobody has assigned an owner to.

The data

End-of-life dates from each project's published lifecycle or endoflife.date. CVE data from NVD, retrieved September 2026.

Method

1. Retrieve every CVE registered against each product's own CPE from the NVD 2.0 API, paginated to completion. Not a keyword search: keyword matching returns advisories for unrelated software that merely mention the product, which is the most common way this kind of analysis goes wrong.
2. Discard records NVD marks rejected, and records carrying no CVSS base score.
3. For each release line with a citable community end-of-life date, keep the records published after that date whose structured CPE version range still includes the line. Platform CPEs — the Debian and Red Hat entries riding along on many records — are filtered out, because they describe the distribution rather than the software.
4. Report the count, how many scored 7.0 or above, and the highest score. Every CVE identifier behind every figure is listed below.

The retrieval and analysis scripts are published in the site repository so the study can be reproduced rather than taken on trust.

Limitations, stated plainly

These are counts of CVE records. They are not counts of defects, and they are certainly not measures of exploitability. Three things follow, and they cut against the headline as much as for it.

• A low count is not a clean bill of health. Projects differ in how consistently they request CVEs and how completely CPE data is assigned. Some fix issues quietly. RabbitMQ's zero should be read as “no records in NVD”, not as “no vulnerabilities”.
• CVSS is a severity estimate, not a risk assessment. A 10.0 in a component you do not expose is less urgent than a 6.5 on your edge.
• The set is small because the dates are. Only lines with a citable end-of-life date can be measured. Apache Kafka and Apache ActiveMQ publish no per-line EOL dates at all, so they cannot appear here — which is its own kind of problem for anyone trying to plan.

We sell extended support for several of the products measured here, so treat the framing with appropriate suspicion and check the numbers. That is what the method section and the identifier list are for.

Every identifier behind the counts