Astro 5.x Has No Patch for Critical AVIF RCE

Astro 5.x has no patched release for GHSA-26w7, a critical remote code execution flaw in the default Sharp image service. The first fixed Astro release is 7.2.8. The upgrade PR moves the project from Astro 5.18.1 to 7.4.2, resolves Sharp 0.35.5, and also clears GHSA-m8p5 in @astrojs/node.

That version jump is the practical fix. Staying on 5.x and changing a setting does not remove the vulnerable code path.

The two advisories

GHSA-26w7: AVIF image optimization can execute code

Astro’s default image service uses Sharp. Sharp uses libheif to decode AVIF files. A crafted AVIF image can trigger an out-of-bounds read and write in that decoder when Astro optimizes the image. The result can be remote code execution on the host running Sharp.

The advisory rates the issue 9.8 on CVSS v3: network attack vector, low complexity, no privileges, and no user interaction. An attacker only needs a path that makes Astro process an AVIF file they control. Public upload forms, remote image URLs that reach the optimizer, and build pipelines that ingest untrusted images are the paths to check.

Astro 7.2.8 updates the minimum supported Sharp version to 0.35.4. The upgrade PR goes further and resolves Sharp 0.35.5. Projects on Astro 5.x are inside the affected range, and the advisory lists no 5.x patched version.

GHSA-m8p5: Host header SSRF in @astrojs/node

The second advisory affects @astrojs/node 11.1.6 and earlier. The adapter’s createRequestFromNodeRequest() used the incoming Host header as the request URL authority without validating it against security.allowedDomains. The separate createRequest() helper did validate the header and fell back to localhost. The adapter used the unvalidated helper on every request.

That makes the default /_image endpoint a full-read SSRF path. It also means every absolute URL built from Astro.url can point at an attacker-controlled host. The advisory lists password-reset and email-confirmation link poisoning, poisoned canonical and Open Graph tags, and cache poisoning as consequences. @astrojs/node 11.1.7 fixes the validation.

What the upgrade does

Astro 7.2.8 sets the Sharp floor at 0.35.4. Sharp 0.35.5 satisfies that floor and is the version resolved by the upgrade. Verify the resolved tree with npm ls sharp; a nested copy under an integration can keep the vulnerable decoder in the build.

Upgrade checklist

1. Check the installed versions with npm ls astro sharp @astrojs/node, and treat any Astro below 7.2.8 as affected.
2. Upgrade Astro to 7.2.8 or later, with 7.4.2 as the tested target in the PR, and upgrade Sharp to 0.35.4 or later; the PR uses 0.35.5.
3. If the project uses the Node adapter, upgrade @astrojs/node to 11.1.7 or later, and do not rely on security.allowedDomains to cover the Host header on affected versions.
4. Run npm dedupe and npm ls sharp again, because a single stale nested Sharp copy keeps GHSA-26w7 in the dependency tree.
5. Build and test the image pipeline, SSR routes, middleware, and adapter behavior; Astro 5 to 7 is a major upgrade, so check integration versions as well as the core packages.

If an immediate upgrade is not possible, stop passing untrusted AVIF files to Astro’s image optimizer. Remove or restrict public upload paths and remote image sources that reach Sharp. For the Node adapter flaw, also reject unexpected Host values at the reverse proxy. Those measures reduce exposure; they do not replace the patched releases.

The bottom line

Astro 5.x cannot be patched for GHSA-26w7. The first fixed core release is 7.2.8, and the upgrade PR lands on 7.4.2 with Sharp 0.35.5. The same jump picks up the @astrojs/node 11.1.7 fix for GHSA-m8p5. Teams running Astro 5 with the default image service should schedule the major upgrade and verify the resolved Sharp version before the next deploy.

Sources: GHSA-26w7-cxv4-gfx2, GHSA-m8p5-r7qv-cx4c, and the Astro 7.2.8 release notes. Versions and advisory details were checked on 26 October 2026.