CVE-2025-22874 - esbuild (stdlib) binary generates the vulnerability

[vbhardwaj10]

We are using nextjs in our application which used esbuild, in our recent aquascanner report we were flagged that the new CVE-2025-22874 vulnerability with high severity exists in the esbuild binary. Since I didn't notice any open issues with this vulnerability, creating this issue.

[evanw]

This report seems irrelevant to me as esbuild doesn't use the crypto/x509 package. I'm guessing this is unimportant noise from your vulnerability scanner. Feel free to disregard this vulnerability report.

It would also be nice if you could file a bug report with your vulnerability scanner about this, as it's reporting a false positive in code that esbuild doesn't even use.

[vbhardwaj10]

Thank you @evanw for the information. We will check with our vulnerability scanner provider.

[Alex-McLean]

We are also seeing this in our pipeline and auditing processes.
Seems like bumping go to 1.23.10 or 1.24.4 would resolve this.

[vbhardwaj10]

We use this in our NextJs project. So should the go version be updated by esbuild to fix this issue?

[vilatvok]

When this will be fixed? We also have this vulnerability issue. It seems like updating go version should help

[MikeWillCook]

CVE-2025-4673 popped up and can also be fixed by updating go to 1.23.10 to clean up these tangential CVE reports for many users. I'll create a PR for this.

[Alex-McLean]

Seems like the CVE has been updated, and now indicates that only go versions 1.24.0 - 1.24.3 are impacted.

[MikeWillCook]

Seeing some divergence between a couple scanning tools (grype and trivy), but looks like another CVE fixed in 1.23.10: CVE-2025-0913

[absidue]

The real fix would be for the vulnerability scanners to actually check what code is being used and only flag vulnerabilities that are actually relevant, instead of just checking the version and flagging lots of completely irrelevant stuff.

[MikeWillCook]

Agreed, ideally every scanner would be detailed enough to infer actual usage of dependencies, but unfortunately that's not how most scanners are implemented. Being able to know outside of runtime exactly what might be called would be challenging (especially for languages like Go that compile in dependencies).

Being able to update on this side is a much more efficient solution than pushing that off on all the users, so that'd be my recommendation.

[baonguyen2411]

Hi guys,
I got the same issue on Xray Jfrog, Please help me

[marianolop]

Hi, I have exactly the same issue and I can't run my CI. Do you hace an estimate time to solve this issue? I'm totally blocked in my company.

[marianolop]

@evanw can you please merge this and create a new release?