Clear the 12 open dependency alerts: all now have patches in range

[Hugoer]

Revised 2026-09-04 against main @ e5c739b. The original framing — "most of these have no
upstream fix" — has since inverted: every open alert now names a patched version. The
superseded triage and a full before/after of what changed is preserved in
this comment.

GitHub shows 12 open Dependabot alerts: 8 high, 4 moderate. Six reach the production
dependency tree; the rest are dev-only.

Every one of them now has a patched version available. None of the patched versions requires
a major bump, and each falls inside a semver range its parent already declares — so this is
expected to be a lockfile refresh, not a set of overrides entries or written risk acceptances.

Open alerts

Severity	Package	Scope	Advisory	First patched
high	ws	runtime	CVE-2026-48779	7.5.11
high	lodash-es	runtime	CVE-2026-4800	4.18.0
medium	lodash-es	runtime	CVE-2026-2950	4.18.0
high	brace-expansion	runtime	CVE-2026-13149	5.0.7
high	brace-expansion	runtime	CVE-2026-14257	5.0.8
high	brace-expansion	runtime	CVE-2026-69152	5.0.9
medium	brace-expansion	runtime	CVE-2026-45149	5.0.6
high	brace-expansion	development	CVE-2026-13149	1.1.16
high	js-yaml	development	CVE-2026-59869	4.3.0
high	js-yaml	development	GHSA-5p4m-2wfm-xmqj	4.3.1
medium	js-yaml	development	CVE-2026-53550	4.2.0
medium	qs	development	CVE-2026-8723	6.15.2

Production exposure

Reached through lighthouse and glob. Installed versions and the range each parent declares:

Path	Installed	Needs	Parent declares	In range
lighthouse → ws	7.5.10	7.5.11	^7.0.0	yes
lighthouse → lodash-es	4.17.23	4.18.0 (4.18.1 published)	^4.17.21	yes
glob → minimatch → brace-expansion	5.0.5	5.0.9 (current)	^5.0.5	yes

lodash-es is the one that deserves a real look rather than a reflexive bump: it sits in
Lighthouse's report rendering, and audited page content is attacker-controlled — auditing a
hostile site is this tool's normal job. The advisories are code injection via _.template and
prototype pollution via _.unset / _.omit.

For ws and brace-expansion, confirm the threat model rather than assuming it: the ws peer
is the headless Chrome this CLI launched itself, and brace-expansion input is the glob the
operator typed.

ws@8.21.3 also exists in the tree via puppeteer-core, but carries no open alert — only
the 7.5.10 instance on the Lighthouse path is flagged.

Dev-only exposure

