frontend-skills-qa.yml: @axe-core/cli pulls a moderate-severity, currently-unpatched adm-zip advisory (GHSA-vwc7-r8mq-g2x9)

[wz-gsa]

Summary

.github/workflows/frontend-skills-qa.yml installs @axe-core/cli@4.11.3 via a floating npm install -g (no lockfile, no npm audit step). That package transitively depends on chromedriver: latest -> adm-zip: ^0.6.0, which has a moderate-severity advisory: GHSA-vwc7-r8mq-g2x9 (CVE-2026-76845) — adm-zip follows destination symlinks during extraction, allowing an attacker who can pre-plant a symlink in a shared/reused extraction directory to overwrite an arbitrary file the extracting process can write.

Found while sweeping all 3 GSA-TTS agentic-coding repos for exposure to a separate, unrelated js-yaml advisory that was blocking PR auto-merge (GSA-TTS/agentic-coding-quickstart#454 / GSA-TTS/agentic-coding-playbook#290 / #409) — this is a distinct finding, not part of that fix.

Why this can't be fixed by a version bump

Checked directly: the advisory itself states "Patched versions: None" — no released adm-zip version fixes the symlink-following behavior. Every published @axe-core/cli version (checked 4.7.3 through 4.13.1 prereleases) declares chromedriver: latest, and chromedriver's own dependency on adm-zip ^0.6.0 pulls the same vulnerable range regardless. npm audit fix --force's own suggested remediation (downgrade to @axe-core/cli@4.7.3) does not actually resolve the finding — it still resolves to a vulnerable chromedriver/adm-zip pair, just via axe-core/cli's own now-vulnerable-differently <=4.1.1 range per the advisory tree. There is currently no combination of pinned versions that clears this.

Exploitability assessment (why this isn't urgent)

The vulnerable code path only triggers during chromedriver's own npm postinstall step, which downloads and extracts its own trusted binary from Google's CDN — exploiting it requires an attacker to have already planted a symlink in that extraction directory before the install runs. GitHub Actions runners are fresh, non-shared, ephemeral VMs per job, so the realistic attack surface in this specific CI usage is low (not zero — a supply-chain compromise of the download itself is a separate, different risk this advisory doesn't cover). The workflow also never runs npm audit, so this was not the cause of any PR auto-merge blockage — that was a separate, unrelated js-yaml advisory (already fixed).

Recommendation

No action is safe to take right now that actually resolves the underlying adm-zip issue — there's no patched version to pin to, and pinning @axe-core/cli to an older version doesn't help per the advisory's own affected-range coverage. Options, none clearly best without more input:

1. Accept as a documented, tracked risk (lowest effort) — this issue serves that purpose; revisit when adm-zip ships a real fix upstream.
2. Replace @axe-core/cli's Selenium/chromedriver-based driver with a Playwright-based axe runner (e.g. @axe-core/playwright), which doesn't depend on chromedriver/adm-zip at all — a real fix, but a larger workflow rewrite, not a drop-in swap.
3. Pin chromedriver explicitly to a version that resolves to a non-vulnerable adm-zip — checked and this is not currently possible; every recent chromedriver version requires adm-zip ^0.6.0.

Acceptance criteria

• A decision is recorded on which direction to take (including "accept and monitor for an upstream adm-zip fix" as a valid outcome)
• If accepted as a tracked risk, this issue stays open with a note to re-check adm-zip's advisory page periodically until "Patched versions: None" changes