Dedicated EOL page

We want to draft a dedicated End-Of-Life (EOL) page to direct all our banners and links that highlight End-Of-Life support to a centralized page that highlights the importance of upgrading, key-risks, and our partner HeroDevs and its Node.js NES (Never Ending Support) program.

Takeaways:

Link under nodejs.org/eol and nodejs.org/{locale}/download/eol
Inspire ourselves on Vue's EOL page
Inspire ourselves on Node's EOL blog post

cc @nodejs/tsc @nodejs/marketing -- I'd like to add this to our agenda, so we can chat/talk about this and move forward. We definitely need the Foundation's support here to co-design (more like what the page should have and how we should word things) we can definitely inspire ourselves on Vue's https://v2.vuejs.org/eol/ EOL page) and draft a dedicated End-Of-Life page.

@mcollina

We got an approval from the TSC to implement this. We can start doing something that resembles a bit Vue's one but being version neutral and using some of the quotes from our blog post that @mcollina wrote and then have the Foundation (cc @nodejs/marketing) updating/fixing the copy as needed.

Here are some of the functional specs we agreed of the EOL page:

The page of course tells what is EOL,
why it is bad using EOL and what means using an EOL version of Node
and the "Commercial Support text" that was on /about gets moved here
The page then has a table listing:
- 4 columns
  - Node.js major that is EOL (followed by codename on same column)
  - When it became EOL
  - Pills containing the current CVEs for that version
    - Pill renders something like [(Critical) 15], [(High) 4], [(Low) 5]
      - Meaning it renders total number of CVEs per Severity Level
      - Color of pill based on Severity
      - Hovering Tooltip explaining what each Severity level means
  - Button "Details" that opens Modal that renders a full list of the CVEs (CVE Severity, CVE Number, CVE Title)
    - Each entry of the list when clicked opens on new page the MITRE to the CVE
    - Maybe some other info on the modal or details?
Then a section talking about the ESP program
Then CTAs to download latest version of Node or getting support to EOL versions of Node (links to ESP partner programs)

Some specs of updates across the website:

Button on home page redirects to /eol with the ESP section highlighted
About -> Previous Releases after Header, "Warning Alert Box" talking directly about EOL and link to EOL page, this Alert Box is a multi-line one and a bit longer (explaining summarized about EOL versions)
All other links on all alert boxes across the website (blog post from Matteo, Download pages, Version modal, etc) go to the /EOL page
All blog posts under the /security category should have the same warning alert box we added on /about Previous Releases that also goes to /EOL, the box should be before the blog post title.

This issue can be worked on starting immediately cc @nodejs/nodejs-website and it is of highest priority 🙇 (anyone can tackle it) and I'm going to personally bounty $50 as a thank you for whoever that completes it.

Why wouldn't someone connect "Commercial Support" with "EOL"?

Why wouldn't someone connect "Commercial Support" with "EOL"?

I think it's fine to mention Commercial Support if we also add EOL. The current banner, if I just landed on that page, that banner wouldn't be helpful for me. But if it said something that attracts the user, like a CTA that also showcases the danger of EOL. The banner needs to be more convincing.

for context, we are discussing WIP within #7990

I've started the business logic of grouping and displaying the vulnerabilities. I want to gut check some logic and assumptions before going further. A lot of this is thinking out loud for my own benefit...

The EOL Version page shows patched vulnerabilities

Things like docker hub show ACTIVE vulnerabilities, not the whole list of found and patched ones. Well, this is me overthinking, cause the fact they show up at all indicates a patch has been issued, and the perspective of the user weighing whether to use that software is one of risk analysis.

By definition, I suppose all vulnerabilities are disclosed problems fixed by future versions. So we are using this as a communication mechanism to show the risk associated with these versions. Regardless of patch status (all are patched).

Perhaps... this all works on docker hub because they do make space for minor versions, but our current scope is to aggregate to EOL majors only, which sorta glosses over all this nuance.

Should to EOL Version page assume people are on the latest in the release line?

