Clarify whether the state of being EoL is a vulnerability and can receive a CVE assignment

[zmanion]

This assignment documents that some versions of Node.js are EoL. It is my personal opinion and recommendation that being EoL is not a technical cybersecurity vulnerability that should receive a CVE ID assignment, but others may think differently. The decision should be documented in the CNA Operational Rules and probably also the End of Life Vulnerability Assignment Process documents.

https://www.cve.org/CVERecord?id=CVE-2025-23089

This CVE has been issued to inform users that they are using End-of-Life (EOL) versions of Node.js. These versions are no longer supported and do not receive updates, including security patches. The continued use of EOL versions may expose systems to potential security risks due to unaddressed software vulnerabilities or dependencies (CWE-1104: Use of Unmaintained Third-Party Components). Users are advised to upgrade to actively supported versions of Node.js to ensure continued security updates and support.

[todb]

Agreed - the mere fact of EOLness is not a vulnerability.

Also, producers routinely issue fixes for otherwise end-of-service software, sometimes begrudgingly, but often in the face of widespread exploitation.

CVEs for EOL software can depress this kind of emergency activity and will put users at risk, since it gives those producers and artificial "out."

[greg-hero]

My personal opinion:

1. Always better to have specific CVEs for specific vulnerabilities and have those CVEs tagged to all affected versions (even if some versions are EOL and will not be fixed by the author/creators). This should be the expectation and the standard though realistically it may not always be possible or pragmatic for some organizations.

2. I agree with Art/Tod that EOL-ness alone is not a vulnerability but we have seen multiple cases where even large organizations have resource-based policies/constraints that makes following (1) difficult. And in many cases these organizations do know that there are likely vulnerabilities in old versions. So which would be better, to have NO CVE on them (and leave package-consumers blind to the risks that would otherwise be flagged by SCA tools)? Or to have these sub-optimal, not-how-originally-intended CVEs? Like would EOL-ness + high risk/likelihood be enough to tip into "ok with having a general CVE"?

Totally agree it would be nice if there were existing other channels to signal EOL-ness. Either at the repository level (like NPM) or through package meta-data (multiple specs / committees are discussing this but in practice that would be years away before adoption). In the absence of those mechanisms, CVEs are about the one universally accepted mechanism for signaling risk. So, while imperfect and only when (1) isn't feasible, this practice of generic EOL+risk CVEs might still have more benefit than harm?

[zmanion]

My (current) opinion for the record:

• The state of software being EOL should (must) not get a CVE ID assignment
• I appreciate the awareness and attention providerd by a new CVE ID asignment
• This is similar to assigning CVE IDs for trojaned software (like xz utils CVE-2024-3094), which I also don't think deserves a CVE ID assignment, but I've been overrulled by practice (and I can squint and see that malicious software modification probably violates an implicit security policy, is unwanted, surprising, and has a security impact).
• If we assign for EOL, potentally a lot of (over time, all) software should get an assignment.
• CVE is about technical cybersecurity vulnerabilities. We (the various rules and practices) allow a lot of leeway (and explicitly note that CNAs can and should use their judgment) because defining vulnerabilities, especially at ther ediges, is naturally difficult. But we have to hold some line or face unwanted dilution.
• Depending how this discussion goes, I'll probably suggest a succinct new rule. Both the CNA rules and EOL policy will need updates and to be in agreement.

[dwelch2344]

Great thoughts all around. My current strong-convictions-loosely-held are:

• Unsupported software is a risk that must be managed, both as an industry best practice and a governance requirement.
• The vulnerability in question is, at best, a novel adaption of the CVE process (though benevolent in any light)
• The CVE program is the most appropriate institution to address explicit EOL* risks
• An EOL CVE policy should be created, requiring the originators of the component to clearly and intentionally confirm that the range in question will NOT be addressed moving forward.
  • Additional qualifiers are required, including that "not being addressed" includes something along the lines of the originators will outright not accept / review / participate in the process for said range
• If the CVE program does not provide a solution for this, instances like this will continue to occur in the future.
• Both CWE-1104 CWE-1357 provide constructs for managing this appropriately in the current model (again, with some potential guidelines/policies)
• Originators need to have a way to "cut off" being accountable for triage at a certain level.
  • I actually hate this point, but it's a reality for the majority of projects due to resourcing

---

Also, responses to some comments both here and in the slack thread:

The state of software being EOL should (must) not get a CVE ID assignment
I agree with the state of software is not a technical vulnerability and thus not CVE worthy, but the explicit decision to opt OUT of participating in the security process for a range. This is a very common practice, and frankly almost has to be otherwise each release would compound the burden indefinitely.

CVEs for EOL software can depress this kind of emergency activity and will put users at risk, since it gives those producers and artificial "out."

I agree with this in spirit, but in practice software producers already & always have said "out" – and it's by far more common than indefinitely accepting and managing vulnerability reports for long dead software.

Who defines the security policy is left up to the reader, so CNAs are left to decide what it means (which means it can mean anything), and anything can be a vulnerability. (wrt 4.1.2)

