Accepted: 10 high npm advisories with no upstream patch (build-time only) — do NOT run `npm audit fix --force`

[twistedmelonman]

Status: accepted risk, enforced by CI. No action is available or required.
Last verified 2026-08-29. The authoritative record is
docs/SECURITY-AUDIT.md; this issue is
the discussion thread for it.

Summary

npm audit reports 10 high advisories on main, from two root packages
carrying three CVEs between them. Both roots are build-time-only
dependencies of the Netlify toolchain, and neither has a patched release in
existence — so there is nothing to upgrade to and nothing to fix.

The remaining eight audit entries are not distinct problems. They are chain
packages flagged solely for depending on a root.

Root	Advisory	Installed	Vulnerable range	First patched
image-size	GHSA-w3rx-r6r6-pgpr — ICNS parser DoS	2.0.2	<=2.0.2	none exists
image-size	GHSA-5p2g-fcmc-qvqq — JXL/HEIF parser DoS	2.0.2	<=2.0.2	none exists
extract-zip	GHSA-jmr9-qjv8-65gv — symlink path traversal	2.0.1	<=2.0.1	none exists

first_patched_version: null on all three, confirmed against the GitHub
Advisory API. npm view confirms 2.0.2 and 2.0.1 are the newest published
versions of each package. Upstream fix tracked at
netlify/framework-adapters#47.

Chain-only entries: @astrojs/netlify, @netlify/blobs, @netlify/dev,
@netlify/dev-utils, @netlify/edge-functions-dev, @netlify/functions-dev,
@netlify/redirects, @netlify/vite-plugin.

⚠️ Do NOT run npm audit fix --force

npm proposes a downgrade of @astrojs/netlify from the installed 8.1.2 to
6.4.1, flagged isSemVerMajor: true, for 9 of the 10 findings:

@astrojs/netlify -> {"name":"@astrojs/netlify","version":"6.4.1","isSemVerMajor":true}

That would roll back #106's major bumps and reintroduce the Astro 5
content-collection API — re-breaking the site in exactly the way #120 fixed. It
also would not clear the advisories, because the roots are unpatched at every
version.

This trap is guarded in two places: scripts/check-audit-baseline.sh keys on
GHSA IDs rather than npm's fixAvailable (which recommends the downgrade), and
.github/dependabot.yml ignores @astrojs/netlify majors.

Why this is accepted

Both roots run at build time only. Neither is bundled into any deployed
function.

@astrojs/netlify@8.1.2 → @netlify/vite-plugin@2.12.9 → @netlify/dev-utils@4.4.7 → image-size@2.0.2
@astrojs/netlify@8.1.2 → @netlify/vite-plugin@2.12.9 → @netlify/dev@4.18.12 → @netlify/functions-dev@1.3.4 → extract-zip@2.0.1

image-size processes only images committed to this repo. extract-zip is used
by local dev/functions tooling, not by anything in production. A DoS advisory
against a build-time parser fed exclusively repo-controlled input is not a
meaningful risk here; the realistic worst case is a local build hanging on a
malformed image the author added themselves.

Two caveats that are not part of the rationale, recorded because earlier
versions of this issue wrongly relied on them:

• The site is not free of user input. netlify/functions/instagram-webhook.mts:88
  fetches an attacker-supplied post.imageUrl and stores the bytes. It is
  bearer-token gated (:44) and never parses the image, so it reaches no
  parser — but "no user uploads" is false.
