fix(deps): bump brace-expansion out of all three vulnerable ranges (GHSA-3jxr-9vmj-r5cp)

[Prekzursil]

Dependabot alert #274 — brace-expansion (high)

Advisory: GHSA-3jxr-9vmj-r5cp / CVE-2026-13149 — DoS via exponential-time expansion of consecutive non-expanding {} groups.
Manifest: app/package-lock.json (scope: development)

Why the reported floor was not enough

The alert reports first_patched_version: 5.0.7. That is only the floor for one of the advisory's three disjoint vulnerable ranges:

vulnerable range	patched in
< 1.1.16	1.1.16
>= 2.0.0, < 2.1.2	2.1.2
>= 3.0.0, < 5.0.7	5.0.7

This lockfile resolved brace-expansion at seven places spanning all three ranges. Bumping everything to >= 5.0.7 would have crossed a major on parents that constrain ^1.1.7 and ^2.0.2.

Fix — newest release within each existing major

lockfile path	before	after	range cleared
@electron/asar/node_modules/brace-expansion	1.1.15	1.1.16	< 1.1.16
dir-compare/node_modules/brace-expansion	1.1.15	1.1.16	< 1.1.16
glob/node_modules/brace-expansion	1.1.15	1.1.16	< 1.1.16
@electron/universal/node_modules/brace-expansion	2.1.1	2.1.2	>= 2.0.0, < 2.1.2
filelist/node_modules/brace-expansion	2.1.1	2.1.2	>= 2.0.0, < 2.1.2
test-exclude/node_modules/brace-expansion	2.1.1	2.1.2	>= 2.0.0, < 2.1.2
brace-expansion (hoisted, via minimatch)	5.0.6	5.0.8	>= 3.0.0, < 5.0.7

No major boundary is crossed; every parent constraint (minimatch ^1.1.7 / ^2.0.2 / ^5.0.5) still resolves. Lockfile-only — no declared range is pinned to an exact version, so Dependabot can keep proposing future upgrades.

Verification

• Independent checker asserts each of the 7 resolved versions against all three ranges. It was first run against the pre-fix lockfile as a control and correctly reported 7/7 vulnerable; against this branch it reports 0/7 vulnerable.
• brace-expansion@5.0.8 narrows engines.node from 18 || 20 || >=22 to 20 || >=22. All three workflows pin node-version: "20", so this is satisfied.

[Prekzursil]

Why quality is red here, and why it is not caused by this PR

gate-deps (osv-scanner) is the only failing step — steps 1-16 (lint/format, tsc app, tsc render-cli, basedpyright, pytest, vitest app, opengrep) all passed. Reading the job log via the jobs API (2.47 MB / 21,606 lines — confirmed non-empty before trusting it):

osv-scanner exited 1 with a real finding table, so this is not the deps.dev / "service unavailable" infrastructure case — it is a genuine vulnerability report.

Controlled measurement: same tool version, both lockfile states

I ran the CI-pinned osv-scanner 2.3.8 locally with the exact CI flags against blob-exact extractions (git archive, so LF like CI checks out) of both states:

