How to use CVE/CNA at Eclipse to declare specific versions of Eclipes Jetty as EOL

How can we use the Eclipse CNA authority to declare specific versions of Eclipse Jetty as EOL?

Steps to reproduce

The CNA authority has the means to declare specific versions of products as EOL. We would like to use this ability of a CNA authority for older, no longer supported, Eclipse Jetty versions.

What are the affected versions?

Eclipse Jetty 11 and older. (Jetty 11., Jetty 10., Jetty 9., Jetty 8., Jetty 7.*) But NOT Jetty 12 (which is the mainline and supported version of Jetty)

Do you know any mitigations of the issue?

Please add Jesse McConnell @jmcconnell to this issue.

made the issue visible to everyone

assigned to @jmcconnell

made the issue confidential

As far as I know, there is no way to assign the whole product EOL in the CVE programme. What is possible is to assign "Unsupported when Assigned" tag to a specific CVE stating that it is an unsupported product. Then it is implicit that there's no fix and the analysis might be more lightweight, basically checking if the report makes sense. See more information in the CNA EOL process https://www.cve.org/Resources/General/End-of-Life-EOL-Assignment-Process.pdf

What some project do, is to assign a high severity CVE to each unsupported version, so that it shows up in scanners. This is not an official method. We could talk about doing this if it makes sense for Projects.

What do you think?

I would assume that Spring and other projects have a way to clearly communicate that open-source projects no longer support release lines. Commercial support may be available, of course, but we are looking for the best way to fully communicate that open-source project support has ceased.

@jerdfelt How does Spring do this? Is updating metadata like that EOL GitHub project enough?

@mrybczyn Is there a standard, non-bespoke way to leverage the CVE authority to communicate EOL clearly yet still provide for the possibility that commercial support may prompt another release on that EOL release line? Reading through your PDF I get the impression this would be for a release line that will NEVER be supported again, maybe like Jetty 7 or Jetty 8..

What is possible is to assign "Unsupported when Assigned" tag to a specific CVE stating that it is an unsupported product.

What is the scope of this "Unsupported when Assigned" tag?
Is it for the whole CVE, and all tagged as fixed/addressed-in versions on that CVE?
Or is the tag assigned to specific versions (or version ranges) on that CVE?

It is for tagging that specific CVE as being assigned to an unsupported version, so it doesn't work with an issue that is in both supported and unsupported versions.

The tag implicitly says that there's no fix and will be none.

Is it more clear?

Here's more links to other documents about CVE/CNA and EOL.

• https://cve.mitre.org/cve/cna/CVE_Program_EOL_Policy_v1-1.pdf
• https://cve.mitre.org/cve/cna/CVE_Program_End_of_Life_EOL_Assignment_Process.html
• https://cve.mitre.org/cve/cna/CVE_Program_End_of_Life_EOL_Assignment_Process_v1-1.pdf

Unfortunately, these don't add much to understanding of "how" to do it.

node.js did some EOL CVEs.
Perhaps we can learn from what they did.

• https://www.cve.org/CVERecord?id=CVE-2025-23088 - EOL version 19.9.0
• https://www.cve.org/CVERecord?id=CVE-2025-23089 - EOL version 21.7.3

Agreed, we could certainly emulate Node's approach. It could serve as a valid workaround until we have a more robust solution.

FYI, 've also initiated a discussion on the OpenSSF's slack to gauge if there are any ongoing efforts specifically aimed at establishing a registry of EOL packages. My comments pasted below for convenience:

The CWE used here is somewhat of a workaround, as it’s meant to describe EOL third-party components within Node rather than Node itself. Still, it might be sufficient. That said, has anyone come across discussions about creating something similar to https://github.com/ossf/malicious-packages but specifically for EOL packages? Publishing this information in OSV format would allow scanners to easily flag EOL packages and clearly indicate the reason; much like how malicious packages are handled.

I note that I have memories of such EOL CVEs issued earlier.

Do we have any contacts at groups that use the CVE/Mitre data for auditing reasons (qualsys, blackduck, etc) that we can ask how / where they consume this kind of metadata?

@jmcconnell how about we experiment with some of these ideas on Eclipse Jetty 7.x? (a low risk version)

sounds reasonable

btw, I don't think this specific issue needs to be confidential.

I agree, other projects may have their opinion on the subject.

I'm removing the confidentiality tag.

made the issue visible to everyone

The question about using CVEs for EoL version is there in the CVE user survey that you can link from https://www.cve.org/Media/News/item/blog/2025/03/04/CVE-Data-Usage-and-Satisfaction-Survey

@jerdfelt @jmcconnell you may want to fill it to have your say

Done. Thanks for the link.