CVE-2026-54299

What it actually does

Astro SSR applications prior to version 6.4.6 can perform a server-side request to an attacker-chosen origin when serving prerendered error pages. If an application has prerendered /404 or /500 pages and does not validate the incoming Host header against allowedDomains, Astro derives the runtime fetch URL from request.url, whose origin can be controlled through the Host header. An unauthenticated remote attacker can therefore cause the server to fetch content from arbitrary internal or external hosts and expose the fetched response, resulting primarily in confidentiality impact with limited integrity impact.

Why it matters to the business

A vulnerable public-facing Astro SSR application could be abused as a proxy to reach systems that are not directly exposed to the internet, such as internal HTTP services, cloud metadata endpoints, or administrative interfaces reachable from the application server. This can lead to leakage of internal data, service metadata, credentials, or network topology. The current EPSS is low and there is no known CISA KEV listing or public exploit maturity reported, but affected internet-facing SSR applications should still be remediated because SSRF flaws can become high-impact when the application has access to privileged internal networks or cloud metadata services.

How an attack unfolds

An attacker sends a request to an Astro SSR application that will cause a prerendered error page to be served, such as requesting a nonexistent route for /404 behavior or triggering an application error for /500 behavior. The attacker supplies a crafted Host header pointing to a target origin they want the server to contact. In affected versions, Astro builds the URL used to fetch the prerendered error page from request.url, which can inherit that attacker-controlled Host value. The server then initiates an outbound HTTP request to the attacker-selected host. If the response is incorporated into the error handling flow and returned to the attacker, the attacker can read data from the target service as seen from the server-side network position. Practical exploitation depends on the application using Astro SSR, having prerendered /404 or /500 pages, lacking Host validation, and the targeted service returning useful content at the requested error-page path.

How to fix it

Upgrade Astro to version 6.4.6 or later. If immediate upgrade is not possible, enforce strict Host header validation using Astro's allowedDomains or equivalent reverse-proxy/application-layer controls so only expected production domains are accepted. Block requests with unrecognized Host headers at the CDN, load balancer, reverse proxy, or application edge. Review whether /404 and /500 pages are prerendered in SSR deployments and remove that configuration as a temporary mitigation if compatible with the application. Restrict outbound network access from application servers so they cannot reach cloud metadata endpoints, internal administrative services, or broad private address ranges unless explicitly required.

How to confirm the fix worked

Confirm the deployed Astro package version is 6.4.6 or later in package lockfiles, build artifacts, container images, and runtime dependency inventories. Verify that the application rejects or normalizes unexpected Host headers before they reach Astro. Test with a controlled canary domain in the Host header while requesting a nonexistent page; a fixed or properly mitigated deployment should not make an outbound request to that canary domain and should not return content from it. Review edge, proxy, and application configuration to ensure only approved domains are accepted. Validate egress controls by confirming the application cannot make HTTP requests to link-local metadata addresses, loopback addresses, or unnecessary private network ranges.

Typical attack path

1. Identify a public Astro SSR application running a vulnerable version before 6.4.6.
2. Confirm that the application serves prerendered /404 or /500 pages.
3. Send requests that trigger error handling, such as nonexistent paths or error-inducing requests.
4. Set the Host header to an attacker-controlled external host or an internal target reachable from the application server.
5. Observe whether the application server performs an outbound HTTP request to the supplied Host value.
6. Inspect the returned error response for content fetched from the attacker-selected host.
7. Iterate against internal addresses, metadata services, or other reachable HTTP endpoints to extract sensitive information.

How to detect it

To determine whether exploitation has already occurred, review web access logs, reverse-proxy logs, CDN logs, application logs, DNS resolver logs, egress proxy logs, firewall logs, and cloud VPC flow logs. Focus on requests that produced 404 or 500 responses and had Host headers that do not match the application's approved domains. Look for Host values containing IP addresses, loopback addresses, link-local metadata addresses, private RFC1918 ranges, unusual ports, or attacker-controlled domains. Correlate those inbound requests with near-simultaneous outbound HTTP/HTTPS connections from the Astro application server to the same Host value. Also look for outbound requests to cloud metadata services such as 169.254.169.254 or metadata.google.internal, internal service names, or unexpected external domains immediately following 404/500 responses. Because no specific public exploitation campaign or stable malware artifact is known from the provided intelligence, detection should emphasize behavioral correlation between malformed Host headers, error-page handling, and unexpected server-side egress.

• Host: 169.254.169.254
• Host: metadata.google.internal
• Host: 127.0.0.1
• Host: localhost
• Host: [::1]
• Host: 0.0.0.0
• Host: 10.
• Host: 172.16.
• Host: 172.17.
• Host: 172.18.
• Host: 172.19.
• Host: 172.20.
• Host: 172.21.
• Host: 172.22.
• Host: 172.23.
• Host: 172.24.
• Host: 172.25.
• Host: 172.26.
• Host: 172.27.
• Host: 172.28.
• Host: 172.29.
• Host: 172.30.
• Host: 172.31.
• Host: 192.168.
• GET /404
• GET /500
• POST /404
• POST /500
• 169.254.169.254/latest/meta-data
• metadata.google.internal/computeMetadata
• 169.254.169.254/metadata/instance

What your security team should do

• Prioritize upgrading all Astro SSR applications to Astro 6.4.6 or later, especially internet-facing services.
• Inventory Astro applications that use SSR and prerendered /404 or /500 pages; treat those as the highest-risk candidates.
• Enforce allowedDomains or equivalent Host header allowlisting at the application and reverse-proxy layers.
• Add egress restrictions for application workloads, including explicit blocks for cloud metadata endpoints and unnecessary internal address ranges.
• Search recent access logs for requests with suspicious or unexpected Host headers, especially requests resulting in 404 or 500 responses.
• Correlate web requests with outbound DNS, proxy, firewall, or VPC flow logs to identify server-side requests to attacker-controlled, link-local, loopback, or private network destinations.
• If suspicious activity is found, rotate any credentials potentially exposed through reachable metadata services or internal HTTP endpoints.