If so, it will diminish the impact of enumerating them because there will be less "active" or "open", unpatched.

So to answer my question, we make no assumptions of the user's current position, we only communicate the aggregate risk of that Node.js release line (even if all the disclosed vulnerabilities are patched IN THAT release line). What that will mean, then is that as versions fall into EOL, they will show up with the things that we DID fix over the course of its lifecycle, and simply imply that if you are using something prior to disclosure, you are at risk. This is a paradoxical perhaps coffee fueled way to show safety. "This release is safe because of all the things we fixed!"

For example:

someone is on Node 12.
They find this page, see all the things fixed in 12, 14, 16, and 18... and are armed with more info to jump to 20 or 22, not simply go to 14

Say, for this vulnerability:

    "108": {
      "cve": [
        "CVE-2023-30581"
      ],
      "vulnerable": "16.x || 18.x || 20.x",
      "patched": "^16.20.1 || ^18.16.1 || ^20.3.1",
      "ref": "https://nodejs.org/en/blog/vulnerability/june-2023-security-releases/",
      "overview": "The use of proto in process.mainModule.proto.require() can bypass the policy mechanism and require modules outside of the policy.json definition",
      "affectedEnvironments": [
        "all"
      ],
      "severity": "high"
    },

do we add this to the count for 16 and 18? it's been patched in every release line
- I think the answer is yes, else we will have no vulnerabilities to display (since we never disclose something until we have a patch... so this is a risk-communication vehicle of the age of a release, not an up to date reference for any particular major.minor relationship)
do we add this to versions less than 16? our written guidance is that and all earlier versions have these same vulnerabilities but will never receive patches

I think this is a great idea. "This is why it's bad; here are your options. Also, here's an arms-length friend."

Much better than an advert CTA :)

Are we also moving forward with a banner on all the EoL line doc pages? I also really like that idea and think it should point to this proposed page.

Are we also moving forward with a banner on all the EoL line doc pages? I also really like that idea and think it should point to this proposed page.

it's on all the vulnerability blog posts right now. We could expand scope to include release blog posts that are EOL.

I've updated the draft PR with more screenshots, and of course there is the deployment

WIP of the above logic.

I need to track down a number of unknown severities

https://raw.githubusercontent.com/nodejs/security-wg/main/vuln/core/index.json has 78 unknown severities. that doesnt exactly communicate much

here's some WIP with unknown added

Things like docker hub show ACTIVE vulnerabilities, not the whole list of found and patched ones. Well, this is me overthinking, cause the fact they show up at all indicates a patch has been issued, and the perspective of the user weighing whether to use that software is one of risk analysis.

Is the list of security wg also including unpatched CVEs or only patched CVEs? For example I assume the list from the last screenshot are unpatched CVEs, right?

I talked myself into patched because in most cases we dont have any disclosed but unpatched CVEs

this is now live! thanks to all the support along the way team!

Navigation Menu

Repository navigation

Dedicated EOL page #7906

19 remaining items

The EOL Version page shows patched vulnerabilities

Should to EOL Version page assume people are on the latest in the release line?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Dedicated EOL page #7906

Description

Activity

ovflowd commented on Jun 28, 2025

ovflowd commented on Jul 16, 2025

19 remaining items

ljharb commented on Jul 17, 2025

ovflowd commented on Jul 17, 2025

bmuenzenmeyer commented on Jul 17, 2025

bmuenzenmeyer commented on Jul 18, 2025

The EOL Version page shows patched vulnerabilities

Should to EOL Version page assume people are on the latest in the release line?

JakobJingleheimer commented on Jul 18, 2025

bmuenzenmeyer commented on Jul 18, 2025

bmuenzenmeyer commented on Jul 18, 2025

bmuenzenmeyer commented on Jul 18, 2025

bmuenzenmeyer commented on Jul 18, 2025

ovflowd commented on Jul 19, 2025

bmuenzenmeyer commented on Jul 19, 2025

bmuenzenmeyer commented on Aug 15, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions