feat: add csv with missing

[marco-ippolito]

Created a CSV with every CVE in our list, and the missing EOL lines
@nodejs/security-wg

[RafaelGSS]

The first line I reviewed points exactly to why I told you that this process isn't that simple as it seems.

To make it work we'll need to find exactly which versions were End-of-Life in the moment the patched version came out. For instance, if the CVE is being patched to v8.x and v6.x line is not EOL yet, it implies that version is not affected by that vulnerability, on the other hand, v7.x was EOL and should be included. We'll need to correlate the version date using @pkgjs/nv and https://github.com/nodejs/Release/blob/main/schedule.json to make it correct.

[mcollina]

lgtm

[mhdawson]

@marco-ippolito to help me understand, does this just mark all EOL version as vulnerable to all CVEs that we have not checked for applicability or is it based on research you have done?

[marco-ippolito]

@marco-ippolito to help me understand, does this just mark all EOL version as vulnerable to all CVEs that we have not checked for applicability or is it based on research you have done?

This marks as vulnerable every version that wad EOL when the cve was assigned. Its not based on research

[ljharb]

… we're not planning on adding those to the CVE, though, right? especially given MITRE's response, an affected version needs to be one that's been explicitly validated as affected, not just "maybe/probably? we haven't checked"

[mhdawson]

@marco-ippolito thanks for confirming

[mhdawson]

@ljharb other projects (I think spring was the one mentioned) tag all EOL versions as vulnerable to all new CVE's without checking. I believe that was the pattern we are planning to follow.

[ljharb]

oof, ok. that's really unfortunate, but i guess it's better than nothing.

[RafaelGSS]

oof, ok. that's really unfortunate, but i guess it's better than nothing.

Yeah, that's exactly what I tried to bring to the OpenSSF discussion. We don't have the capacity to assess all EOL lines against CVEs, but still, we want to inform users they shouldn't be using an EOL. As Michael mentioned, this is the only viable option we found -- although sometimes imprecise.

[RafaelGSS]

LGTM. We should update the vuln database too. Use a new field on this instead.

[marco-ippolito]

Should we create an issue to track next steps?

[RafaelGSS]

Should we create an issue to track next steps?

I'd merge this PR only when H1 updates the CVE, then we can create the issue to update the vuln DB.

In theory, we already have: #1443

[marco-ippolito]

All right so we should create a ticket on H1 and send them the csv.

[bwillis]

Hey, team, thanks for putting this together. I can help update this in the MITRE CVE database. Generally speaking, we use API calls to the MITRE CVE services API to create and update records. With the provided CSV, the main challenge is to identify how to translate the version information into the CVE Record Format version information so that it is captured correctly and consumable. I haven't seen good examples of how EOL versions should be structured, so I want to document my thinking and would appreciate feedback.

For reference, this is an example of the most recent CVE version structure for CVE-2025-23083:

{
   ...
    "cveMetadata": {
      "cveId": "CVE-2025-23083",
      "state": "PUBLISHED",
      ...
    },
    "containers": {
      "cna": {
        ...
        "affected": [
          {
            "defaultStatus": "unaffected",
            "vendor": "nodejs",
            "product": "node",
            "versions": [
              {
                "version": "20.18.1",
                "status": "affected",
                "lessThanOrEqual": "20.18.1",
                "versionType": "semver"
              },
              {
                "version": "22.13.0",
                "status": "affected",
                "lessThanOrEqual": "22.13.0",
                "versionType": "semver"
              },
              {
                "version": "23.6.0",
                "status": "affected",
                "lessThanOrEqual": "23.6.0",
                "versionType": "semver"
              }
            ]
          }
        ],
        ...
      }
    }
  }
}

I think the above represents the most recent vulnerable & patched versions (Vulnerable:"20.x || 22.x || 23.x", Patched:"^20.18.2 || ^22.13.1 || ^23.6.1").

As for the EOL versions ("4.x || 5.x || 6.x || 7.x || 8.x || 9.x || 10.x || 11.x || 12.x || 13.x || 14.x || 15.x || 16.x || 17.x || 19.x || 21.x"), my initial thinking is that we can represent them as:

{
  ...
    "affected": [
      {
        "version": "4.0",
        "status": "affected",
        "lessThan": "4.*",
        "versionType": "semver"
      } # repeat for all EOL versions
    ],
  ...
}

I would appreciate it if someone could verify that this structure makes sense, especially for those who have tools consuming the format, given the nuances in version parsing and interpretation. In parallel, I'll also seek advice from other CNA members and report back what I hear.

Thank you!

[marco-ippolito]

we could also grab the latest version for each release line which are available here and mark them as:

{
     "version": "v16.20.2",
     "status": "affected",
     "lessThanOrEqual": "v16.20.2",
     "versionType": "semver"
}

and repeat for each version

[marco-ippolito]

@bwillis do you have any update on this? is there a timeline?

[bwillis]

Apologies for the delay. I've translated the CSV format here into the CVE Services JSON format.

I chose the default to unaffected, meaning these are more exhaustive, but we should assume that any new versions will not be affected. Some versions were vulnerable and affectedEOL, while some were just affectedEOL. I treated these the same, as affected. One special case seemed to be for CVE-2018-12115, which was vulnerable <= 10, but I only listed versions that showed up in patched and affectedEOL as affected, so v1, for example, I left out.

output.txt

There's a lot, but it would help if someone could validate that it makes sense. Thanks, and sorry again for the delay.

[Fdawgs]

Suggested change

	const vulnerabilities = require('../../vuln/core/index.json');
	const { createWriteStream } = require('fs');
	const { format } = require('fast-csv');
	const { resolve } = require('path');
	const semver = require('semver');
	const nv = require('@pkgjs/nv');
	const path = require('path');
	'use strict';
	const vulnerabilities = require('../../vuln/core/index.json');
	const { createWriteStream } = require('fs');
	const { format } = require('fast-csv');
	const { resolve } = require('node:path');
	const semver = require('semver');
	const nv = require('@pkgjs/nv');

Path is already being imported, so the duplicate import could be removed?