state	commit	result	exit
origin/main (this PR's base)	97600e8	9 packages / 18 vulnerabilities	1
this branch	b8e84f3	8 packages / 14 vulnerabilities	1

Failure-set diff: 6 rows cleared, 2 rows appear — and the 2 "new" rows are the same advisory at a higher version, not a new advisory:

• cleared (6): GHSA-3jxr-9vmj-r5cp at 1.1.15 / 2.1.1 / 5.0.6 and GHSA-mh99-v99m-4gvg at 1.1.15 / 2.1.1 / 5.0.6
• remaining (2): GHSA-mh99-v99m-4gvg at 1.1.16 / 2.1.2

So this PR fully clears its target advisory GHSA-3jxr-9vmj-r5cp and strictly reduces the total from 18 → 14. main measured today fails identically (in fact worse). Its last green run was 2026-07-18 at this very commit; the database, not the code, is what changed.

The blocker: a second advisory published yesterday

GHSA-mh99-v99m-4gvg — "brace-expansion: DoS via unbounded expansion length causing an out-of-memory process crash" — was published 2026-07-24 21:53 UTC. Range <= 5.0.7, patched only in 5.0.8. There is no fix in the 1.x or 2.x lines.

The hoisted 5.0.6 → 5.0.8 bump in this PR clears it. The 1.x and 2.x entries cannot be cleared by any in-major upgrade.

Forcing everything to 5.0.8 is NOT a viable workaround

I checked the export shape mechanically rather than assuming:

1.1.16 export typeof : function        1.1.16 call a{b,c} : [ 'ab', 'ac' ]
5.0.8  export typeof : object          5.0.8  call THREW  : "is not a function"
5.0.8  keys          : [ 'EXPANSION_MAX', 'EXPANSION_MAX_LENGTH', 'expand' ]

brace-expansion 5.x moved from module.exports = expand to a named { expand } export. minimatch 3.x does var expand = require('brace-expansion'); expand(pattern), so an override forcing 5.x onto the ^1.1.7 / ^2.0.2 consumers would throw at runtime. That is a breaking transitive major migration, not a dependency bump.

Recommendation

This PR is correct and strictly improves the gate, but cannot make it green on its own. Reaching the repo's clean-zero policy additionally needs, all pre-existing and independent of this change:

package	current	needs
tar (dev)	7.5.16	7.5.21 (5 advisories, one 9.2 Critical)
fast-uri (dev)	3.1.2	3.1.4 (2 advisories; also in render-cli)
js-yaml	4.2.0	4.3.0
postcss (dev)	8.5.15	8.5.18 (also in render-cli)
brace-expansion 1.x/2.x	1.1.16 / 2.1.2	no in-major fix — needs a minimatch migration or a reasoned osv-scanner.toml ignore per the policy in that file

Left open deliberately rather than merged: the required quality check is genuinely red, and I did not use --admin.

[Prekzursil]

Update — residual swept: 18 → 2 vulnerabilities, CRITICAL cleared

Pushed b4ef66c adding bounded security floors for the four packages I measured as residual. All four are in-major patch lifts; every existing parent constraint still resolves, and no major boundary is crossed.

Measured with the CI-pinned osv-scanner 2.3.8 on blob-exact git archive extracts

state	commit	packages	vulnerabilities	breakdown
origin/main	97600e8	9	18	1 Critical, 14 High, 3 Medium
branch, first push	b8e84f3	8	14	1 Critical, 10 High, 3 Medium
branch now	b4ef66c	2	2	0 Critical, 2 High, 0 Medium

The tar CRITICAL — and why the critical's own floor was not enough

tar 7.5.16 carried five advisories, and the highest floor comes from a medium, not the critical:

advisory	severity	range	patched
GHSA-23hp-3jrh-7fpw	CRITICAL	<= 7.5.18	7.5.19
GHSA-8x88-c5mf-7j5w	high	<= 7.5.17	7.5.18
GHSA-w8wr-v893-vjvp	medium	<= 7.5.17	7.5.18
GHSA-gvwx-54wh-qm9j	medium	<= 7.5.16	7.5.17
GHSA-r292-9mhp-454m	medium	<= 7.5.20	7.5.21

Fixing to the critical's own 7.5.19 would have left two advisories live. Effective floor 7.5.21; resolved 7.5.22.

All four floors

package	before → after	override	upper bound
tar (dev)	7.5.16 → 7.5.22	^7.5.21 = >=7.5.21 <8	guard — no 8.x exists
fast-uri (dev, both lockfiles)	3.1.2 → 3.1.4	^3.1.4 = >=3.1.4 <4	load-bearing — 4.1.1 exists
js-yaml (runtime)	4.2.0 → 4.3.0	^4.3.0 = >=4.3.0 <5	load-bearing — 5.2.2 exists
postcss (dev, both lockfiles)	8.5.15 → 8.5.23	^8.5.18 = >=8.5.18 <9	guard — no 9.x exists

Bounded floors, never exact pins, using the caret form already established here for security floors (esbuild ^0.28.1, undici ^6.27.0, render-cli ws ^8.21.0). Note fast-uri and js-yaml advisories each carry multiple disjoint ranges (fast-uri: 2.x/3.x/4.x; js-yaml: 3.x/4.x) — the floors were chosen per-line, same discipline as brace-expansion.

js-yaml is the only one on the runtime path (via electron-updater), so the build/test gates are the meaningful check on it.

Exact remaining residual — and why it has no non-breaking fix

GHSA-mh99-v99m-4gvg | 7.5 | npm | brace-expansion (dev) | 1.1.16 | 5.0.8 | app/package-lock.json
GHSA-mh99-v99m-4gvg | 7.5 | npm | brace-expansion (dev) | 2.1.2  | 5.0.8 | app/package-lock.json

Published 2026-07-24, range <= 5.0.7, fixed only in 5.0.8 — there is no 1.x or 2.x remedy. I measured both candidate upgrade paths and both break at runtime:

Path 1 — force brace-expansion to 5.x:

1.1.16 typeof: function → one('a{b,c}') = ['ab','ac']
5.0.8  typeof: object   → five('a{b,c}') THREW "is not a function"
       keys: [EXPANSION_MAX, EXPANSION_MAX_LENGTH, expand]

minimatch 3.x does expand = require('brace-expansion'); expand(p).

Path 2 — force the parent minimatch to 10.x:

minimatch 3.1.2 typeof: function → three('a/b.js','a/*.js') = true
minimatch 10.x  typeof: object   → ten(...) THREW "is not a function"
       keys: [minimatch, sep, GLOBSTAR, filter, defaults, braceExpand, makeRe, match]

@electron/asar (^3.0.4), dir-compare (^3.0.5) and glob (^3.1.1) all require minimatch 3.x and call it as a function.

The three 1.1.16 entries come from @electron/asar, dir-compare and glob → minimatch 3.1.5; the three 2.1.2 entries from @electron/universal/test-exclude → minimatch 9.0.9 and filelist → minimatch 5.1.9. The real fix is upstream in the electron-builder chain moving off minimatch 3.x.

Status

gate-deps will still exit 1 on these 2 dev-scope findings, so this PR remains blocked and I have not merged it. I did not use --admin, and I deliberately did not add an osv-scanner.toml ignore — that file's policy allows one for a "genuinely-unfixable vuln … with a reason + dated review note", which this now demonstrably is, but that is a security-posture decision for the maintainer, not something to slip into a dependency PR.

If you want the ignore, the evidence above is the review note; scoped to GHSA-mh99-v99m-4gvg it would take gate-deps to exit 0. Caveat worth recording: an osv-scanner ignore is keyed by vuln ID, not by version, so it would also mask a future regression of the hoisted 5.0.8 entry below 5.0.8.

[Prekzursil]

gate-deps is GREEN — and the whole quality gate passes. Blocked by a separate, pre-existing repo-config deadlock.

Pushed 42fe7b2 adding one narrow, dated [[IgnoredVulns]] entry for GHSA-mh99-v99m-4gvg only. Nothing else was folded in to reach green.

CI result, quoted

quality — pass, 5m12s (run). All 18 steps success, including step 17 gate-deps osv-scanner and step 18 charter-check (previously skipped because gate-deps failed). The gate's own output:

GHSA-mh99-v99m-4gvg and 1 alias have been filtered out because: ...   (x2)
Filtered 2 vulnerabilities from output
No issues found

Identical to my local run of the CI-pinned osv-scanner 2.3.8 over a blob-exact git archive extract — two independent signals agree.

Measured before → after

state	commit	packages	vulnerabilities
origin/main	97600e8	9	18 (1 Critical, 14 High, 3 Medium)
+ upgrades	b4ef66c	2	2 (0 Critical)
+ one ignore	42fe7b2	0	0 — No issues found

Detector validated in all three states before trusting the green

A config that silently disables scanning is the failure mode here, so I controlled for it rather than trusting the green:

state	exit	Filtered line	behaviour
unknown key injected	127	absent	aborts without scanning — Failed to read config file: unknown keys in config file: IgnoredVulns.bogusUnknownKey. Fail-closed, not fail-open.
ignore id pointed at a non-matching GHSA	1	absent	both findings return — proves the suppression is narrowly scoped to this one id
this entry as committed	0	Filtered 2 vulnerabilities from output	No issues found

Two notes for future readers: an unknown key yields exit 127, not 130; and osv-scanner 2.3.8 aborts on a bad config rather than falling back to an empty one, so a broken config cannot masquerade as a clean scan.

Schema kept to the three valid keys only — id, ignoreUntil (bare unquoted date 2026-10-25), reason.

Why this PR still cannot merge — NOT this change

gh pr merge (no --admin) returns: "the base branch policy prohibits the merge." The cause is an active repository ruleset, separate from branch protection:

• ruleset 18276553 — "CodeQL security red-blocker (any severity)", enforcement active, targeting ~DEFAULT_BRANCH, rule code_scanning with security_alerts_threshold: all / alerts_threshold: all, and bypass_actors: [].
• CodeQL therefore must supply results for the PR — but it does not run. code-scanning/default-setup reports state: not-configured, and the most recent CodeQL analysis on this repo is 2026-07-18T00:21:14. No CodeQL run exists on this branch; only quality ran.
• Open code-scanning alerts: 0. So this is not an alert blocking the merge — it is the absence of the required analysis.

Corroboration that this is repo-wide and pre-existing, not caused by this PR:

• the last merge into main was chore(deps): bump the npm-app-render-cli-patch-minor group in /app/render-cli with 4 updates #296 at 2026-07-18T00:19:25 — two minutes before the final CodeQL analysis;
• all five open PRs are BLOCKED, including four untouched Dependabot PRs (chore(deps): bump actions/checkout from 6.0.3 to 6.1.0 in the github-actions-root-patch-minor group #299, chore(deps-dev): bump electron from 43.1.0 to 43.2.0 in /app in the npm-app-patch-minor group #300, chore(deps): bump the npm-app-render-cli-patch-minor group across 1 directory with 6 updates #301, chore(deps): bump the pip-sidecar-patch-minor group in /sidecar with 9 updates #302).

Answering the question directly: is the tar CRITICAL closed on main?

No — not yet. Read from main authoritatively:

package	main	this branch
tar	7.5.16 (CVSS 9.2 GHSA-23hp-3jrh-7fpw live)	7.5.22
fast-uri	3.1.2	3.1.4
js-yaml	4.2.0	4.3.0
postcss	8.5.15	8.5.23

main also still carries 0 [[IgnoredVulns]] blocks. The fix is verified and ready on this branch; it lands the moment the merge policy can be satisfied.

What unblocks it (maintainer action — I did not touch protection, rulesets, or use --admin)

Any one of:

1. Re-enable CodeQL (default setup or an advanced-setup workflow) so the ruleset's required analysis is produced — this also unblocks the four stuck Dependabot PRs;
2. adjust/disable ruleset 18276553;
3. gh pr merge 303 --admin as a one-off, accepting the documented green above.

If you prefer it to land by itself once the policy clears, gh pr merge 303 --squash --delete-branch --auto respects the ruleset fully and is not a bypass — I deliberately did not enable it, since resolving the deadlock is a maintainer decision.