CVE-2026-25545
Published: 24 February 2026
Description
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,…
more
it will be fetched on `/500.html` and they can redirect this to any internal URL to read the response body through the first request. An attacker who can access the application without `Host:` header validation (eg. through finding the origin IP behind a proxy, or just by default) can fetch their own server to redirect to any internal IP. With this they can fetch cloud metadata IPs and interact with services in the internal network or localhost. For this to be vulnerable, a common feature needs to be used, with direct access to the server (no proxies). Version 9.5.4 fixes the issue.
Mitigating Controls (NIST 800-53 r5)AI
Timely remediation through patching to Astro version 9.5.4 directly eliminates the SSRF flaw in error page rendering triggered by Host header manipulation.
Boundary protection via reverse proxies or WAFs enforces Host header validation and prevents direct origin server access required for exploitation.
Input validation of the Host header prevents manipulation that causes the server to fetch attacker-controlled endpoints during error page rendering.
Security SummaryAI
CVE-2026-25545 is a Server-Side Request Forgery (SSRF) vulnerability, classified under CWE-918, affecting the Astro web framework prior to version 9.5.4. It impacts Server-Side Rendered (SSR) pages that return errors using prerendered custom error pages, such as 404.astro or 500.astro. The issue arises when the Host header is manipulated, leading the server to fetch content from an attacker-controlled endpoint, which can then redirect to internal resources. The vulnerability has a CVSS v3.1 base score of 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N), indicating high confidentiality impact with network accessibility and no privileges required.
An unauthenticated attacker with direct access to the Astro application—bypassing proxies or Host header validation, such as by discovering the origin IP—can exploit this by setting the Host header to their own server. This triggers a fetch to /500.html (or similar), allowing the attacker-controlled response to redirect the request to arbitrary internal URLs, including cloud metadata endpoints, localhost services, or other internal network resources. The attacker can then read the response body from these internal fetches via the initial request, enabling reconnaissance or interaction with sensitive internal systems.
Mitigation is available by upgrading to Astro version 9.5.4, which addresses the issue. Official advisories and patches are detailed in the Astro security advisory (GHSA-qq67-mvv5-fw3g), the release notes for @astrojs/node@9.5.4, and the fixing commit e01e98b063e90d274c42130ec2a60cc0966622c9 on GitHub. Direct server access without proxies is required for exploitation, and the feature involves common custom error page configurations.
Details
- CWE(s)
Affected Products
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
SSRF in public-facing Astro SSR app enables T1190 exploitation of web apps via Host header manipulation; directly facilitates T1522 by allowing redirects to and response retrieval from cloud metadata endpoints.