Wrongly assigned CVE critical vulnerabilities to 16.16.0

[CrlsMrls]

After reading the contributing guidelines, in my opinion this is the best place I found to raise this issue. I understand this may not be correct though, sorry in advance for the inconvenience.

What is the problem this feature will solve?

There are multiple resources that (in my opinion) are wrongly assigning CVE critical vulnerabilities to node.js version 16.16.0.

The goal of this GitHub issue is to raise awareness in the Node.js community, so this situation is fixed.

Our security CICD pipelines are raising these critical vulnerabilities for the latest LTS version of node.js (version 16.16.0)

CVE	SEVERITY	CVSS	PACKAGE	VERSION	STATUS
CVE-2022-32215	critical	9.10	node	16.16.0	fixed in 18.5.0, 16.20.0, 14.20.0
CVE-2022-32214	critical	9.10	node	16.16.0	fixed in 18.5.0, 16.20.0, 14.20.0
CVE-2022-32213	critical	9.10	node	16.16.0	fixed in 18.5.0, 16.20.0, 14.20.0

This seems wrong to me, because:

• You announced in the July 2022 security releases blog these vulnerabilities were fixed.
• The vulnerability was reported in https://hackerone.com/reports/1501679, and you clearly state this was finally fixed.
• The commit 1da22eb addressed those issues and it is merged.
• The report says it will be fixed in 16.20.0 (which still does not exist)

On the other hand, there are very well respected vulnerability databases stating this is not fixed yet:

• The US government National Vulnerability Database (NVD) assigns CVSS 9.1, indicating that it is fixed ONLY in v.16.20.0 https://nvd.nist.gov/vuln/detail/CVE-2022-32215
• Synk vulnerability DB says there is no fix for this vulnerability. https://security.snyk.io/vuln/SNYK-JS-LLHTTP-2946720

I am not sure how to resolve these discrepancies. Until this is fixed, our security practices are blocking this node.js version, which means we cannot use version 16 at all.

What is the feature you are proposing to solve the problem?

Somebody from the Node.js organization contacts NATIONAL VULNERABILITY DATABASE to fix the issue.

[mhdawson]

Looking at our entries in Hacker 1 which is how we request/publish CVEs it does seems like there was a cut/paste error so that we reported it was fixed in 16.20.0 intead of 16.16.0.

I could not find an option in H1 to update the CVE data so I've send a message asking how can can do this.

Thanks for raising the issue.

[mhdawson]

@RafaelGSS FYI.

[thejackal]

@mcollina FYI

[mcollina]

@mhdawson thanks for taking care of this. I made another typo too apparently in another one.

We really need more eyes on them before hitting publish.

[mcollina]

One note: I'm not aware why those vulnerabilities were classified as critical by others. THEY ARE NOT.

Update at your own pace, you are almost certainly not at risk as they apply only in very specific conditions with limited impact.

[mhdawson]

No answer to my question on how to update yet and I'm out until next Tuesday. WIll check when I get back.

[texiontech]

We have got this report issue from Aqua-scan too.

[mcollina]

@MylesBorins what would be the best way to notify the Github Security Advisories team about this change?

[nil4]

https:/github/advisory-database#contributions suggests a couple of approaches that might help.

[mhdawson]

Trying to follow up with a contact we have at H1 as I'm still waiting on a response through the help system.

[mcollina]

I checked and it's not possible to fix it via GitHub as the information is not copied in that registry.

[mhdawson]

I reached out to our contact at H1 and they indicated they would help point me in the right direction. Will update here when I have more info.

[aberezovski]

Hey guys,

I was thinking to open similar issue, but found this one.
Regarding NVD confusion, I was convinced that it was a copy/paste issue regarding the Node.js versioning in NVD vulnerabilities like CVE-2022-32214.
The original NVD statement says vulnerability applicable:

• from (including) 16.0.0 up to (excluding) 16.20.0

but the update from July 27th says vulnerability applicable:

• from (including) 16.0.0 up to (including) 16.12.0
• from (including) 16.13.0 up to (excluding) 16.16.0

Apart of that I would like to understand how did the above mentioned commit 1da22eb fix the issue?
The July 7th Security Release mentions that all three CVEs related to llhttp library issue were fixed by using llhttp v6.0.7 where tag v6.0.7 was added on July 6th.

I found the line project(llhttp VERSION 6.0.5) in the Node.js 16.16.0 source code, but according to security release the fix is in llhttp v6.0.7.

Could you clarify what does the sticked llhttp version 6.0.5 in the file deps/llhttp/CMakeLists.txt mean?
And if there is nothing missed to provide a proper fix for the discussed CVEs?

[mhdawson]

I've gotten info on how to request an update to the CVEs. Adding here so that we have a record (although I'll think about whether we have a good place to PR into our docs/guidance as well)

Go to the “CVE IDs” section in your program sections (https://hackerone.com/:handle/cve_requests)
Click the “Request a CVE ID” button
Enter the CVE ID that needs to be updated 
    Include all the details that need updating within the form
Submit the request

[mhdawson]

The link I think should be - https://hackerone.com/nodejs/cve_requests

[mhdawson]

Ok updates are now submitted. They still need to be processed on the H1 side before we'll see the updates externally.

[aberezovski]

Hey guys,

Could you confirm that commit 1da22eb really fixed the issue?
And there is not any typo in the file deps/llhttp/CMakeLists.txt, and no adjustment (like mentioned below) is required in that sense?

• From: project(llhttp VERSION 6.0.5)
• To: project(llhttp VERSION 6.0.7)

Thank you in advance and be well.

[mhdawson]

@aberezovski I think it is an artifact on how llhttp is updated for vulnerabilities. Since updating llhttp in advance would dislose the vulnerability, the commits for the security release were directly landed in the node repo. There was then a later llhttp release which incorporated the changes.

I had to fix a similar issue in the past - https:/nodejs/node/pull/43029/files. It looks to me like CMakeList.txt is an additional file not in the llnode repo that is maintained separately and needs to be updated independently as well.

Since https:/nodejs/node/blob/main/deps/llhttp/include/llhttp.h says 6.0.7 I think updating CmakeList.txt was just missed. @ShogunPanda can you confirm that is correct?

We still need to better document the update process for a security release to avoid the confusion.

[mhdawson]

PR to add missing step to update the CMakeList.txt to llhttp update instructions. #44136

It may not have fixed this case where we do things a bit differently for security releases but still needed and will help avoid us missing it once we document the security release specific flow.

[mhdawson]

@aberezovski if you believe my analysis is incorrect and we have actually missed something, please report through H1 so that we can handle as a additional/new vulnerability - see https:/nodejs/node/security/policy

[ShogunPanda]

@mhdawson Yes, I do confirm it.

llhttp is updated first in private, then incorporated in node and then released publicly.
Another related issue is that llhttp release procedure was not streamlined yet and this resulted in some inconsistencies over the past.

I'm trying to address this in nodejs/llhttp#173

[aberezovski]

@mhdawson, I am OK with your arguments.
I was not aware about another place where the llhttp version was tracked.
Anyway, either fixing the inconsistency caused by two sources for llhttp versions, or keeping only one source of versioning is exactly way to go.
Thanks for clarification.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[RafaelGSS]

Is it solved @ShogunPanda @mhdawson? In case not, how can I help? I think it should be updated in https:/nodejs/security-wg/blob/main/vuln/core/94.json as well.

[mhdawson]

I had asked Hacker one how to best do this but never got an answer. We'll have to follow up again.

[CrlsMrls]

I believe it is safe to close this ticket, as the version 16.16.0 is deprecated.

Thank you all for your feedback and work. 🙇