chore(deps): bump brace-expansion to 1.1.18 in yarn.lock (CVE-2026-69152)

[anupamme]

Summary

Re-resolve brace-expansion@^1.1.7 from 1.1.11 to 1.1.18 in yarn.lock to clear
CVE-2026-69152 (unbounded intermediate arrays / DoS). Lockfile-only, 3 lines.

Why no manifest change

1.1.18 is the maintenance-v1 fix and is already inside the declared ^1.1.7 range,
so no package.json or resolutions edit is needed. A plain yarn install will not
pick it up either — yarn v1 keeps any existing lockfile entry that still satisfies its
range — so the entry was dropped and re-resolved to force the bump.

The only other range in the tree, brace-expansion@^5.0.8, was already at 5.0.9.
Those are the two entries in the lockfile, and both are now at or above the fixed
versions for this advisory.

Dropped from this PR

This PR originally upgraded glob v7 → v10 and jest v26 → v29. Both were reverted.

They did not clear the advisory. jest still depends on glob v7 (@jest/reporters,
jest-config, jest-runtime) and test-exclude on glob@^7.1.6, so
minimatch@3 → brace-expansion@^1.1.7 stays in the tree either way. Re-resolving that
range is what actually fixes it.

The glob bump silently broke asset emission. glob v7 matched ignore patterns
against the returned paths, and every call site here passes an absolute pattern, so the
relative pattern node_modules/**/* never matched — the option was a no-op. glob v9+
matches ignore relative to cwd, so for a build whose dependencies live in
./node_modules (the normal case) it matches everything under it. All three call sites
— the two globSync calls in asset-relocator.js and the shared-library glob in
sharedlib-emit.js — returned nothing:

cwd     = test/project-chunking
pattern = <cwd>/node_modules/@img/sharp-linux-x64/**/*
glob  7 + ignore -> 5 matches
glob 10 + ignore -> 0 matches

yarn test failed on should correctly run webpack build project-chunking: sharp's
native binaries were no longer emitted, so chunks/sharp-chunk.js lost its
ab+"sharp-linux-x64/lib/..." reference and dist/assets/ lost build, vendor and
sharp-{,libvips-}linux{,musl}-x64. webpack still reported zero errors, so this broke
at runtime rather than at build time.

glob is a runtime dependencies entry of a package consumed by ncc, so a major bump
is breaking for downstream consumers and belongs in its own PR — one targeting v13
(v10 is itself deprecated on npm) with Windows coverage, since v9+ also changed
backslash escaping and result separators.

Not covered here

npm (pulled in by semantic-release v25 → @semantic-release/npm v13) vendors
brace-expansion 5.0.7 as a bundled dependency. Bundled deps do not appear in
yarn.lock, so lockfile scanners will not flag it and it cannot be overridden from
here. It clears when npm ships a release bundling 5.0.9.

Verification

On Node 22: yarn test 85/85 passing, yarn test-coverage meeting thresholds,
yarn install --frozen-lockfile clean from scratch, and test/project-chunking
emitting the same asset set as main.

---

Original vulnerability report and first commit by
OrbisAI Security.

Co-authored-by: Anupam Mediratta mediratta@gmail.com

[styfle]

Present in dependency tree, not confirmed reachable

Lets use AI to confirm if its reachable, otherwise we can close, right?

[anupamme]

The vulnerability is not reachable. All glob patterns in this codebase are constructed from hardcoded extglob strings (@(js|json|node), @(dylib|so?(.*)) and resolved filesystem paths; none contain brace expansion syntax ({}), and there's no path for untrusted input to reach brace expansion's parser.

It is recommended to keep as a defence-in-depth practice; however, it is safe to close as well.

[github-actions]

🎉 This PR is included in version 1.10.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