Agreed. Security Policy is used in several places but never defined, and fwict from multiple POVs.

That said, in this context I think it's fair to assume a "security policy" to be defined along the lines of a set of rules or requirements that help ensure the security posture of a system, such as protecting against unauthorized access, maintaining availability, ensuring reliability, or safeguarding data integrity, with said security policy being violated would belong to the "CVE consumer" (do we have a better term for this?)

If that logic holds, I'm strongly of the opinion that some form of EOL CVE can be appropriate, as using unsupported software components violates pretty much every modern GRC framework (let alone most commercial SLAs). Off hand, that list includes:

• FedRAMP
• PCI DSS
• HIPAA
• NIST CSF + 800-53
• GDPR
• SOC 2 / ISO 27001

If the CVE program's purpose is to identify, catalog, and disclose cybersecurity vulnerabilities, a software maintainers explicit declaration that there will be no oversight on a project should absolutely be considered a vulnerability.

[mcollina]

@dwelch2344

If the CVE program's purpose is to identify, catalog, and disclose cybersecurity vulnerabilities, a software maintainers explicit declaration that there will be no oversight on a project should absolutely be considered a vulnerability.

This has essentially been our reasoning when emitting the CVE for Node.js EOL versions. Note that it might have been lost in the noise: all the Node.js versions included in CVE have multiple unpatched vulnerabilities. All the people affected are essentially using vulnerable software.

——

@zmanion

The state of software being EOL should (must) not get a CVE ID assignment

An alternative option is to always include EOL versions in new CVEs even if a new vulnerability has not been assessed for them. This likely creates a lot of edits to the CVEs, which we don’t have the resources to do, and it really shouldn’t be done by 3rd parties that do not know our project. However, finding a way to make this work might be possible. Is this a preferred route?

[zmanion]

I do not disagree that EOL status is important security information, and as @mcollina notes, EOL software is likely accumulating unfixed vulnerabilities. The "narrow" question for CVE is whether or not CVE should be the mechanism to convey this. I have no great experience or preference, but do any of these efforts help?

https://openeox.org/
https://endoflife.date/

That is, is there a "better" way to convey EOL than CVE?

[zmanion]

@dwelch2344

If the CVE program's purpose is to identify, catalog, and disclose cybersecurity vulnerabilities, a software maintainers explicit declaration that there will be no oversight on a project should absolutely be considered a vulnerability.

In this view, would a unit of software get one assignment when that unit becomes EOL?

[dlorenc]

Thanks @zmanion. I agree with your take here - the mere fact that software is EOL should not be considered a vulnerability. I also agree that it is a software risk, but that feels out of scope of the CVE system for me.

There are two ways vulnerabilities can be reported against EOL software today:

• A vulnerability is discovered in the currently supported release, and then that vulnerability is subsequently fixed only in the supported release. In this case, metadata in that CVE entry should show that the EOL software remains affected. This is very common and works well, and already acts to pressure users of the EOL software to upgrade
• A vulnerability is discovered in the EOL software and it has already been fixed in the supported release. From existing CVE guidance, "Vendors are under no obligation to validate vulnerability reports in EOL software", but if they do so they can use the "Unsupported When Assigned" tag

This does leave a gap in vulnerability reporting for the second case here which a CVE such as CVE-2025-23089 might have been designed to address, but I feel the CVE system is the wrong place to close that gap. Minor and patch releases of software are almost always "unsupported" as soon as a new version comes out. For example, the current release of Node.js is v23.6.1. This means v23.6.0 is effectively EOL as well and will no longer receive security updates either. Trying to issue CVE ids to close this gap would require a new release or updated CPE metadata for every single release.

[mcollina]

That is, is there a "better" way to convey EOL than CVE?

Note that CVE-2025-23089 wasn't emitted when the release went EOL but when we shipped a new set of security releases for the supported lines. The result is that the EOL release lines are very likely vulnerable, but we don't have the bandwidth to clearly assess all the previous lines for all valid CVEs.

Managers think they are safe because there no known vulnerabilities, and teams are not being given budget to allocate to upgrades.

An alternative is to widen the range for all new CVEs and always include some past versions range out of caution (and mention it in the CVE). Would that be better?

This does leave a gap in vulnerability reporting for the second case here which a CVE such as CVE-2025-23089 might have been designed to address, but I feel the CVE system is the wrong place to close that gap.

I don't see any good, widespread alternative to convey "this release line has vulnerabilities in it, you are using EOL software and we are not assessing it".

https://www.cve.org/Resources/General/End-of-Life-EOL-Assignment-Process.pdf covers the case of pure EOL vulnerabilities, but it provide close to no guidance for the mixed case we live daily.

[mcollina]

This means v23.6.0 is effectively EOL as well and will no longer receive security updates either.

This is not how our release process works. Our release lines are only majors, and are the one receiving new releases with the security fixes. You can read more about our release process at:

https://github.com/nodejs/Release

[dwelch2344]

If the CVE program's purpose is to identify, catalog, and disclose cybersecurity vulnerabilities, a software maintainers explicit declaration that there will be no oversight on a project should absolutely be considered a vulnerability.

