LTS-4700 / LTS-4699: js-yaml -> 4.3.1 + 3.15.1, fast-uri -> 3.1.5, brace-expansion -> 1.1.18 + 2.1.4

All four are transitive dev-only dependencies patched through the existing
`overrides` block. Every high-severity advisory in `npm audit` is cleared:
0 high, 0 critical (was 3 high).

js-yaml (LTS-4700, GHSA-5p4m-2wfm-xmqj, CVSS 7.5)
  resolveYamlOmap() enforced key uniqueness with a linear objectKeys.indexOf()
  scan per entry, making !!omap resolution O(n^2) inside yaml.load(). !!omap is
  in the default schema, so a plain yaml.load(untrusted) is affected.

  This repo carries TWO vulnerable copies, not one:
    node_modules/js-yaml                                          4.3.0
    node_modules/js-yaml-cloudformation-schema/node_modules/js-yaml  3.15.0
  Affected range is "3.0.0 - 3.15.0 || 4.0.0 - 4.3.0", so both are in scope.

  A bare `js-yaml` override would force the 3.x consumer onto 4.x, which is a
  breaking API change (4.x removed safeLoad). Used the version-scoped form the
  block already uses for brace-expansion@1/@2:
    "js-yaml@3": "^3.15.1"
    "js-yaml@4": "^4.3.1"
  Both backport the same fix — a hash lookup replacing the linear scan.

fast-uri (LTS-4699, GHSA-7p8r-x3mc-p8w7, CVSS 7.5)
  fast-uri does not treat a literal backslash as an authority delimiter while
  Node's WHATWG URL normalises it, so the two disagree on the host of the same
  string — a policy/use desync for any allowlist or SSRF filter built on it.

  The override was pinned exactly at 3.1.4, which is INSIDE the affected range
  (3.0.0 - 3.1.4). The companion advisory GHSA-v2hh-gcrm-f6hx quotes 3.1.4 as
  patched; the second one extends the range to include it. Real floor is 3.1.5.

brace-expansion (not ticketed, 2 high advisories per major line)
  GHSA-mh99-v99m-4gvg + GHSA-rgw5-rvv9-x895. Pinned at 1.1.16 / 2.1.2, both
  vulnerable; 1.1.17 only fixes the first of the two. Floors are 1.1.18 / 2.1.4.
  Same overrides block, same audit run — folded in rather than left to re-raise.

Exact pins -> carets
  The three stale pins here were all exact, which is why they aged into the
  vulnerable range. Caret stays within the major (no breaking jump) and lets the
  next patch land without a PR. Matches the `ip-address: ^10.4.0` precedent from
  LTS-4657 in this repo.

Verification
  - npm audit: 0 high / 0 critical (6 moderate remain: qs, uuid — both below the
    repo's own audit-level=high gate, both unticketed)
  - npm ci from a clean tree: 854 packages, no peer/engine errors
  - npm ls confirms the real installed tree: js-yaml@4.3.1 + js-yaml@3.15.1
    (3.x consumer stayed on 3.x), fast-uri@3.1.5, brace-expansion@1.1.18 + 2.1.4
  - advisory PoC replayed against BOTH installed js-yaml copies: growth is now
    ~2x per doubling (linear; the quadratic signature is ~4x), and duplicate-key
    rejection still throws YAMLException on each
  - lockfile diff touches only these five entries — no collateral bumps
  - all five targets published 2026-07-30/31, clearing .npmrc min-release-age=7

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: MihirR-BS

package-lock.json

@@ -31,9 +31,11 @@
     "jws": "4.0.1",
     "fast-xml-parser": "^5.10.1",
     "basic-ftp": "^5.3.1",
-    "fast-uri": "3.1.4",
-    "brace-expansion@1": "1.1.16",
-    "brace-expansion@2": "2.1.2",
+    "fast-uri": "^3.1.5",
+    "brace-expansion@1": "^1.1.18",
+    "brace-expansion@2": "^2.1.4",
+    "js-yaml@3": "^3.15.1",
+    "js-yaml@4": "^4.3.1",
     "fast-xml-builder": "1.2.1",
     "path-expression-matcher": "1.6.1",
     "tmp": "0.2.7",