qnbs · qnbs · Sep 10, 2026 · Sep 10, 2026 · Sep 10, 2026
@@ -6,6 +6,8 @@
 
 **`extract-zip` eliminated from the dependency graph (2026-09-10, Dependabot #86):** **GHSA-7pqw-9j4j-h8q3** (CVSS 8.1, high) and **GHSA-jmr9-qjv8-65gv** (CVSS 8.6) both flagged `extract-zip@2.0.1`, reachable only via `@lhci/cli@0.15.1` → `lighthouse@12.6.1` (hard-pinned exact version) → `puppeteer-core@24.41.0` → `@puppeteer/browsers@2.13.0` → `extract-zip`. No patched `extract-zip` release exists, but `@puppeteer/browsers` 3.x (pulled in by `puppeteer-core` ^25.x, pulled in by `lighthouse` 13.x) replaced `extract-zip` with `modern-tar` entirely. Verified live: `@lhci/cli@0.15.1` is the latest published release and hard-pins `lighthouse: "12.6.1"` exactly, so no parent-package upgrade alone could reach the fix — a `pnpm-workspace.yaml` `overrides.lighthouse: "13.4.1"` entry (exact-pinned, not a `>=` floor, since `@lhci/cli@0.15.1` is untested against later Lighthouse majors) forces the whole chain to the modern, `extract-zip`-free stack instead. Confirmed `@lhci/cli`'s own Lighthouse invocation is CLI-subprocess-based (`path.join(require.resolve('lighthouse'), '../../cli/index.js')`, spawned with the stable `--output json --output-path <path>` contract, not an internal JS API import), and lighthouse 13.4.1 keeps the identical `main`/`bin` package-layout convention as 12.6.1, de-risking the major-version jump. `pnpm why extract-zip` returns empty and the package has zero occurrences in `pnpm-lock.yaml` post-fix. Functionally validated: `lhci healthcheck --fatal` passes, and a real `lighthouse@13.4.1` CLI audit against a live URL (Chrome launch, navigation, full performance audit, valid JSON output) succeeded end-to-end. `extract-zip` was never Playwright's browser-binary downloader as two historical entries above incorrectly stated (corrected in place) — it was always this repo's separate Lighthouse CI devDependency chain, matching what `src-tauri/osv-scanner.toml` and `docs/DEPENDABOT-TRIAGE.md` already documented correctly. Both `IgnoredVulns` entries for `extract-zip` removed from `src-tauri/osv-scanner.toml`.
 
+**`adm-zip` (Dependabot #87, GHSA-vwc7-r8mq-g2x9) investigated exhaustively — BLOCKED UPSTREAM / CURRENTLY MITIGATED, not retired (2026-09-10):** unlike `extract-zip` above, no remediation exists here. No patched `adm-zip` release exists (GitHub's advisory API: `first_patched_version: null`); the `>=0.6.0` override is a floor, not a pin — it permits any future release from 0.6.0 upward, currently resolving to 0.6.0 only because that's still the newest published version. No upgrade path removes it either: `@huggingface/transformers@4.2.0` (latest stable) hard-pins `onnxruntime-node` as an exact, mandatory (non-optional) dependency, and `onnxruntime-node@1.29.0` (latest stable, newer than the resolved `1.24.3`) still depends on `adm-zip@^0.6.0` — this is not a stale-pin problem an upgrade solves. The SOLE mitigation for the actual vulnerable operation — `adm-zip` runs inside `onnxruntime-node`'s postinstall script, during `pnpm install`'s lifecycle-script phase, before any bundler is ever involved — is the pre-existing `pnpm-workspace.yaml` `allowBuilds: { onnxruntime-node: false }`, which denies that script outright; a claim that bundler behavior provides a second, independent install-time layer would be wrong, since Vite has no influence over what runs during `pnpm install`. Separately verified as independent evidence about a different question (runtime import reachability, not install-time safety): the shipped app's own JS code never imports `onnxruntime-node` either, because `vite.config.ts`'s `resolve.alias` hardcodes `@huggingface/transformers` to `dist/transformers.web.js` for every bundler/browser consumer (the PWA build and the Tauri WebView frontend alike), bypassing the package's own `exports` map entirely; that file has zero real reference to `onnxruntime-node` (only a stripped build marker), reinforced by this repo's own test suite explicitly mocking that exact web-build path — confirmed via direct package/source inspection, not assumption. A narrow `onnxruntime-node>adm-zip` pnpm override to a stub package was considered and rejected as unnecessary maintenance burden given `allowBuilds` already closes the actual attack surface. `GHSA-vwc7-r8mq-g2x9`'s `IgnoredVulns` entry in `src-tauri/osv-scanner.toml` stays, with its comment expanded to record this evidence trail.
+
 **Release gate (2026-09-09 — v1.28.6):** Main CI/CD run `34408072174` (the push-triggered run for the release-prep merge commit) passed all applicable required and advisory jobs (Quality Gate Node 22+24, Tauri Rust Gate, Security Audit, Verified Signatures, Build, E2E Tests, E2E Deep Coverage, Storybook, Browser Quality (VRT + Lighthouse), `CI Success`); Core Rust Gate legitimately skipped (the release-prep commit touches `src-tauri/`, not `crates/`). Main-push CodeQL SAST run `34408072137` passed; 0 open code-scanning alerts. Before tagging, a dedicated exact-SHA `workflow_dispatch` Tauri qualification (run `34410474256`) on this exact commit passed Windows/Ubuntu/macOS — this recovery's own release discipline, on top of the standard tag-triggered qualification below. The tag-triggered `Tauri desktop build` workflow `34411937761` passed all 5 jobs (`Verify release tag`, `Bundle` for windows-latest/ubuntu-22.04/macos-latest, `GitHub Release`); the tag-triggered `CI / CD` run `34411937709` independently passed all applicable jobs including `E2E Tests (Playwright)`. A parallel `Docker` workflow (`34411937646`) built and pushed `ghcr.io/qnbs/worldscript-studio:1.28.6` (digest `sha256:8fbaed94388c2bcce7b0caf182497f711748e490fdc467b0941c8cadcc77f312`). The release publishes the same asset shape as v1.28.4/v1.28.3: Linux x86_64 (rpm/deb/AppImage) and Windows x86_64 (msi/exe) artifacts with corresponding Minisign `.sig` files; macOS arm64 ships an unsigned `.dmg` installer plus a signed `.app.tar.gz` updater bundle (`.sig`) — no separate `.dmg.sig`; `latest.json` present; all 14 release assets uploaded successfully. Platform code-signing and notarization remain separate claims. No macOS x86_64 artifact, matching prior releases — Intel-macOS remains a gated qualification lane (ADR-0021). Landed via PR #678 (Tauri plugin Rust/npm version-parity fix + permanent CI guard), PR #679 (CHANGELOG completeness-gate PR-number reference fix), and PR #680 (version bump + CHANGELOG/TODO/README release truth).
 
 **Release gate (2026-09-09 — v1.28.5, desktop release failed):** Tag `v1.28.5` was created on commit `590481189c0f9980f71b4081f4a6f8fccef7388d` via PR #676's release-prep merge; the tag itself is permanently kept as-is (never deleted, moved, or re-tagged) as the historical record of this failure. Main-push CI/CD run `34353928731` and CodeQL SAST run `34353928691` both passed on the release-prep commit. The tag-triggered `Tauri desktop build` workflow `34357232967` ran `Verify release tag` successfully, then **failed on every platform's `Bundle` job individually** (`windows-latest`, `ubuntu-22.04`, `macos-latest` each failed): `tauri-plugin-http` resolved to Rust 2.6.0 vs npm 2.5.9 and `tauri-plugin-notification` resolved to Rust 2.4.0 vs npm 2.3.3, both drifted after #661's Rust-only Dependabot bump, and `tauri build` hard-rejects a Rust/npm major.minor mismatch; the `GitHub Release` job was correctly skipped since no bundle job produced assets — no GitHub Release, installer, or updater artifact was ever published for `v1.28.5`. The tag-triggered `CI / CD` run `34357232902` passed independently (it does not depend on the Tauri bundle jobs). A parallel `Docker` workflow (`34357233022`) succeeded and pushed `ghcr.io/qnbs/worldscript-studio:1.28.5` (digest `sha256:3e5ac677979de21fb45ecb2899fb824302047c114829e54265d090928862f940`) — the desktop-build failure did not affect the separately-triggered container publish. Root-caused and fixed in `v1.28.6` above via PR #678.

@@ -100,13 +100,33 @@ rechecked before expiry and removed as soon as an upstream fix or dependency-pat
 possible. Review each cluster against current upstream status before changing any deadline.
 
 **2026-09-10 update: both `extract-zip` ignores retired.** A `pnpm-workspace.yaml`
-`overrides.lighthouse: ">=13.4.1"` entry forces `@lhci/cli`'s Lighthouse/Puppeteer chain onto a
+`overrides.lighthouse: "13.4.1"` entry (exact-pinned, not a `>=` floor — `@lhci/cli@0.15.1` is
+untested against later Lighthouse majors) forces `@lhci/cli`'s Lighthouse/Puppeteer chain onto a
 version whose `@puppeteer/browsers` dependency replaced `extract-zip` with `modern-tar` —
 eliminating the package from the resolved graph entirely (`pnpm why extract-zip` now returns
 nothing). `GHSA-jmr9-qjv8-65gv` and `GHSA-7pqw-9j4j-h8q3` are removed from
 `src-tauri/osv-scanner.toml`; the cluster total drops from 21 to 19. See AUDIT.md's 2026-09-10
 entry for the full verification trail.
 
+**2026-09-10 update: `adm-zip` (`GHSA-vwc7-r8mq-g2x9`) investigated exhaustively, remains
+accepted risk — BLOCKED UPSTREAM / CURRENTLY MITIGATED, not retired.** No patched `adm-zip`
+release exists (GitHub's advisory API: `first_patched_version: null`); the `>=0.6.0` override is a
+floor permitting any future release from 0.6.0 upward, currently resolving to 0.6.0 only because
+that is still the newest published version. No upgrade path removes it either:
+`@huggingface/transformers@4.2.0` (latest stable) hard-pins `onnxruntime-node` as an exact,
+mandatory dependency, and `onnxruntime-node@1.29.0` (latest stable) still depends on
+`adm-zip@^0.6.0`. The SOLE mitigation for the actual vulnerable operation — `adm-zip` runs inside
+`onnxruntime-node`'s postinstall script, during `pnpm install`'s lifecycle-script phase, before any
+bundler is involved — remains `allowBuilds: onnxruntime-node=false`, which denies that script
+outright. Separately (not as a second install-time control for the same risk, but as independent
+evidence about a different question): the shipped app's own JS code never imports the
+`onnxruntime-node` module either, since `vite.config.ts`'s `resolve.alias` hardcodes
+`@huggingface/transformers` to `dist/transformers.web.js` for every bundler/browser consumer (the
+PWA build and the Tauri WebView frontend alike), bypassing the package's own `exports` map
+entirely; that file has zero real reference to `onnxruntime-node`, reinforced by this repo's own
+test suite explicitly mocking that exact web-build path. See `src-tauri/osv-scanner.toml`'s
+expanded comment for the full evidence trail.
+
 ## Special-attention dependencies
 
 These need more than a changelog skim because of documented quirks elsewhere in this repo:

@@ -133,20 +133,40 @@ reason = "unic-ucd-ident 0.9.0: unmaintained Unicode data crate; final version;
 
 # adm-zip@0.6.0 (CVE-2026-76845 / GHSA-vwc7-r8mq-g2x9, CVSS 6.8): symlink-following
 # path traversal on extraction with overwrite enabled, when an attacker can
-# pre-place a symlink at the extraction destination. 0.6.0 is the latest
-# published release with no patched version yet — pnpm.overrides already pins
-# the newest available release (see pnpm-workspace.yaml) but cannot fix an
-# unpatched vulnerability. adm-zip is a dependency of onnxruntime-node's own
-# postinstall/build script (which extracts its prebuilt native binary into
+# pre-place a symlink at the extraction destination. No patched version exists
+# yet (GitHub's advisory API reports first_patched_version: null) — the
+# `adm-zip: ">=0.6.0"` pnpm override is a floor, not a pin: it permits any
+# future adm-zip release from 0.6.0 upward, and the lockfile currently resolves
+# the range to 0.6.0 because that is still the newest published version. No
+# upgrade path exists either: @huggingface/transformers@4.2.0 (latest stable)
+# hard-pins onnxruntime-node to an exact, mandatory (non-optional) "1.24.3",
+# and even onnxruntime-node@1.29.0 (latest stable, 2026-09-10) still depends on
+# adm-zip@^0.6.0 — this is not a stale-pin problem an upgrade solves. adm-zip
+# is a dependency of onnxruntime-node's own postinstall/build script (which
+# extracts its prebuilt native binary into
 # `path.join(os.tmpdir(), 'onnxruntime-node-pkgs_<timestamp>')` — a shared,
 # timestamp-named system temp directory, NOT a project-local one — verified
-# directly against onnxruntime-node@1.24.3's own install-utils.js). The actual
-# mitigation is that `pnpm-workspace.yaml`'s `allowBuilds: { onnxruntime-node:
-# false }` denies this package's lifecycle scripts outright, so this code path
-# never executes during a normal `pnpm install` in this repo, in CI, or in the
-# shipped app. If that `allowBuilds` entry is ever relaxed or removed, this
-# exposure model must be re-evaluated — the temp-directory extraction target
-# is not inherently safe on its own.
+# directly against onnxruntime-node@1.24.3's own install-utils.js). The SOLE
+# mitigation for that install-time extraction is `pnpm-workspace.yaml`'s
+# `allowBuilds: { onnxruntime-node: false }`, which denies this package's
+# lifecycle scripts outright, so the postinstall extraction never runs during
+# a normal `pnpm install` in this repo, in CI, or in the shipped app — Vite's
+# bundling behavior below is a separate fact about a different question and
+# does NOT independently protect against this install-time script, since
+# `pnpm install`'s lifecycle-script phase runs before Vite or any bundler ever
+# resolves anything. Separately, verified 2026-09-10: even the shipped app's
+# own JS code never imports the onnxruntime-node module this postinstall
+# extracts a binary for — `vite.config.ts`'s `resolve.alias` hardcodes
+# `@huggingface/transformers` to `dist/transformers.web.js` for every
+# bundler/browser consumer (the PWA build and the Tauri WebView frontend
+# alike), bypassing the package's own conditional `exports` map entirely, and
+# that file contains zero real reference to onnxruntime-node (confirmed by
+# inspecting the published package) — this repo's own test suite reinforces
+# the same boundary by explicitly mocking that exact web-build path rather
+# than letting real module resolution occur. If that `allowBuilds` entry is
+# ever relaxed/removed, this exposure model must be re-evaluated — the
+# temp-directory extraction target is not inherently safe on its own, and the
+# Vite-alias fact does not substitute for it.
 
 [[IgnoredVulns]]
 id = "GHSA-vwc7-r8mq-g2x9"