fix(deps): pin sharp to patched 0.35.4, document the astro AVIF advisory - #29
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
…dvisory The scheduled audit failed on one CRITICAL finding, GHSA-26w7-cxv4-gfx2, "Astro: remote code execution through AVIF image optimization". The advisory ranges on astro >=7.2.8, but the flaw is not in Astro's own source. It lives in libheif inside sharp, and Astro 7.2.8 fixes it only by raising its own sharp floor. This app is on astro 6.4.8 and cannot reach 7.2.8, since 6.4.8 is the final 6.x release, so the fix has to come from sharp directly. sharp was already overridden, but at >=0.35.0, which permits the vulnerable 0.35.0-0.35.3. The lockfile happened to resolve 0.35.4, so the protection was incidental rather than guaranteed. The floor now starts at the patched release. With patched sharp installed the advisory still matches on the astro version, so it is allowlisted, with the reasoning written down rather than a bare id. The path is independently unreachable here. There is no astro:assets, <Image>, <Picture> or getImage usage anywhere under web/src, no AVIF, HEIC or HEIF files in the repo, no web/src/assets/, no image.remotePatterns (so remote images are refused), no endpoint that accepts an uploaded image, and no source file importing sharp. The entry records what would make it apply again and expires 2026-12-09. This is a stopgap, not a decision to stay on Astro 6. The real fix is the 6->7 migration, tracked as a separate PCI. Verified locally. The workflow's own allowlist-filter logic reports 0 violations and 1 allowed. Confirmed the entry is not a blanket suppression by injecting a synthetic unrelated HIGH advisory into a copy of the report; the filter still failed, exit 1.
acamarata
force-pushed
the
fix/deps-audit-2026-09-09
branch
from
September 9, 2026 15:56
3ebe9c4 to
1a1898a
Compare
🟢 Rampart Security Gate — CLEAN
Totals: 0 critical · 0 high · 0 medium · 0 low Mode: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the scheduled audit failure on
0d19c1d7(run 34343556095) — one CRITICAL finding, GHSA-26w7-cxv4-gfx2, "Astro: remote code execution through AVIF image optimization".The advisory names astro, but the bug is in sharp
It ranges on
astro >=7.2.8, yet the flaw is in libheif insidesharp— Astro 7.2.8 fixes it by raising its own sharp floor. This app is onastro 6.4.8and cannot reach 7.2.8 (6.4.8 is the final 6.x release), so the fix has to come from sharp directly.sharpwas already overridden, but at>=0.35.0— which permits the vulnerable 0.35.0-0.35.3. The lockfile happened to resolve 0.35.4, so the protection was incidental rather than guaranteed. Floor now starts at the patched release.Why it is also allowlisted
With patched sharp installed the advisory still matches on the astro version, so it needs an entry — written with its reasoning rather than as a bare id. The path is independently unreachable here, verified on disk:
astro:assets/<Image>/<Picture>/getImageunderweb/srcweb/src/assets/image.remotePatterns/image.domainsrequest.formData()call sites are text-only auth/admin formssharpThe 85 raster images all sit under
web/public/or vendored brand assets, which bypass the image pipeline. The entry records what would make it apply again and expires 2026-12-09.This is a stopgap, not a decision to stay on Astro 6. The real fix is the 6->7 migration, tracked separately.
Verified locally