js-yaml and qs, reached through eslint, @commitlint/*, cosmiconfig and the
@googleapis/* type packages, plus brace-expansion@1.1.13/1.1.14 via the minimatch@3 that
eslint 8 pulls in.

Direct dependency status

Package	Installed	Latest	Upgrade
lighthouse	13.4.1	13.4.1	none
glob	13.0.6	13.0.6	none
@commitlint/cli	21.2.2	21.2.2	none
puppeteer-core	25.9.0	25.10.0	in-range patch
eslint	8.57.1	10.9.1	two majors

Unrelated aside worth knowing before anyone regenerates the lockfile from scratch: npm outdated
reports lighthouse Latest as 12.8.2 while 13.4.1 is installed, so the latest dist-tag is
behind the pinned version and a fresh npm install lighthouse would resolve to v12.

The one real upgrade

eslint 8.57.1 → 10.9.1 clears most of the dev-only findings, but eslint 8 is EOL and 9+
requires migrating .eslintrc to flat config (eslint.config.js). That also drags
@netcentric/eslint-config, eslint-plugin-import and eslint-plugin-unused-imports, which must
support flat config first. This should be split into its own issue rather than done here.

Approach

Per the repo's dependency discipline, and explicitly not a blanket npm audit fix:

1. One package per change, so a break is attributable and the revert is clean.
2. Read the changelog, not the version number.
3. Green suite before and after, with the lockfile diff reviewed.
4. Record an explicit verdict for any advisory that turns out to resist a fix.

Plan

1. Refresh the lockfile and confirm which runtime alerts clear on their own. Review the diff.
2. Bump puppeteer-core to 25.10.0 as its own change.
3. Handle whatever residue survives step 1 — and only then decide whether an overrides entry or
   a written risk acceptance is needed anywhere, and where such a record should live.
4. Split the eslint 9/10 flat-config migration into its own issue.

Unverified

Whether the lockfile refresh in step 1 actually lands the patched versions is inference from
the semver ranges above, not a confirmed result. It could not be verified in the environment
where this was triaged: npm audit times out against
registry.npmjs.org/-/npm/v1/security/audits/quick, and both npm update --package-lock-only
and a clean npm install --package-lock-only fail with Cannot read properties of null (reading 'edgesOut') on npm 10.9.2 — reproducible from a bare package.json in an empty directory, so it
is environmental rather than a property of this tree. Confirm before writing any override.

Verification

Whatever lands: npm run lint, npm test, npm run generate-types, npm run check-types, plus
a reviewed lockfile diff and a re-run of npm audit showing the expected before/after delta.

[Hugoer]

Re-triaged against current main (e5c739b) — this issue's premise has inverted

Re-checked because the repo has moved a long way since this was written. The dependency data below is a live fetch, not a re-read of the issue body.

The headline claim is no longer true

the headline finding is that most of these have no upgrade path, so this needs a per-package verdict rather than a bump

Every one of the currently open Dependabot alerts now names a first_patched_version. There are 12 open (this issue says 8):

Severity	Package	Scope	Advisory	First patched
high	ws	runtime	CVE-2026-48779	7.5.11
high	lodash-es	runtime	CVE-2026-4800	4.18.0
medium	lodash-es	runtime	CVE-2026-2950	4.18.0
high	brace-expansion	runtime	CVE-2026-13149	5.0.7
high	brace-expansion	runtime	CVE-2026-14257	5.0.8
high	brace-expansion	runtime	CVE-2026-69152	5.0.9
medium	brace-expansion	runtime	CVE-2026-45149	5.0.6
high	brace-expansion	development	CVE-2026-13149	1.1.16
high	js-yaml	development	CVE-2026-59869	4.3.0
high	js-yaml	development	GHSA-5p4m-2wfm-xmqj	4.3.1
medium	js-yaml	development	CVE-2026-53550	4.2.0
medium	qs	development	CVE-2026-8723	6.15.2

Specific corrections

• lodash-es — "No fix available" is wrong. Patched at 4.18.0; 4.18.1 is published. Lighthouse declares lodash-es@^4.17.21, so the patch is inside the range it already accepts. This was the finding the issue singled out as most deserving a real look, on the grounds that audited page content is attacker-controlled.
• ws — the patched version is 7.5.11, not 7.5.13. Lighthouse declares ws@^7.0.0, so again in range.
• brace-expansion — one moderate DoS has become four advisories (3 high, 1 medium) on the runtime path, patched at 5.0.9, which is the current published version. minimatch@10.2.5 declares ^5.0.5; minimatch@10.2.6 tightens to ^5.0.8. Both in range of glob@13.0.6's minimatch@^10.2.2.
• js-yaml (dev) is now three advisories, not a passing mention.
• puppeteer-core is no longer at latest. The table says 25.9.0 with no upgrade available; npm outdated now reports Wanted and Latest as 25.10.0, so it is a plain in-range bump.

Still accurate

lighthouse@13.4.1, glob@13.0.6 and @commitlint/cli@21.2.2 remain at their latest published versions. The eslint 8.57.1 → 10.9.1 gap is unchanged, still two majors, still requires the flat-config migration plus @netcentric/eslint-config and the two plugins supporting it — still worth its own issue. The dependency discipline in "Approach" (one package per change, read the changelog, green suite before and after, review the lockfile diff) needs no revision.

What I could not verify

Whether a lockfile refresh actually lands the patched versions. Two blockers in this environment, both unrelated to the repo:

• npm audit times out against registry.npmjs.org/-/npm/v1/security/audits/quick, so there are no current npm audit counts to compare with the "22 findings (5 high, 17 moderate)" in the issue body.
• npm update --package-lock-only and npm install --package-lock-only both fail with Cannot read properties of null (reading 'edgesOut') on npm 10.9.2 — including from a clean package.json with no lockfile in a scratch directory, so it is environmental rather than something about this tree.

Every patched version is inside a range its parent already declares, which strongly suggests a refresh clears the runtime alerts without a single overrides entry. That is inference from the semver ranges, not a verified result, and should be confirmed before anyone writes an override.

Revised decisions

The four questions in the issue body were framed around there being no upgrade path. Three of them largely dissolve:

1. Override ws to 7.5.13? → Re-ask as: does a lockfile refresh clear the runtime alerts on its own? If yes, no override is needed anywhere.
2. Accept unpatched ws@8.21.3 and lodash-es with written reasoning? → Moot. lodash-es is patched, and there is no open alert against ws@8.x — only the 7.5.10 instance on the Lighthouse path is flagged.
3. eslint 9/10 flat-config migration — unchanged and still open. Recommend splitting it into its own issue, as this one already suggests.
4. Where to record accepted risks? → Defer. Worth deciding once something actually resists a fix; right now nothing is known to.

Suggested reshape

The task is no longer "produce a per-package risk verdict." It is:

1. Refresh the lockfile, confirm the runtime alerts clear, review the diff, green suite.
2. Bump puppeteer-core to 25.10.0 as its own change.
3. Handle whatever residue survives step 1 — and only then decide whether an override or an accepted-risk register is needed.
4. Split the eslint migration into its own issue.

Steps 1–3 are a much smaller piece of work than the issue body implies.