Critical RCE Bug Hits Astro's Image Pipeline — One MCP Server Exposed

A single malicious image file. That's all it takes to get remote code execution on a server running an outdated Astro image pipeline — and one MCP server in the registry is exposed right now.

What's broken

The vulnerability lives in libheif, the library Astro's default Sharp image service uses to decode AVIF files. When Astro is asked to optimize an untrusted AVIF image, a crafted file can trigger remote code execution during processing.

The attack surface isn't exotic. Any project that lets users upload images, pulls images from external sources, or otherwise processes AVIF files it didn't create is exposed the moment that content flows through Astro's image optimizer.

Who's affected

com.sigaoli/profile carries this advisory. It's built on Astro and inherits the vulnerable image pipeline unless it's already been patched past the fixed version.

What to do about it

The fix is not optional and not complicated: upgrade to Astro 7.2.8 or later, which pulls in the patched Sharp 0.35.4. There's no configuration workaround here — the vulnerability is in the decode path itself, not in how you've wired Astro's image service.

Practical steps:

• Check your package.json for Astro's current version. Anything below 7.2.8 is vulnerable.
• Verify Sharp separately — Astro can be updated without automatically bumping Sharp if it's pinned or overridden elsewhere in the dependency tree.
• Audit image inputs. If your deployment accepts user-uploaded images or fetches images from third-party sources and runs them through Astro's optimizer, treat that as an active exposure until the patch lands.
• Don't assume "we don't handle AVIF" is a mitigation. Astro's default image service can be invoked on files regardless of extension if content-type sniffing or format conversion is in play — the safest assumption is that any image path through Sharp is affected.

This is the pattern worth internalizing: image optimization pipelines are a favorite target precisely because they feel like plumbing, not attack surface. Nobody threat-models their thumbnail generator. That's exactly why libheif bugs keep resurfacing as RCE vectors across the JS ecosystem.

If you're running an Astro-based MCP server anywhere near untrusted image input, this is your reminder that "it's just image resizing" is not a security boundary.

Patch now, ask questions later.