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.

[marco-ippolito]

Looks good to me, just to double check

{ "versionType": "semver", "version": "5.0", "status": "affected", "lessThan": "5.*" },

The 5.* affects the whole 5.x release line right?

[bwillis]

{ "versionType": "semver", "version": "5.0", "status": "affected", "lessThan": "5.*" },

The 5.* affects the whole 5.x release line right?

Yes, correct. It's confusing, but there is even a direct explanation in the CVE schema:

For example, {version: 1.0 lessThan: 1.*} would describe the entire 1.X branch for most range kinds, and {version: 2.0, lessThan: *} describes all versions starting at 2.0

If that all makes sense, then I can proceed to get these updated. Do we need to generate a latest version of the CSV or are we all good to go?

[marco-ippolito]

I think we are good to go since we didnt release any new CVE lately.
@RafaelGSS @mcollina

[marco-ippolito]

I re run and no diff so we are good to go @bwillis

[bwillis]

I started to craft the import, but got stuck after inspecting a few more details.

1. CVE-2024-27982 duplicated:

CVE-2024-27982,"18.x || 20.x || 21.x","^18.20.1 || ^20.12.1 || ^21.7.2","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"
CVE-2024-27982,"18.x || 20.x || 21.x","^18.20.2 || ^20.12.2 || ^21.7.3","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"

Can someone confirm which one is correct?

2. A few of these didn't specifically look like NodeJS vulnerabilities:

• CVE-2024-9551 vuln in D-Link
• CVE-2016-2178 vuln in OpenSSL
• CVE-2016-2183 vuln in OpenSSL
• CVE-2016-5172 vuln in V8

I didn't keep going, so can someone confirm this is correct and double check the whole list to ensure these are in scope for NodeJS?

[marco-ippolito]

I'm not sure where you got CVE-2024-9551, its not in the csv file, nor in the vulnerabilities dataset.
I think at the beginning, they used to add in the dataset vulnerabilities are not node specific but affected node.
We can ignore those.

In regards of CVE-2024-27982

It was patched on ^18.20.1 || ^20.12.1 || ^21.7.2 on every platform except windows where it was patched in ^18.20.2 || ^20.12.2 || ^21.7.3.
Note the:

    "affectedEnvironments": [
      "win32"
    ],

In

  "140": {
    "cve": [
      "CVE-2024-27982"
    ],
    "vulnerable": "18.x || 20.x || 21.x",
    "patched": "^18.20.1 || ^20.12.1 || ^21.7.2",
    "ref": "https://nodejs.org/en/blog/vulnerability/april-2024-security-releases/",
    "description": "HTTP Request Smuggling via Content Length Obfuscation",
    "overview": "The team has identified a critical vulnerability in the http server of the most recent version of Node, where malformed headers can lead to HTTP request smuggling. Specifically, if a space is placed before a content-length header, it is not interpreted correctly, enabling attackers to smuggle in a second request within the body of the first.",
    "affectedEnvironments": [
      "all"
    ],
    "severity": "medium"
  },
  "141": {
    "cve": [
      "CVE-2024-27982"
    ],
    "vulnerable": "18.x || 20.x || 21.x",
    "patched": "^18.20.2 || ^20.12.2 || ^21.7.3",
    "ref": "https://nodejs.org/en/blog/vulnerability/april-2024-security-releases-2/",
    "overview": "Due to the improper handling of batch files in child_process.spawn / child_process.spawnSync, a malicious command line argument can inject arbitrary commands and achieve code execution even if the shell option is not enabled.",
    "affectedEnvironments": [
      "win32"
    ],
    "severity": "medium"
  },

[marco-ippolito]

I updated the list removing all the CVEs that affect Node.js but are not released by Node.js itself

Click to expand CVE list by project

CVE ID	Project
CVE-2017-1000381	c-ares
CVE-2017-3731	OpenSSL
CVE-2017-3732	OpenSSL
CVE-2016-7055	OpenSSL
CVE-2016-9551	libuv
CVE-2016-9840	zlib
CVE-2016-9841	zlib
CVE-2016-9842	zlib
CVE-2016-9843	zlib
CVE-2016-5172	V8
CVE-2016-6304	OpenSSL
CVE-2016-2183	OpenSSL
CVE-2016-6303	OpenSSL
CVE-2016-2178	OpenSSL
CVE-2016-6306	OpenSSL
CVE-2019-9511	HTTP/2
CVE-2019-9512	HTTP/2
CVE-2019-9513	HTTP/2
CVE-2019-9514	HTTP/2
CVE-2019-9515	HTTP/2
CVE-2019-9516	HTTP/2
CVE-2019-9517	HTTP/2
CVE-2019-9518	HTTP/2
CVE-2020-1971	OpenSSL
CVE-2021-23840	OpenSSL
CVE-2021-3450	OpenSSL
CVE-2021-3449	OpenSSL
CVE-2020-7774	npm
CVE-2021-27290	npm
CVE-2021-23362	npm
CVE-2021-37701	npm
CVE-2021-37712	npm
CVE-2021-37713	npm
CVE-2021-39134	npm
CVE-2021-39135	npm
CVE-2022-0778	OpenSSL
CVE-2023-23936	Undici
CVE-2023-24807	OpenSSL
CVE-2023-45143	Undici
CVE-2023-44487	HTTP/2

[bwillis]

I'm not sure where you got CVE-2024-9551

Sorry, I think I typo'd.

I updated the list removing all the CVEs that affect Node.js but are not released by Node.js itself

Thanks!

I've taken 5 of them to start with and ran the update. I think these look good, but a second set of eyes would be great:

• https://www.cve.org/CVERecord?id=CVE-2022-35255
• https://www.cve.org/CVERecord?id=CVE-2022-43548
• https://www.cve.org/CVERecord?id=CVE-2023-23918
• https://www.cve.org/CVERecord?id=CVE-2023-23919
• https://www.cve.org/CVERecord?id=CVE-2023-23920

Assuming those are good, I can do the rest in bulk. There are 76 that HackerOne "owns" as CNA, so those I can update, but I'll talk to MITRE about the remainder to see how we can proceed in updating. Hopefully they'll just transfer them over to us so we can finish the process.