esbuild security issue from npm audit

[mfulton26]

Note

You may get a following npm audit report when installing Vite.

# npm audit report

esbuild  <=0.24.2
Severity: moderate
esbuild enables any website to send any requests to the development server and read the response - https://github.com/advisories/GHSA-67mh-4wv8-2f99
fix available via `npm audit fix --force`
Will install [email protected], which is a breaking change
node_modules/esbuild
  vite  >=0.11.0
  Depends on vulnerable versions of esbuild
  node_modules/vite
    @vitejs/plugin-react  >=2.0.0-alpha.0
    Depends on vulnerable versions of vite
    node_modules/@vitejs/plugin-react

3 moderate severity vulnerabilities

This vulnerability does not affect Vite and this audit report can be ignored for the meanwhile. We plan to upgrade esbuild in the next minor version. Note that running npm audit fix --force confusingly installs a quite old version of Vite which is not maintained anymore and should not be run.

Edited by @sapphi-red

---

May we get esbuild updated to 0.25.0 to address GHSA-67mh-4wv8-2f99?

[patak-dev]

the esbuild CVE is for the esbuild dev server, that Vite doesn't use. It was reported by @sapphi-red, after fixing a similar issue on vite's side.

please don't ignore the issue template next time, and always provide a minimal reproduction

[mfulton26]

the esbuild CVE is for the esbuild dev server, that Vite doesn't use. It was reported by @sapphi-red, after fixing a similar issue on vite's side.

please don't ignore the issue template next time, and always provide a minimal reproduction

I don't recall being prompted with an issue template… odd. I will watch for that though next time.

Is there a problem with updating though? Not updating will mean noise in security reporting tools.

[patak-dev]

We only update esbuild minors on Vite minors. PR to do the update here:

• chore: bump esbuild to 0.25.0 #19389

security reporting tools should stop making noise

[mfulton26]

security reporting tools should stop making noise

I agree, I wish there were an easy way to not flag things for unused features… maybe that is a reason for things to be published as multiple, smaller packages instead of one though; e.g. if the esbuild dev server were its own package then it would reduce noise.

[sbernard31]

security reporting tools should stop making noise

My 2 cts abou that.
I think this is not so easy to avoid that kind of noise. 😞
And Security reporting tool are very useful and waiting software community find a better alternative we need to deal with how current security tool works. (and so try to limit noise)

maybe that is a reason for things to be published as multiple, smaller packages instead of one though; e.g. if the esbuild dev server were its own package then it would reduce noise.

Yep this could be a way.

I wish there were an easy way to not flag things for unused features…

A bit what VEX is trying to achieve but it seems not really popular for now. 🤷

Using VEX could be a good way to avoid some false positive during vulnerabilities check.
But if it is used direct/transitive dependencies should be managed correctly which is generally not really done.
So tooling will be needed to check that this 👆 is done correctly...

For me details see :

• https://www.aquasec.com/blog/introducing-vex-hub-unified-repository-for-vex-statements/
• https://aquasecurity.github.io/trivy/v0.56/docs/supply-chain/vex/file/#applying-vex-to-dependency-trees--
• Some question about VEX for library aquasecurity/trivy#7784

[Orrison]

Hey folks! Should this issue be re-opened? It is currently marked as Closed: Not Planned but it looks like it is a part of the 6.2 Milestone in this PR: #19389

[patak-dev]

We don't need to reopen this issue. There isn't any security issue in Vite at the moment. We always update esbuild in each vite minor, that is what that PR is doing. The automated tooling reporting this issue should be fixed, but we are going to release the next minor soon.

[Orrison]

Thank you, @patak-dev. That does make sense and sounds good.

But, I would like to echo @sbernard31. A security audit mostly doesn't care if you are correct that you are not vulnerable to the CVE. It cares primarily whether or not your dependency tree results in the installation of known vulnerable code.
This can be justified with paperwork "proving" that you are not vulnerable to the particular CVE, but for many projects, that is at least inconvenient and, at most, could still result in a failure of the audit.

Understanding this, I'll just propose to the conversation that dependabot and other tools reporting this as a vulnerability are not incorrect and are not noise. The package results in the installation of known vulnerable software and, therefore, contains vulnerabilities regardless of whether or not it is considered at the time that it can be triggered.

I totally understand y'alls reasoning though. Just throwing in my 2-cents from the perspective of dealing with projects that require these levels of scrutiny.

[casewalker]

Another 2-cents of thought:

IMO this is unfortunately not a simple "bump the patch version for esbuild" fix because of esbuild's versioning choices. Despite being a stable, long-lived project used by millions over the last five years, the maintainer has kept the project in version zero (initial development) all this time. I've been commenting on a two-years old issue to try to argue why releasing v1 could make it easier to remediate things like this vulnerability.

I am not sure that it's an easy ask for a solo maintainer to do all the legwork of LTS maintenance and EOL management, but given the massive usage of their project, I think it is a fair thing to talk about.

[santhosh-chinnasamy]

until new version is available we can override esbuild version by adding below lines to package.json

  "overrides": {
    "vite": {
      "esbuild": "^0.25.0"
    }
  }

Thanks to reddit comment