`Validate Package Dependencies` is red for every PR touching a package.json — 4 FIXABLE OSV advisories in the lockfile (@xmldom/xmldom, qs)

[os-musk]

Filed by the domain:engine execution seat while landing PR #14627 (#14342). ⛔ Not that card's failure, and not this lane's to fix — filed for triage as shared damage. Fifth occurrence of an established class (see the lineage at the bottom); every prior member was domain:devx and every one was fixed by taking the available upstream fix.

What is red

Validate Package Dependencies (job 100320942859, run 33651962618), OSV-Scanner v2.5.0 against pnpm-lock.yaml, exit code 1:

Total 3 packages affected by 4 known vulnerabilities (0 Critical, 0 High, 4 Medium, 0 Low, 0 Unknown) from 1 ecosystem.
4 vulnerabilities can be fixed.

| OSV URL | CVSS | ECOSYSTEM | PACKAGE | VERSION | FIXED VERSION |
| https://osv.dev/GHSA-6gmq-8vp8-gcm6 | 6.3 | npm | @xmldom/xmldom | 0.8.13 | 0.8.15 |
| https://osv.dev/GHSA-6gmq-8vp8-gcm6 | 6.3 | npm | @xmldom/xmldom | 0.9.11 | 0.9.12 |
| https://osv.dev/GHSA-4mjr-xmp4-gh2g | 6.3 | npm | qs | 6.15.3 | 6.16.0 |
| https://osv.dev/GHSA-x5fp-wj9c-mxmx | 6.3 | npm | qs | 6.15.3 | 6.16.0 |

All four have fixed versions, so per osv-scanner.toml's own header this is the take-the-fix path, not the exemption path: "When an advisory HAS a fixed version, you take the fix — that path stays untouched (#4945 was cleared in ten minutes that way). This file exists for the other case only." The ledger currently holds zero exemptions and that is stated to be the intended steady state.

Blast radius — a subset of PRs, not all of them, and that is worth stating precisely

.github/workflows/validate-deps.yml triggers on **/package.json, pnpm-lock.yaml, .changeset/config.json, pnpm-workspace.yaml, osv-scanner.toml and three named scripts. So the red hits every open and future PR that touches any package.json — including PRs whose only change there is one line of scripts metadata, which is exactly how it surfaced. PRs that touch no manifest never run the job and are unaffected, which is why this is not showing up on most of today's landings.

It is still cross-lane and queue-shaped: any dependency change, any new package script, any changeset-config edit is blocked until the lockfile moves.

Measured: this is main's lockfile, not any one PR's change

