fix(deps): patch brace-expansion DoS (GHSA-rgw5-rvv9-x895) [DEVX-8507] - #26
Draft
warp-agent-staging[bot] wants to merge 2 commits into
Draft
fix(deps): patch brace-expansion DoS (GHSA-rgw5-rvv9-x895) [DEVX-8507]#26warp-agent-staging[bot] wants to merge 2 commits into
warp-agent-staging[bot] wants to merge 2 commits into
Conversation
Update the brace-expansion overrides to close both vulnerable copies left after the CVE-2026-14257 mitigation was found incomplete (GHSA-rgw5-rvv9-x895 / CVE-2026-69152): - brace-expansion@<1.1.18 -> 1.1.18 (pulled in by minimatch@^1.1.7, used by @eslint/eslintrc) - brace-expansion@>=3.0.0 <5.0.9 -> 5.0.9 (widened/bumped from the previous >=3.0.0 <5.0.7 -> 5.0.7 pin; pulled in by minimatch@^11, used by @typescript-eslint/typescript-estree) Both copies are dev-scope transitive dependencies with no production exposure. Regenerated package-lock.json via npm install. Ref: DEVX-8507 Co-Authored-By: Warp <agent@warp.dev>
Address review findings on PR #26 for DEVX-8507 (GHSA-rgw5-rvv9-x895): - The previous >=3.0.0 <5.0.9 -> 5.0.9 override left the 2.x vulnerable range (>=2.0.0 <2.1.4) uncovered, and 5.0.9 falls outside normal 3.x/4.x consumer ranges so npm would not force it onto nested consumers requesting exact 3.x/4.x versions. - Replace it with one override per vulnerable major line, each mapped to that line's own first patched version, mirroring the advisory's range -> patch mapping exactly: brace-expansion@<1.1.18 -> 1.1.18 brace-expansion@>=2.0.0 <2.1.4 -> 2.1.4 brace-expansion@>=3.0.0 <3.0.6 -> 3.0.6 brace-expansion@>=4.0.0 <5.0.9 -> 5.0.9 - This also avoids forcing 3.x consumers onto the 5.x line, which narrows engine support (5.0.9 requires Node 20 || >=22, while 3.0.6/4.0.1 support Node >=18). Regenerated package-lock.json; resolved tree is unchanged for the two copies that actually exist (1.1.18, 5.0.9) confirming the new 2.x/3.x keys are inert against the current dependency tree. Ref: DEVX-8507 Co-Authored-By: Warp <agent@warp.dev>
Author
|
This PR was generated with Warp. |
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.


Summary
Fixes DEVX-8507: GHSA-rgw5-rvv9-x895 / CVE-2026-69152 ("brace-expansion: DoS via unbounded intermediate arrays, bypassing the CVE-2026-14257 mitigation"), flagged as Dependabot alert #35. The
maxLengthmitigation added inbrace-expansion@5.0.8for the earlier advisory (GHSA-mh99-v99m-4gvg / CVE-2026-14257) only bounded the accumulator incombine(), not the intermediate arrays feeding it — a ~25 KB input can crash Node with an uncatchable OOM, and a ~400 KB padded-sequence input can block the event loop for minutes. Applications already on 5.0.8 are affected.This repo had two vulnerable copies of
brace-expansion, both only inpackage-lock.jsonand both dev-scope transitive dependencies with no production/runtime exposure:node_modules/brace-expansion— pulled in byminimatch@3.1.5(^1.1.7, via@eslint/eslintrc), was 1.1.16, needed>= 1.1.18.node_modules/@typescript-eslint/typescript-estree/node_modules/brace-expansion— pulled in byminimatch@10.2.6(requestingbrace-expansion ^5.0.8, via@typescript-eslint/typescript-estree), was 5.0.8, needed>= 5.0.9.Alert 35 is
auto_dismissedby an auto-triage rule for dev-scope transitive deps, so Dependabot will not open a PR for it — this fix was made explicitly instead.Changes
Updated the
overridesblock inpackage.json. Replaced the prior"brace-expansion@>=3.0.0 <5.0.7": "5.0.7"pin with one entry per vulnerable major line, each mapped to that line's own first patched version (mirroring the advisory's range → patch mapping exactly, with no cross-major jumps):"brace-expansion@<1.1.18": "1.1.18""brace-expansion@>=2.0.0 <2.1.4": "2.1.4""brace-expansion@>=3.0.0 <3.0.6": "3.0.6""brace-expansion@>=4.0.0 <5.0.9": "5.0.9"A single wide
>=3.0.0 <5.0.9 -> 5.0.9override (an earlier draft of this fix) had two problems: it left the 2.x range (>=2.0.0 <2.1.4) completely uncovered since there was no 2.x key, and5.0.9falls outside normal 3.x/4.x semver-consumer ranges so npm would not force it onto nested consumers requesting exact 3.x/4.x versions, leaving them on vulnerable versions. The per-major mapping above closes both gaps and is a deliberate departure from the old>=3.0.0 <5.0.7pin, which forced 3.x consumers onto the 5.x line —3.0.6is patched and supports Node>=18(vs.5.0.9's20 || >=22engines requirement), so the narrower mapping is strictly safer for engine compatibility. The 2.x and 3.x keys are defense-in-depth for the current dependency tree (no 2.x/3.x copy is currently resolved) and are confirmed inert against it — regenerating the lockfile with the four-entry override produced an identicalpackage-lock.jsonto the previous (1.1.18/5.0.9-only) revision.postcss,sharp, andjs-yamloverride entries untouched.Regenerated
package-lock.jsonvianpm install. No application source, config, or production dependencies were changed.Verification
npm install— regenerated the lockfile; resolved tree unchanged from the prior revision for the copies that actually exist.npm ls brace-expansion --all:1.1.18 >= 1.1.18,5.0.9 >= 5.0.9). Zero copies remain in a vulnerable range.npm audit— nobrace-expansionadvisory remains. Two pre-existing, unrelated advisories remain (nanoid < 3.3.18, high;postcss <= 8.5.22incomplete-fix, moderate) — out of scope for this change, not fixed here.npm run build— succeeded (✓ Compiled successfully,✓ Linting and checking validity of types).npm run lint— succeeded (✔ No ESLint warnings or errors). This is the meaningful regression check since the 5.x copy is consumed by@typescript-eslint.brace-expansion-related entries changed are the two resolved copies (1.1.16 → 1.1.18, 5.0.8 → 5.0.9); the new 2.x/3.x override keys did not add or change any lockfile entries.Ref: DEVX-8507
Co-Authored-By: Warp agent@warp.dev