You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Wrongly assigned CVE critical vulnerabilities to 16.16.0 #43946
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)
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?
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.
Reacted by Matteo Collina, Benjamin Gruenbaum and Carlos Morales
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?
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.
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.
@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.
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.
Activity
mhdawson commentedon Jul 22, 2022
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 commentedon Jul 22, 2022
@RafaelGSS FYI.
mcollina commentedon Jul 22, 2022
@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 commentedon Jul 22, 2022
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 commentedon Jul 22, 2022
No answer to my question on how to update yet and I'm out until next Tuesday. WIll check when I get back.
texiontech commentedon Jul 25, 2022
We have got this report issue from Aqua-scan too.
mcollina commentedon Jul 25, 2022
@MylesBorins what would be the best way to notify the Github Security Advisories team about this change?
nil4 commentedon Jul 25, 2022
https://github.com/github/advisory-database#contributions suggests a couple of approaches that might help.
mhdawson commentedon Jul 26, 2022
Trying to follow up with a contact we have at H1 as I'm still waiting on a response through the help system.
mcollina commentedon Jul 27, 2022
I checked and it's not possible to fix it via GitHub as the information is not copied in that registry.
mhdawson commentedon Jul 27, 2022
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 commentedon Jul 29, 2022
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:
but the update from July 27th says vulnerability applicable:
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
llhttplibrary 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
llhttpv6.0.7.Could you clarify what does the sticked
llhttpversion 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?
6 remaining items
mhdawson commentedon Aug 4, 2022
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 commentedon Aug 4, 2022
@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://github.com/nodejs/node/security/policy
ShogunPanda commentedon Aug 5, 2022
@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 commentedon Aug 5, 2022
@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 commentedon Feb 2, 2023
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 commentedon Feb 2, 2023
Is it solved @ShogunPanda @mhdawson? In case not, how can I help? I think it should be updated in https://github.com/nodejs/security-wg/blob/main/vuln/core/94.json as well.
mhdawson commentedon Feb 2, 2023
I had asked Hacker one how to best do this but never got an answer. We'll have to follow up again.
CrlsMrls commentedon Jul 12, 2023
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. 🙇