[Aikido] Fix 3 security issues in esbuild, devalue#5
Closed
aikido-autofix[bot] wants to merge 1 commit into
Closed
[Aikido] Fix 3 security issues in esbuild, devalue#5aikido-autofix[bot] wants to merge 1 commit into
aikido-autofix[bot] wants to merge 1 commit into
Conversation
Author
|
Closed by Aikido: a new AutoFix has been created → #6 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Upgrade esbuild and devalue to fix remote code execution via missing binary integrity checks, Windows path traversal in dev server, and denial-of-service via sparse array deserialization.
✅ Code not affected by breaking changes.
✅ The changelog entry describes an internal change to esbuild's installation mechanism where integrity check hashes for platform-specific binary packages are now embedded in the top-level
esbuildpackage. This change only affects the fallback download path during installation.After searching the codebase, I found:
No direct usage of
esbuildin any source code files (.js,.ts,.jsx,.tsx,.mjs,.cjs)No custom installation scripts or postinstall hooks in
package.jsonNo custom build configurations that interact with esbuild's installation process
No code that validates integrity hashes or interacts with binary downloads
The project uses Astro and Vite, which may use esbuild internally as a transitive dependency, but the codebase doesn't directly configure or interact with esbuild's installation mechanism
The change is purely internal to esbuild's installation process and does not affect the API, build behavior, or any functionality that this codebase relies on. The standard
npm installworkflow in the CI/CD pipeline (.github/workflows/deploy.yml) will handle the updated installation mechanism transparently.No breaking changes affect this codebase.
All breaking changes by upgrading esbuild from version 0.27.7 to 0.28.1 (CHANGELOG)
esbuildpackage, which could affect the fallback download path during installation✅ 3 CVEs resolved by this upgrade
This PR will resolve the following CVEs:
servedirroot directory.🤖 Remediation details
Fix security vulnerabilities in
esbuildanddevaluetransitive dependenciesShort summary
This PR remediates vulnerabilities in two transitive dependencies —
esbuildanddevalue— both pulled in throughastro. The fix updatesdevaluevia a lockfile-only refresh and pinsesbuildto a safe version via anoverridesentry added to the rootpackage.json. The lockfile (package-lock.json) is updated in both cases.esbuild
esbuildappeared as two separate lockfile instances: one atnode_modules/esbuild(resolved0.27.7, required byastro@5.18.1via^0.27.3) and one atnode_modules/vite/node_modules/esbuild(resolved0.25.12, required byvite@6.4.2via^0.25.0). No stable release ofastro(5.x or 6.x) widens itsesbuildrange to^0.28.x, and no stableviteversion reachable throughastro5.x uses esbuild≥ 0.28.1; the first parent versions that would resolve the issue are pre-release only (astro@7.0.0-beta.3). With the full parent-chain exhausted, a selector-pattern override"esbuild@<0.28.1": "0.28.1"was added to the rootpackage.json, targeting only vulnerable instances. Afternpm install --package-lock-only, both previously separate instances collapsed into a single hoistednode_modules/esbuild@0.28.1entry.devalue
devalueappeared as a single lockfile instance atnode_modules/devalue(resolved5.7.1), pulled in byastro@5.18.1which declares it as^5.6.2. Because5.8.1(the patched version) satisfies that existing caret range, no manifest change was needed — runningnpm update devalue --package-lock-onlywas sufficient to refresh the lockfile to5.8.1.Version changes
devalue5.7.15.8.1astro's existing^5.6.2rangeesbuild0.27.7/0.25.12(two instances)0.28.1(single hoisted instance)≥ 0.28.1