This has essentially been our reasoning when emitting the CVE for Node.js EOL versions. Note that it might have been lost in the noise: all the Node.js versions included in CVE have multiple unpatched vulnerabilities. All the people affected are essentially using vulnerable software.

Thanks @mcollina! And fwiw: knowing that this particular instance of an "EOL CVE" does actually target vulnerable versions makes this a perfect example where this kind of approach seems warranted.

@zmanion:
If the CVE program's purpose is to identify, catalog, and disclose cybersecurity vulnerabilities, a software maintainers explicit declaration that there will be no oversight on a project should absolutely be considered a vulnerability.

In this view, would a unit of software get one assignment when that unit becomes EOL?

This is a SOLID question that a few of us have been wrestling with. Ideally, IMO, I would say yes. My thinking is that this current instance is a one-time "catch-up" – when the next version of Node hits EOL (specifically the "cut off" point where future CVEs will no longer be validated against said version) goes EOL, a much more narrow scoped EOL CVE for the most applicable range would be filed. (Again, using this example, but I'm in no way affiliated / speaking on behalf of node 😅 )

The end result is that I as a CVE consumer (whether security team, development, or GRC) will now be alerted that – according to the actual project + maintainers – am at risk for running this EOL software with an established vulnerability / threat vector.

Isn't that the very reason for the CVE project? Granted, we can semantically argue whether said "EOL Vulnerability" is/isn't a specific credible issue vs a categorical one, but I'd argue if the CVE model doesn't support the real world application of it's principles then the model should be changed... and maybe that's where we tighten up the rules/policies so it's not free form chaos.

The state of software being EOL should (must) not get a CVE ID assignment

An alternative option is to always include EOL versions in new CVEs even if a new vulnerability has not been assessed for them. This likely creates a lot of edits to the CVEs, which we don’t have the resources to do, and it really shouldn’t be done by 3rd parties that do not know our project. However, finding a way to make this work might be possible. Is this a preferred route?

Oof please no. I see your rationale, but IMO this shuffles the unmanageable maintainer-burden of validating every issue against every historical version to the consumer's end (wrt making an informed decision about their risk profile). Far better to either leave the status quo or provide a broader stroke to signify it's up to consumers to measure the risk IMO.

---

Emphasis added below:

There are two ways vulnerabilities can be reported against EOL software today:

• A vulnerability is discovered in the currently supported release, and then that vulnerability is subsequently fixed only in the supported release. In this case, metadata in that CVE entry should show that the EOL software remains affected. This is very common and works well, and already acts to pressure users of the EOL software to upgrade
• A vulnerability is discovered in the EOL software and it has already been fixed in the supported release. From existing CVE guidance, "Vendors are under no obligation to validate vulnerability reports in EOL software", but if they do so they can use the "Unsupported When Assigned" tag

metadata in that CVE entry should show that the EOL software remains affected
You're completely right, but the truth is this explicitly doesn't happen on the regular. Even the best resourced teams can't and won't do this; Node's choice here is a good example but look at everything from .NET to Spring.

Spring's actually a great example, as most list the subjectively relevant affected versions and then opt out with Older, unsupported versions are also affected – see cve-2024-38816, which I happened to have on another tab. One could argue this is bad practice on the CNA / reporter's front, but the reality is that neither party has the incentive to go back through years of history / releases and verify to accurately range this. And again, to reiterate, I see this daily in every OSS project we work in - which is a much longer list than posted.

Vendors are under no obligation
This is the crux of the issue. Vendors are not obligated, nor is it tenable to assume they could do so if they were. Furthermore even a well resourced who has both technical & financial incentive to have individual + accurate CVEs filed (ie HeroDevs) cannot sustain doing this.

---

Okay, I'll take a step back here. Again, clearly something I'm passionate about – but I think this is one of the most important decisions we could make for the next N decades of software development.

I think it would benefit this thread to have the vendors/originators-of-software weigh in more on whether support of EOL in some form would produce better results. @zmanion I'm assuming we're not limiting the discussion here to just Node's EOL CVE, but happy to spin up new issues if preferable. Just lmk

[zmanion]

oss-security thread: https://www.openwall.com/lists/oss-security/2025/01/21/5

[zmanion]

@dwelch2344

I'm assuming we're not limiting the discussion here to just Node's EOL CVE, but happy to spin up new issues if preferable. Just lmk

IMO this is a universal discussion/decision, not limited to Node.js. And at the risk of repeating myself or others, the narrow question is whether the CVE Program allows assignments for EOL. I believe there is broad agreement (including within the CVE Program) that knowing softare is EOL (and security fixes won't be provided, at least not by the original vendor/developer/maintainer) is important and useful information.

[dlorenc]

This is not how our release process works. Our release lines are only majors, and are the one receiving new releases with the security fixes. You can read more about our release process at:

I think we're saying the same thing just differently - my point is just that every patch release is immediately EOL as soon as a new patch release comes out. The same for minors, and that this is likely true for every open source project out there.