Wrong CVE Creation - May 14th Security Releases

[RafaelGSS]

I'm opening this issue just for tracking.

In the latest Node.js Security Release (May 14, 2025), we have issued three new CVEs

• CVE-2025-23165
• CVE-2025-23166
• CVE-2025-23167

However, during this process, we have found that a mistake was made in the process, and the CVE-2025-23122 was also issued for the same vulnerability (likely due to an automation bug). We have informed the HackerOne team (@bwillis) and they are taking care of that.

We have also noticed the range of affected versions was incorrectly set (possibly a HackerOne bug). I have filled an ticket to HackerOne and they are also taking care of that (see screenshot)

While in the CVE.org shows:

affected from 20.19.1 through 20.19.1
affected from 22.15.0 through 22.15.0
affected from 23.11.0 through 23.11.0
affected from 24.0.1 through 24.0.1

---

In parallel, I have asked them to also include the EOL versions of Node.js to the range of affected versions, as part of #1443.

[bwillis]

Hey @RafaelGSS, I've updated the version ranges, both with the currently maintained versions and the EOL versions. Can you confirm they look ok?

Additionally, the UI currently only supports a limited version payload which only sets the version with a narrowly affected version. I can file a feature request to allow input of the lower/upper bound of the version for easier control for you. I think with the same request, we can probably handle the EOL versions as well. I'll report back when I discuss with the team.

[RafaelGSS]

Hi @bwillis

• For https://www.cve.org/CVERecord?id=CVE-2025-23165 it's missing v21 (EOL) - Rest LGTM.
• For https://www.cve.org/CVERecord?id=CVE-2025-23166 it's also missing v21 (EOL) - Rest LGTM
• https://www.cve.org/CVERecord?id=CVE-2025-23167 LGTM.

Additionally, the UI currently only supports a limited version payload which only sets the version with a narrowly affected version

That's weird, we have always set the versions in this way. I thought the range <= would mean: "The affected lines are all the ones <= vX.Y.Z".

[bwillis]

I've updated CVE-2025-23165 and CVE-2025-23166 to include EOL v21.

That's weird, we have always set the versions in this way

I think our understanding and the default behavior has evolved, especially after going through the EOL update. I'm pretty optimistic we can update the flow soon to make it more explicit and flexible.

[RafaelGSS]

Thank you!

So, for now, how should we write the "affected versions" to prevent this from happening again?

[bwillis]

So, for now, how should we write the "affected versions" to prevent this from happening again?

Sorry for the delay, I just got the team to release an updated workflow, so you can now specify the range of the version affected, for example:

Additionally, we added a little helper to add the EOL versions in the right format, so you can specify a range which will generate the list of affected versions:

I think this should help you more easily self manage a more accurate range as well as the EOL versions. Let me know if you have any questions about this or see any issues with the flow.

[RafaelGSS]

@bwillis Thank you!

Are those changes reflected in the API? All of our CVE creation pass by our automation

[bwillis]

Still working on deploying a new parameter for the upper bound to the API, I'll keep you posted!

[RafaelGSS]

@bwillis We have just published two new CVEs (Pending H1 Approval). Apparently, the same behaviour will happen

Can I edit it before it gets published on NVD so it also includes the EOL versions?

[bwillis]

Send back to draft for you, still working on the API updates, I haven't forgotten!

[RafaelGSS]

Thanks, just updated it. How do we publish it?