CVE-2026-25545: Astro @astrojs/node SSRF Vulnerability

CVE-2026-25545 Overview

CVE-2026-25545 is a Server-Side Request Forgery (SSRF) vulnerability affecting the Astro web framework's @astrojs/node adapter. The vulnerability exists in Server-Side Rendered (SSR) pages that return errors with prerendered custom error pages (such as 404.astro or 500.astro). An attacker who can access the application without Host: header validation can manipulate the Host: header to redirect internal requests through their controlled server, enabling access to internal network resources, cloud metadata endpoints, and localhost services.

Critical Impact

Attackers can exploit this SSRF vulnerability to access cloud metadata services (e.g., AWS IMDSv1 at 169.254.169.254), interact with internal network services, and potentially exfiltrate sensitive configuration data including credentials and API keys.

Affected Products

• Astro @astrojs/node adapter versions prior to 9.5.4
• Applications using Server-Side Rendering with custom error pages (404.astro, 500.astro)
• Deployments with direct server access without proxy-based Host header validation

Discovery Timeline

• 2026-02-24 - CVE-2026-25545 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-25545

Vulnerability Analysis

This SSRF vulnerability occurs when Astro's SSR engine processes error responses and attempts to fetch prerendered error pages. The application constructs the URL for fetching error pages using the incoming request's Host: header without proper validation. When an attacker supplies a malicious Host: header pointing to their controlled server, the Astro application will make a request to that server. The attacker's server can then respond with an HTTP redirect (3xx status code) pointing to any internal URL, causing the Astro server to follow the redirect and fetch the internal resource.

The vulnerability is classified under CWE-918 (Server-Side Request Forgery), which describes scenarios where web applications make server-side requests to attacker-specified URLs without adequate validation.

Root Cause

The root cause of this vulnerability lies in two related issues:

1. Insufficient Host Header Validation: The application trusts the Host: header from incoming requests when constructing URLs for fetching prerendered error pages, allowing attackers to redirect these requests to external servers.

2. Following Redirects Without Restriction: The fetch() calls in the Astro codebase followed HTTP redirects automatically, enabling attackers to redirect the initial request to internal resources that should not be externally accessible.

Attack Vector

The attack requires network access to the Astro application, typically achieved by:

1. Bypassing Proxies: Finding the origin server IP behind CDN/reverse proxy configurations
2. Direct Access: Targeting applications deployed without proxy layers that validate Host headers

The attacker modifies the Host: header to point to their malicious server. When the Astro application encounters an error and attempts to fetch the custom error page, it makes a request to the attacker's server. The attacker responds with a redirect to an internal URL (such as http://169.254.169.254/latest/meta-data/ for AWS instance metadata), and the Astro server follows this redirect, returning the internal response data to the attacker.

// Vulnerable code - fetch followed redirects automatically
const res = await fetch(req);

// Patched code - redirects are now blocked
const res = await fetch(req, { redirect: 'manual' });

if (res.status >= 300 && res.status < 400) {
	throw new Error(`Failed to load remote image ${src}. The request was redirected.`);
}

Source: GitHub Commit e01e98b

Detection Methods for CVE-2026-25545

Indicators of Compromise

• Unusual outbound HTTP requests from the Astro application to external IP addresses or domains
• HTTP requests to cloud metadata endpoints (e.g., 169.254.169.254, metadata.google.internal)
• Abnormal Host: header values in incoming requests that don't match expected domains
• Server logs showing requests with mismatched Host headers and actual destination IPs

Detection Strategies

• Monitor outbound network traffic from application servers for connections to internal IP ranges (10.x.x.x, 172.16.x.x, 192.168.x.x) or cloud metadata IPs
• Implement Web Application Firewall (WAF) rules to detect and block requests with suspicious Host header values
• Enable logging for all outbound HTTP requests from the application and alert on requests to non-whitelisted destinations
• Review access logs for error page requests (404, 500 responses) with anomalous Host headers

Monitoring Recommendations

• Configure network monitoring to alert on outbound connections from web servers to internal services or metadata endpoints
• Implement application-level logging that captures the full request headers, especially Host headers, for error responses
• Set up alerts for any fetch operations that result in redirect responses, as these may indicate exploitation attempts
• Monitor for increased error rates that could indicate attackers probing for vulnerable error page handling

How to Mitigate CVE-2026-25545

Immediate Actions Required

• Upgrade @astrojs/node to version 9.5.4 or later immediately
• Implement Host header validation at the reverse proxy or CDN layer to reject requests with unexpected Host values
• Review and restrict outbound network access from application servers to prevent access to internal networks and cloud metadata services
• Audit existing deployments for direct server access without proxy protection

Patch Information

The Astro team has released version 9.5.4 of the @astrojs/node adapter which addresses this vulnerability. The fix adds the redirect: 'manual' option to fetch requests and explicitly handles redirect responses by blocking them, preventing attackers from using redirects to access internal resources.

To update, run:

npm update @astrojs/node

For additional details, refer to the GitHub Security Advisory GHSA-qq67-mvv5-fw3g and the Release Notes for v9.5.4.

Workarounds

• Deploy applications behind a reverse proxy (e.g., nginx, Cloudflare) that validates and sanitizes the Host header before forwarding requests
• Implement network-level controls to block outbound connections from the application server to internal IP ranges and cloud metadata services
• Use egress filtering to whitelist only necessary outbound destinations from the application tier
• If custom error pages are not required, consider removing prerendered error pages (404.astro, 500.astro) as a temporary mitigation

# Nginx configuration to validate Host header
server {
    listen 80;
    server_name example.com www.example.com;
    
    # Reject requests with unexpected Host headers
    if ($host !~* ^(example\.com|www\.example\.com)$) {
        return 444;
    }
    
    location / {
        proxy_pass http://astro_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}