Skip to content

[Aikido] Fix 3 security issues in esbuild, devalue#5

Closed
aikido-autofix[bot] wants to merge 1 commit into
mainfrom
fix/aikido-security-update-packages-49059578-pwdq
Closed

[Aikido] Fix 3 security issues in esbuild, devalue#5
aikido-autofix[bot] wants to merge 1 commit into
mainfrom
fix/aikido-security-update-packages-49059578-pwdq

Conversation

@aikido-autofix

@aikido-autofix aikido-autofix Bot commented Jun 14, 2026

Copy link
Copy Markdown

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 esbuild package. This change only affects the fallback download path during installation.

After searching the codebase, I found:

  • No direct usage of esbuild in any source code files (.js, .ts, .jsx, .tsx, .mjs, .cjs)

  • No custom installation scripts or postinstall hooks in package.json

  • No 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 install workflow 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)

Version Description
0.28.0
Integrity check hashes for all platform-specific binary packages are now embedded in the top-level esbuild package, which could affect the fallback download path during installation
✅ 3 CVEs resolved by this upgrade

This PR will resolve the following CVEs:

Issue Severity           Description
GHSA-gv7w-rqvm-qjhr
HIGH
[esbuild] Deno module downloads native binaries from npm registry without SHA-256 integrity verification, allowing attackers who control the NPM_CONFIG_REGISTRY environment variable to inject malicious binaries and achieve remote code execution. Node.js equivalent includes this protection, but Deno implementation lacks it entirely.
GHSA-g7r4-m6w7-qqqr
LOW
[esbuild] A path traversal vulnerability in the development server on Windows allows attackers to bypass directory containment using backslash characters, enabling arbitrary file read access outside the configured servedir root directory.
CVE-2026-42570
HIGH
[devalue] Deserialization of sparse arrays causes excessive memory allocation due to JavaScript engine quirks, leading to denial of service through memory exhaustion.
🤖 Remediation details

Fix security vulnerabilities in esbuild and devalue transitive dependencies

Short summary

This PR remediates vulnerabilities in two transitive dependencies — esbuild and devalue — both pulled in through astro. The fix updates devalue via a lockfile-only refresh and pins esbuild to a safe version via an overrides entry added to the root package.json. The lockfile (package-lock.json) is updated in both cases.

esbuild

esbuild appeared as two separate lockfile instances: one at node_modules/esbuild (resolved 0.27.7, required by astro@5.18.1 via ^0.27.3) and one at node_modules/vite/node_modules/esbuild (resolved 0.25.12, required by vite@6.4.2 via ^0.25.0). No stable release of astro (5.x or 6.x) widens its esbuild range to ^0.28.x, and no stable vite version reachable through astro 5.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 root package.json, targeting only vulnerable instances. After npm install --package-lock-only, both previously separate instances collapsed into a single hoisted node_modules/esbuild@0.28.1 entry.

devalue

devalue appeared as a single lockfile instance at node_modules/devalue (resolved 5.7.1), pulled in by astro@5.18.1 which declares it as ^5.6.2. Because 5.8.1 (the patched version) satisfies that existing caret range, no manifest change was needed — running npm update devalue --package-lock-only was sufficient to refresh the lockfile to 5.8.1.

Version changes

Package From To Why updated
devalue 5.7.1 5.8.1 Direct CVE fix — semver resolution within astro's existing ^5.6.2 range
esbuild 0.27.7 / 0.25.12 (two instances) 0.28.1 (single hoisted instance) Direct CVE fix — override applied after no stable parent chain could resolve ≥ 0.28.1

@aikido-autofix

Copy link
Copy Markdown
Author

Closed by Aikido: a new AutoFix has been created → #6

@aikido-autofix aikido-autofix Bot closed this Jun 20, 2026
@aikido-autofix aikido-autofix Bot deleted the fix/aikido-security-update-packages-49059578-pwdq branch June 20, 2026 00:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants