Drop extract-zip from the docs tree to clear CVE-2026-56876

[Circadian-agent]

Description

Fixes #76, which is the highest-severity issue currently open (High, 8.1). extract-zip@2.0.1 does not validate symlink targets when extracting, so a malicious archive can read or write outside the extraction directory.

Why an override rather than a version bump

Mend reports Remediation Possible: No, and it is right: extract-zip's latest release is 2.0.1, published 2020-06-10. The package is unmaintained and there is nothing to upgrade to.

It can still be removed, because it is reachable through exactly one path:

astro-icon 1.1.5 -> @iconify/tools 4.2.0 -> extract-zip 2.0.1

astro-icon@1.1.5 is itself the latest release, and it depends on @iconify/tools@^4.0.5. I checked every published 4.x of @iconify/tools: all fourteen depend on extract-zip. No 5.x does. So overriding @iconify/tools to ^5.0.12 removes the vulnerable package from the tree entirely rather than pinning around it.

This repo already uses overrides for exactly this shape (yauzl, undici, sharp), so the mechanism is not new here. What is new is that it crosses a major version of a transitive dependency, which is why I verified it against built output rather than just the install.

Verification

check	before	after
extract-zip dirs under node_modules	1 (2.0.1)	0
extract-zip entries in lockfile	present	0
@iconify/tools	4.2.0	5.0.12
npm audit --omit=dev	-	0 vulnerabilities

And on the output side, since a major bump under astro-icon is the real risk here:

• astro build succeeds, 2 pages
• the rendered HTML of both pages is byte-identical to a pre-change build once content-hashed asset filenames are normalised
• index.html still contains the same 50 inline SVGs, so icon rendering is unaffected

Note

If you would rather not cross a major boundary on a transitive dep, the alternative is dropping astro-icon or waiting for it to widen its @iconify/tools range. Both leave the CVE in place for now, so I went with the override, but I am happy to change it.

[Circadian-agent]

The Mend check is red on this PR and I want to save a reviewer the time of working out whether that means this change made things worse. It did not, and Mend's own summary says so in its first clause:

You have successfully remediated 1 vulnerabilities, but introduced 5 new vulnerabilities in this branch.

The remediated one is the point of this PR. CVE-2026-56876 in extract-zip-2.0.1 is gone, which is #76.

The 5 reported as new are all the same library, in a directory this PR does not touch. They are CVE-2026-71436, CVE-2026-71437, CVE-2026-71438, CVE-2026-71439 and CVE-2026-50159, and every one of them is mermaid-11.15.0.tgz under /docs/starlight-docs/package.json.

This PR changes exactly two files:

docs/package.json
docs/package-lock.json

git diff main...HEAD -- docs/starlight-docs/ is empty, and mermaid: "^11.15.0" is pinned on main in that file already. So the pin these findings come from is not something this branch introduced or moved.

The part that is actually worth acting on

Those mermaid CVEs were tracked in #258 ("mermaid-11.15.0.tgz: 9 vulnerabilities, highest severity 9.3"), and that issue is closed while the pin on main is unchanged. Mend suggests 11.16.1 as the fix for the ones listed here.

I am happy to send that as a separate PR. One ordering note if you want it: #417 already modifies docs/starlight-docs/package.json, so a mermaid bump would conflict with it. Cleanest is to land or close #417 first, then bump mermaid on top. Say the word and I will open it.