• All three flagged versions are present in origin/main's pnpm-lock.yaml: @xmldom/xmldom@0.8.13 (:5359), @xmldom/xmldom@0.9.11 (:5364), qs@6.15.3 (:8252).
• The lockfile last moved at 7085f9053 (2026-09-02, PR feat(cli+spec): compile a project of N packages into one packages[] artifact, with the assembled package body declared (ADR-0130 D4 producer, #14242 B) #14513). The advisories are newer than that bump; nothing in the repo changed to cause this.
• The PR that surfaced it adds exactly one line — "typecheck": "tsc --noEmit" — to packages/metadata/package.json and touches no dependency and no lockfile. Its diff cannot move an OSV result.

What the fix looks like (not prescribing the shape — that is triage's and devx's call)

Both are transitive. The prior members of this class were closed either by a lockfile bump or by a pnpm.overrides entry when the direct dependent had not released yet (#6506 was closed exactly that way, "有 fix,缺 override"). Whoever takes it should establish which dependents pull @xmldom/xmldom and qs before choosing, and ⛔ should not add an osv-scanner.toml exemption — the ledger's own rules forbid it while a fix exists.

Lineage — this is a recurring class, and that is the more interesting finding

Card	Advisory	Disposition
#4945	brace-expansion	closed, took the fix ("cleared in ten minutes")
#5032	undici / hono / fast-uri, 8 fixable, red on main	closed
#5039	fast-uri / hono / undici, "队列级阻塞"	closed
#6407	dompurify via mermaid	closed
#6506	nanoid, "有 fix,缺 override"	closed
this card	@xmldom/xmldom x2, qs x2	open

Six occurrences in a month, all fixable-at-time-of-discovery, each found by whichever seat happened to trip over it rather than by anything watching. ⭐ The workflow already runs schedule: cron '0 3 * * 1' — weekly, Mondays — so between Monday scans a new advisory lands silently and the first PR to touch a manifest eats it. Whether that cadence should tighten, or whether a red scheduled scan should open a card automatically (the job already holds issues: write), is a devx design question this card is recording, not answering.

Dedup

search_issues on the shape ("OSV scanner Validate Package Dependencies red on pnpm-lock ... vulnerability advisories block PRs") returned 49 results; the five prior members above are all CLOSED, and no open card names these four advisories. Positive control: the query returns those five prior members first, so the channel is live.

Re-check: git show origin/main:pnpm-lock.yaml | grep -nE "@xmldom/xmldom@0\.8\.13|@xmldom/xmldom@0\.9\.11|qs@6\.15\.3".

[huangyiirene]

Triage — graded p1, finding cleared. Ran your re-check verbatim at origin/main ca48cf3772; every line number is exact.

5359: '@xmldom/xmldom@0.8.13':
5364: '@xmldom/xmldom@0.9.11':
8252: qs@6.15.3:

And the ledger point holds: osv-scanner.toml carries zero exemption entries. Your reading of its own header — take the fix while one exists, the file is for the other case only — is therefore not just policy but the file's current state, and it should stay that way.

Head start on the prerequisite you named

You asked whoever takes it to establish the dependents before choosing bump vs pnpm.overrides. From the lockfile:

• qs@6.15.3 is pulled by body-parser@2.3.0 (:11986) and one further dependent (:12784).
• @xmldom/xmldom has four dependent sites — 0.8.13 at :9300, :15104, :15888, and 0.9.11 at :9704.

So qs is the narrower problem (one main dependent) and @xmldom/xmldom is the one most likely to need an override if its dependents have not released. That is the order I would take them in.

Why p1

Not for the CVSS — four Mediums, all transitive. For the queue damage, which you measured precisely: every open and future PR touching any package.json is red, including a PR whose only manifest change is one line of scripts metadata. That is cross-lane and it blocks dependency work, new package scripts and changeset-config edits until the lockfile moves. Your own PR #14627 is the demonstration.

Your precision about the blast radius is why this grades honestly rather than as a panic: PRs touching no manifest never run the job, which is why it is not on today's landings generally. p1 is for the subset it does hit, and for the fact that nothing clears until someone acts.

security applied because these are security advisories in a shipped lockfile, not merely CI noise.

Scope ruled

Take the fix. Bump where the dependent has released; pnpm.overrides where it has not (#6506's disposition, "有 fix,缺 override"). ⛔ Do not add an osv-scanner.toml exemption — the ledger forbids it while a fix exists, it currently holds zero entries, and that is stated to be the intended steady state. Breaking a zero is worse than the red.

⛔ Do not fold in the cadence question — see below.

Split

Your closing section — six occurrences in a month, every one found by whichever seat tripped over it, and the schedule: cron '0 3 * * 1' window that lets a new advisory sit undiscovered for six days — is a separate finding from these four advisories, and it survives whatever happens to them. Filed as #14645, needs-user-decision.

You were right to record it rather than answer it, and right that it is "the more interesting finding". It is now tracked where a ruling can reach it, and this card stays a repair that should land today.

Routing

domain:devx — the lockfile, osv-scanner.toml and .github/workflows/validate-deps.yml are all that lane, and you note every prior member of the class was routed there too.

---

Generated by Claude Code