CyberSecBulletin

Astro vulnerabilities

We track 5 vulnerabilities in Astro products across 2 products. 5 are rated high or critical, and none are known to be exploited. The most recent was published on March 24, 2026.

5vulnerabilities
1critical
4high
0exploited
8.0average CVSS score

Latest Astro vulnerabilities

  • 9.1 Critical severity

    astro: Unintended Proxy or Intermediary

    CVE-2026-33768Withastro

    Astro is a web framework. Prior to version 10.0.2, the @astrojs/vercel serverless entrypoint reads the x-astro-path header and x_astro_path query parameter to rewrite the internal request path, with no authentication whatsoever. On deployments without Edge Mid

  • 7.5 High severity

    astro: Allocation of Resources Without Limits or Throttling

    CVE-2026-29772Withastro

    Astro is a web framework. Prior to version 10.0.0, Astro's Server Islands POST handler buffers and parses the full request body as JSON without enforcing a size limit. Because JSON.parse() allocates a V8 heap object for every element in the input, a crafted pa

  • 7.2 High severity

    astro: Server-Side Request Forgery

    CVE-2026-27829Withastro

    Astro is a web framework. In versions 9.0.0 through 9.5.3, a bug in Astro's image pipeline allows bypassing `image.domains` / `image.remotePatterns` restrictions, enabling the server to fetch content from unauthorized remote hosts. Astro provides an `inferSize

  • 7.5 High severity

    astro: Allocation of Resources Without Limits or Throttling

    CVE-2026-27729Withastro

    Astro is a web framework. In versions 9.0.0 through 9.5.3, Astro server actions have no default request body size limit, which can lead to memory exhaustion DoS. A single large POST to a valid action endpoint can crash the server process on memory-constrained

  • 8.6 High severity

    astro: Server-Side Request Forgery

    CVE-2026-25545WithastroEPSS 1.93%

    Astro is a web framework. Prior to version 9.5.4, Server-Side Rendered pages that return an error with a prerendered custom error page (eg. `404.astro` or `500.astro`) are vulnerable to SSRF. If the `Host:` header is changed to an attacker's server, it will be