fix(deps): bump xmldom to 0.8.15 and browserslist to 4.28.8 - #18
Conversation
CVE-2026-83610 (GHSA-6gmq-8vp8-gcm6) spans two @xmldom/xmldom release lines, and this repo carries a copy on each: >= 0.7.0, <= 0.8.14 -> patched in 0.8.15 (node_modules/@xmldom/xmldom) >= 0.9.0, <= 0.9.11 -> patched in 0.9.12 (nested under plist, see #16) #16 covers the 0.9.x copy; this covers the 0.8.x copy. Both are needed to actually close the CVE here -- they are not separate issues, which an earlier version of this message got wrong. - @xmldom/xmldom 0.8.13 -> 0.8.15 (CVE-2026-83610, moderate). XML fragment injection via invalid EntityReference.nodeName during requireWellFormed serialization. All 8 consumers declare ^0.8.8. - browserslist 4.28.5 -> 4.28.8 (GHSA-c83g-rgw3-j3cx and GHSA-73wf-gq98-2v4g, high; first patched in 4.28.7). Unbounded memory growth and an uncaught crash / prototype write via untrusted browserslist-stats.json. browserslist 4.28.8 raises its own dependency floors, so five packages in its chain move with it: baseline-browser-mapping 2.10.42 -> 2.11.21, caniuse-lite 1.0.30001803 -> 1.0.30001810, electron-to-chromium 1.5.388 -> 1.5.422, node-releases 2.0.50 -> 2.0.54 and update-browserslist-db 1.2.3 -> 1.3.2. Lockfile-only; package.json is untouched. All 17 declared ranges across the 7 bumped packages still resolve and satisfy, and no engines constraint changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018Ds7MWC2WZfwe6X5mwJV12
|
Local CI replication finished — resolving the "still running" caveat in the description. All green:
The 192 lint warnings are pre-existing Remaining audit finding on this branch is expected
#16 has since merged. Current
Verified this branch merges cleanly into current |
Lockfile-only. Clears the two remaining
npm auditfindings onmain.1.
@xmldom/xmldom0.8.13 → 0.8.15 — the other half of CVE-2026-83610GHSA-6gmq-8vp8-gcm6isCVE-2026-83610(confirmed via the GitHub advisory API:cve_id: CVE-2026-83610), and it spans two release lines:>= 0.7.0, <= 0.8.140.8.15>= 0.9.0, <= 0.9.110.9.12This repo carries a copy on each line, so the CVE needs both bumps:
node_modules/@xmldom/xmldom0.8.13→0.8.15— this PRnode_modules/plist/node_modules/@xmldom/xmldom0.9.10→0.9.12— fix(deps): bump @xmldom/xmldom to 0.9.12 to resolve CVE-2026-83610 #16#16's description originally framed the 0.8.x copy as "outside the affected range" and "a different advisory". That was wrong and is corrected in a comment there. Both PRs must land before CVE-2026-83610 is actually closed for this repo.
The advisory's third affected package, the legacy unscoped
xmldom(<= 0.6.0, no patch available), is not present in this tree.2.
browserslist4.28.5 → 4.28.8 — unrelated, high severityGHSA-c83g-rgw3-j3cx(unbounded memory growth, no cache eviction → eventual OOM) andGHSA-73wf-gq98-2v4g(uncaught crash / prototype write via untrustedbrowserslist-stats.json). Both affect<= 4.28.6, first patched in4.28.7; this takes4.28.8.4.28.8raises its own dependency floors, so five packages in its chain move with it. This is required by the bump, not scope creep:baseline-browser-mapping^2.11.12caniuse-lite^1.0.30001809electron-to-chromium^1.5.402node-releases^2.0.53update-browserslist-db^1.3.0Why this can't break consumers
Lockfiles are not published to consumers — npm ignores a dependency's lockfile, so downstream apps resolve
@revopush/expo-code-push-pluginpurely from itspackage.jsonranges, which are untouched. The blast radius is this repo's own CI and dev installs.Verification
semveragainst npm's real node_modules walk-up, includingupdate-browserslist-db'sbrowserslist@">= 4.21.0"peer dep. Zero unsatisfied.enginesconstraint changed on any of the 7. The tightest isnode-releases@>=18; CI's Node 20.19.4 satisfies all.npm install --package-lock-onlyproduced no further changes.packagesfrom both lockfiles gives an identical key set — no entries added or removed, exactly 7 versions differing. The 52 changed lines inpackage-lock.jsonare 7 × 3 fields (version/resolved/integrity) + browserslist's 5 dependency-range lines;yarn.lock's 62 are those same 26 plus 5 entry headers, since yarn keys entries by semver range.yarn.lockintegrityvalue was checked against the registry — all 7 match.npm ci+npm run build+npm run lintwere still running locally when this PR was opened (the registry has been very slow — its audit endpoint returned503 Service Unavailableearlier). CI runs exactly that on this PR, so its result is authoritative here.🤖 Generated with Claude Code
https://claude.ai/code/session_018Ds7MWC2WZfwe6X5mwJV12