• The site is not fully static. src/pages/blog/index.astro:7 sets
  export const prerender = false, and the built manifest carries six
  "prerender":false routes deployed at path: /*. SSR runs at request time.

Known gap: Astro vendors its own image-size

node_modules/astro/dist/assets/utils/vendor/image-size/ is a private copy that
ships in the deployed SSR bundle. It is invisible to npm audit, not
covered by the overrides block, and not seen by check-audit-baseline.sh. Its
ICNS parser is logically identical to vulnerable upstream 2.0.2 — same missing
zero-length guard.

Not exploitable, failing closed twice:

1. astro.config.mjs declares no image: block, so domains and
   remotePatterns are empty and isRemoteAllowed returns false for every
   remote URL — 403 before any fetch.
2. The configured service is @astrojs/netlify/image-service.js, whose exported
   service object has no transform method. The /_image endpoint's
   first check is if (!("transform" in imageService)) throw — 500 before a
   parser runs.

Both guards are configuration, not code. Adding a single image.domains
entry, or switching to a local/sharp image service, removes them and makes the
vendored parser reachable. Re-read this section before changing either.

What would change this

• Either root publishes a patched release. check-audit-baseline.sh reports
  this without failing, which is the cue to retire its baseline line.
• @netlify/dev moves off them. @netlify/dev-utils@6.0.1 already dropped
  image-size, but forcing that chain via overrides pushes
  @netlify/vite-plugin onto an untested @netlify/dev major — the same shape
  as the failure behind fix: restore content collections under Astro 7 glob loader #120, so it was deliberately not shipped.
• A new advisory appears outside the accepted set. CI fails on that
  automatically; triage it rather than assuming this acceptance covers it.

@astrojs/netlify 8.1.2 → 8.2.4 is available and compatible (peer
astro: ^7.0.0 against the installed 7.1.6) but clears zero advisories — it
declares the same @netlify/vite-plugin: ^2.12.3, already resolving to 2.12.9.
Hygiene only, not a fix.

History

• 2026-08-18 — filed at 15 high advisories.
• 2026-08-21 — re-triaged; @netlify/dev-utils@6.0.1 override tested (10 → 5
  findings) and deliberately not shipped.
• 2026-08-29 — re-verified at 10 high. sharp, picomatch, nanoid, ipx
  and top-level @netlify/blobs cleared by fix: build CI with output assertions, Node pinning, and dependency triage #127 and the blobs 10 → 11 bump.
  Retired the stale chain @netlify/images baseline entry, corrected the two
  wrong premises above, and recorded the vendored-image-size gap (chore: re-triage the audit baseline, add npm to dependabot #144).

Related: #106, #120, #127, #144

[twistedmelonman]

Partially addressed in #127 (merged as 478855d): 15 → 10 advisories, with the remaining 10 assessed and documented rather than silenced.

Fixed

Package	Action
@netlify/blobs	^10.7.2 → ^11.0.1 (direct fix)
sharp	override → ^0.35.3
picomatch	override → ^4.0.5
nanoid	override → ^5.1.6
ipx	cleared transitively by the sharp override

@netlify/blobs 10 → 11 is a major bump; the three call sites use getStore, .get, .set, .setJSON, all present in v11 with compatible signatures, and the functions type-check clean against the v11 declarations.

Confirmed the trap in the original report: npm's proposed fix is a downgrade of @astrojs/netlify to 6.4.1, which would reintroduce the Astro 5 collection API and re-break the site as in #120. Also tested upgrading to the newest 8.x (8.2.3) — it does not clear the remaining advisories.

Remaining 10 — assessed and accepted

All trace to image-size and extract-zip, which report an affected range of *: no patched release exists upstream, so npm's only "fix" is the downgrade. Both are build-time only in the @netlify/dev toolchain and unreachable from deployed code — this site has no user uploads, so nothing untrusted ever reaches an image or archive parser.

Reasoning is written up in docs/SECURITY-AUDIT.md, including one override (@netlify/blobs forced across the whole dev toolchain) that was tested, clears one more advisory, and was deliberately not taken — it forces the Netlify toolchain onto a major it doesn't pin, which is broader than one build-time advisory justifies.

Keeping this open

The residual 10 are accepted, not resolved. This issue should stay open until image-size or extract-zip publish patched releases, or @netlify/dev moves off them.

Re-check with npm audit. If the count rises above 10, or an advisory appears outside that chain, it needs fresh triage rather than falling under this acceptance.

[twistedmelonman]

Triage pass 2026-08-24 (analysis only — no dependency changed)

Full per-advisory triage below. No file in this repo was modified: no npm audit fix, no version bumps, lockfile MD5 unchanged. Every recommendation is left for you to action.

---

---

Executive summary

The count has moved since the issue was filed. Current audit reports 10 high-severity advisories, not 15 — 0 critical, 0 moderate, 0 low. The @netlify/blobs and picomatch/nanoid/sharp entries named in the issue no longer appear; the overrides block in package.json (sharp, picomatch, nanoid) and the top-level @netlify/blobs@11.0.1 have already resolved them. Five of the issue's fifteen are already fixed.

Of the remaining 10:

• Distinct underlying CVEs: 3. The 10 entries are the same three advisories counted once per affected package in the dependency chain.
• Runtime-reachable: 0. Verified against built output, not inferred.
• Dev/build-only: all 10.
• Non-breaking fix available: 0. Both vulnerable packages are already at their latest published versions.
• Requires a major-version decision: 0 worth taking — npm's only proposal is a downgrade that must be refused.

Do this first: nothing urgent. Close this issue as accept-risk-and-document. That is the actual finding, and it is worth stating plainly rather than manufacturing an action. There is no fix to apply, no exposure to remediate, and the one change npm proposes would break the site.

Why the number is 10 and not 3

npm audit counts an entry for every package with a vulnerable dependency in its subtree, so a single leaf CVE propagates upward. All 10 resolve to one chain:

@astrojs/netlify@8.1.2
└─ @netlify/vite-plugin@2.12.9
   ├─ @netlify/dev-utils@4.4.7 → image-size@2.0.2        (2 CVEs)
   └─ @netlify/dev@4.18.12
      └─ @netlify/functions-dev@1.3.4 → extract-zip@2.0.1 (1 CVE)

The eight intermediate packages (@astrojs/netlify, @netlify/vite-plugin, @netlify/dev, @netlify/dev-utils, @netlify/blobs, @netlify/edge-functions-dev, @netlify/functions-dev, @netlify/redirects) have no vulnerabilities of their own. They are flagged solely for containing image-size or extract-zip.

---

Grouped table

#	Root cause	Advisories	Distinct CVEs	Max severity	Dev/runtime	Fix shape	Recommendation
A	image-size@2.0.2 via @netlify/dev-utils	2	2	high	build-only	none available (at latest)	accept-risk-and-document
B	extract-zip@2.0.1 via @netlify/functions-dev	1	1	high	build-only	none available (at latest)	accept-risk-and-document
C	Intermediate Netlify toolchain packages	7	0	high	build-only	resolves when A and B do	no action — counting artifact

---

Group A — image-size@2.0.2 (2 CVEs)

Field	Value
Advisories	GHSA-w3rx-r6r6-pgpr (ICNS parser, infinite-loop DoS) GHSA-5p2g-fcmc-qvqq (JXL and HEIF parsers, infinite-loop DoS)
Severity	high (both)
Installed	2.0.2
Vulnerable range	<=2.0.2
First fixed version	none — 2.0.2 is the latest published version
Direct?	No. Transitive, depth 3.
Pulled in by	@astrojs/netlify → @netlify/vite-plugin → @netlify/dev-utils@4.4.7

Dev vs runtime: build-only. @netlify/dev-utils is part of the Netlify local-dev and build toolchain. It is used while astro build runs; it is not part of the deployed output.

Reachability: not reachable in production. Two independent checks:

1. astro.config.mjs sets output: 'static'. The site builds to static HTML; there is no SSR server executing adapter code at request time. dist/ contains only HTML, CSS, JS bundles, images, and XML.
2. Grepping the built output for image-size and extract-zip returns nothing — neither package appears in dist/.

The vulnerability is a DoS triggered by parsing a malformed image. Reaching it requires feeding an attacker-controlled image to image-size. This site has no user uploads, and the images it processes are the ones committed to the repo. The realistic worst case is that a malicious image you added yourself hangs your own build.

Fix shape: no fix available. npm view image-size version returns 2.0.2 — the installed version is the latest. There is nothing to bump to. An overrides pin would have no target.

Recommendation: accept-risk-and-document. No command to run. Revisit if image-size publishes 2.0.3+ or if @netlify/dev-utils moves off it.

---

Group B — extract-zip@2.0.1 (1 CVE)

Field	Value
Advisory	GHSA-jmr9-qjv8-65gv — unvalidated symlink path traversal
Severity	high
Installed	2.0.1
Vulnerable range	<=2.0.1
First fixed version	none — 2.0.1 is the latest published version
Direct?	No. Transitive, depth 4.
Pulled in by	@astrojs/netlify → @netlify/vite-plugin → @netlify/dev → @netlify/functions-dev@1.3.4

Dev vs runtime: build-only. @netlify/functions-dev supports local function development and build-time function handling.

Reachability: not reachable in production, by the same two checks as Group A. Exploiting it requires extracting an attacker-controlled zip archive. @netlify/functions-dev uses extract-zip to unpack toolchain artifacts it downloads from Netlify's own infrastructure, not user input.

Honest uncertainty: I did not trace every call site inside @netlify/functions-dev to prove no code path extracts an archive from an attacker-influenced source. I am reasoning from the package's role in the toolchain. Given that the package never reaches the deployed site, this residual uncertainty affects build-machine risk only, not production risk.

Fix shape: no fix available. extract-zip@2.0.1 is the latest published version. The package is effectively unmaintained.

Recommendation: accept-risk-and-document. No command to run.

---

Group C — intermediate Netlify toolchain packages (counting artifact)

@astrojs/netlify, @netlify/vite-plugin, @netlify/dev, @netlify/dev-utils, @netlify/blobs (nested), @netlify/edge-functions-dev, @netlify/functions-dev, @netlify/redirects.

These contribute zero distinct CVEs. Each is flagged only because image-size or extract-zip sits somewhere beneath it. They clear automatically when Groups A and B do. No action.

One point worth clearing up: the @netlify/blobs entry

The audit flags @netlify/blobs at range 9.1.6 - 10.7.12 with fixAvailable: true, which reads like an easy win. It is not, and the reason matters:

node_modules/@netlify/blobs                              = 11.0.1  ← clean; what functions import
node_modules/@netlify/dev/node_modules/@netlify/blobs    = 10.7.12 ← flagged
node_modules/@netlify/functions-dev/node_modules/@netlify/blobs = 10.7.12 ← flagged

The top-level @netlify/blobs@11.0.1 — the one the runtime functions in netlify/functions/*.mts actually import via getStore — is already clean and already bumped. The flagged copies are nested duplicates that the adapter's build tooling pins to the 10.x line. Bumping the direct dependency again does nothing, because it is not the copy being reported. The issue's suggestion to "bump @netlify/blobs directly — clean fix available" was correct when filed but has since been done; the remaining entry is the nested copy, which only the adapter controls.

---

The forward-bump path was checked and does not help

The issue suggests checking whether a newer @astrojs/netlify in the 7/8 line clears these. I checked. It does not:

• Installed: @astrojs/netlify@8.1.2. Latest: 8.2.4 (same major — a safe minor bump).
• But 8.2.4 declares "@netlify/vite-plugin": "^2.12.3", the same range as 8.1.2, which already resolves to 2.12.9 — the latest.
• @netlify/vite-plugin@2.12.9 declares "@netlify/dev-utils": "^4.4.6". Installed is 4.4.7.
• @netlify/dev-utils latest is 6.0.1, but the ^4.4.6 range cannot reach it. Only an upstream change to @netlify/vite-plugin can.
• Even at @netlify/dev-utils@6.0.1, image-size has no fixed version to move to.

Conclusion: bumping to @astrojs/netlify@8.2.4 is harmless and reasonable hygiene, but it clears zero advisories. The fix must come from upstream — either @netlify/vite-plugin widening its @netlify/dev-utils range, or image-size/extract-zip publishing patches.

An overrides entry cannot help either, since there is no fixed version to pin to. (The existing overrides for sharp, picomatch, and nanoid did work — that is why those advisories are gone.)

# Optional hygiene only — clears no advisories. Verify the site still builds.
npm install @astrojs/netlify@8.2.4 --prefix /Users/andrewrich/Developer/netlify/projectinsomnia
npm run build --prefix /Users/andrewrich/Developer/netlify/projectinsomnia

---

Do not do this

Do not run npm audit fix --force in this repo. Its only proposal for 9 of the 10 advisories is:

@astrojs/netlify -> {"name":"@astrojs/netlify","version":"6.4.1","isSemVerMajor":true}

That is a downgrade from 8.1.2 to 6.4.1 — two majors backwards, and it would:

1. Re-break the site the way fix: restore content collections under Astro 7 glob loader #120 just fixed. Rolling back to the 6.x adapter reintroduces the Astro 5-era content-collection API against an Astro 7.1.6 install, undoing chore: bump the npm_and_yarn group across 1 directory with 20 updates #106's major bumps.
2. Break the peer contract. @astrojs/netlify@8.x declares "astro": "^7.0.0". The 6.x line does not support Astro 7, so this produces an unsatisfiable peer graph on top of the API breakage.
3. Not actually fix anything. image-size and extract-zip have no patched versions. The downgrade silences the report by moving to a tree whose advisories are less catalogued, not less present.

Standing signal: when npm proposes a major downgrade as a fix, it means the resolver found no forward path and fell back to the oldest version with no recorded advisories. Treat it as a prompt to triage by hand. nightowlstudiollc/kebab-tax-netlify#243 hit the identical pattern with netlify-cli (23.10.0 → 12.5.0, eleven majors back).

---

Open questions for the owner

1. Close this issue as accept-risk-and-document? That is my recommendation. There is no fix to apply, no production exposure, and the only proposed change is harmful. The useful output is the written conclusion, not a code change.
2. Should the issue title/body be updated to 10? The count dropped from 15 to 10 because the overrides block and the @netlify/blobs@11.0.1 bump already landed. Anyone reading Accepted: 10 high npm advisories with no upstream patch (build-time only) — do NOT run npm audit fix --force #123 today will see a number that no longer matches npm audit.
3. Track upstream, or re-check periodically? These clear only when image-size or extract-zip publishes a patch, or when @netlify/vite-plugin widens its @netlify/dev-utils range. A periodic re-check is probably enough given zero production exposure. Worth noting extract-zip appears effectively unmaintained, so its CVE may persist indefinitely.
4. Add an npm ecosystem entry to .github/dependabot.yml? Same gap flagged in kebab-tax#243. It would not fix these, but it would keep the tree current so the next genuinely-fixable advisory surfaces as a PR rather than an audit backlog.
5. Do you want a note in-repo recording the dev-only conclusion? So the next person to see "10 high severity" does not re-derive this from scratch. scripts/verify-deploy-preview.sh already carries a comment about adapter/blobs coupling, which suggests that habit exists here.

---

Method note

Read-only throughout. npm audit --json --prefix does not write a lockfile. Lockfile MD5 verified identical before and after (9a0bc3ba2aa7b2fb28d1ab9f92c4ce8e). No file inside the repository was created, modified, or deleted. Version lookups used npm view, which is registry-read-only. Runtime-reachability conclusions were checked against the existing dist/ build output rather than inferred from configuration alone.

[twistedmelonman]

Re-triaged 2026-08-29. The count in the title is stale — it is 10 high, not 15 — and the remaining set is unfixable upstream. No dependency change is warranted. Three corrections and one new finding below.

Current ground truth

npm audit: 10 high, 0 critical / moderate / low. Only three distinct CVEs; the other seven entries are chain packages flagged for depending on them.

Advisory	Package	Vulnerable range	First patched
GHSA-w3rx-r6r6-pgpr (ICNS DoS)	image-size 2.0.2	<=2.0.2	null
GHSA-5p2g-fcmc-qvqq (JXL/HEIF DoS)	image-size 2.0.2	<=2.0.2	null
GHSA-jmr9-qjv8-65gv (symlink traversal)	extract-zip 2.0.1	<=2.0.1	null

first_patched_version: null verified against the GitHub Advisory API for all three; npm view confirms 2.0.2 and 2.0.1 are the newest published versions. There is nothing to upgrade to.

Cleared since this issue was filed (by #127 and the blobs 10→11 bump): sharp, picomatch, nanoid, ipx, and top-level @netlify/blobs.

The downgrade trap described above is still live and still correct: npm proposes @astrojs/netlify@6.4.1 (isSemVerMajor: true) for 9 of the 10. Do not take it.

Two premises in docs/SECURITY-AUDIT.md are factually wrong

The accepted-risk conclusion survives, but two of its supporting claims do not:

1. "no user uploads / nothing untrusted reaches a parser" — netlify/functions/instagram-webhook.mts:88 fetches an attacker-supplied post.imageUrl and stores the bytes. It is bearer-token gated (:44) and never parses the image, so it is not exploitable — but there is a user-influenced input path.
2. "static site, no SSR executing at request time" — not accurate. src/pages/blog/index.astro:7 sets export const prerender = false, and the built manifest carries 6 "prerender":false occurrences deployed at path: /*.

New finding: Astro vendors its own image-size, invisible to the baseline

node_modules/astro/dist/assets/utils/vendor/image-size/ is a private copy that ships in the deployed SSR bundle. It is not visible to npm audit, not covered by the overrides block, and not seen by check-audit-baseline.sh. Its ICNS parser is logically identical to vulnerable upstream 2.0.2 — same missing zero-length guard; a crafted header with a zero-length entry pins imageOffset at 8 and loops.

It is not exploitable, and it fails closed twice:

• astro.config.mjs declares no image: block, so domains and remotePatterns are both empty and isRemoteAllowed returns false for every remote URL → 403 before any fetch.
• The configured service is @astrojs/netlify/image-service.js, whose exported service object has no transform method. /_image's first check is if (!("transform" in imageService)) throw → 500 before a parser runs.

Recording it because both guards are config-dependent. Adding one image.domains entry, or switching to a local/sharp image service, would open it.

Disposition

• Fix now: nothing. No patched version exists for any of the three roots.
• Tracked upgrade: none available. The real fix is upstream — netlify/framework-adapters#47, already filed.
• Accept: all 10, as already documented. @astrojs/netlify 8.1.2 → 8.2.4 is available and compatible (peer astro: ^7.0.0 vs installed 7.1.6) but clears zero advisories — it declares the same @netlify/vite-plugin: ^2.12.3, already resolving to 2.12.9. Hygiene only.

Baseline housekeeping

scripts/check-audit-baseline.sh passes (exit 0), reports both roots as "still no patched release upstream", and has all 10 recorded. Two small items:

• One stale entry: the baseline still lists chain @netlify/images, which no longer appears in npm audit. Harmless — the check only fails on unlisted packages — but worth deleting per the doc's own retirement procedure.
• .github/dependabot.yml covers github-actions only. There is no npm ecosystem entry, so npm bumps never arrive as PRs here.

Suggest retitling to reflect 10, and keeping this open as the accepted-risk record.

[twistedmelonman]

Title and description rewritten 2026-08-29 so the current, verified state is at the top instead of scattered across this thread.

Everything that mattered from the comments below is now in the issue body: the corrected count (10, not 15), the three CVEs and their two root packages, proof that no patched release exists, the downgrade trap, the exposure rationale with its two corrected premises, the vendored-image-size gap, and the conditions that would change any of it.

The comments below are kept as history and are partly superseded. Read the description, not this thread. Individual advisory numbers, counts, and package lists in older comments were accurate when written and are not now.