CVE-2025-64525: Astro Auth Bypass Vulnerability

CVE-2025-64525 Overview

CVE-2025-64525 affects the Astro web framework when configured for on-demand rendering. Astro versions from 2.16.0 up to but excluding 5.15.5 use the x-forwarded-proto and x-forwarded-port request headers without sanitization when constructing URLs. Attackers can manipulate these headers to bypass middleware-protected routes, trigger Server-Side Request Forgery (SSRF), and poison CDN caches. The issue is tracked under CWE-918: Server-Side Request Forgery. Version 5.15.5 contains the patch.

Critical Impact
Unauthenticated remote attackers can bypass middleware access controls, poison CDN caches for Denial of Service (DoS), induce SSRF, and evade Web Application Firewall (WAF) rules by sending crafted x-forwarded-proto and x-forwarded-port headers.

Affected Products

Astro framework versions 2.16.0 through 5.15.4 (on-demand rendering mode)
Node.js adapter using packages/astro/src/core/app/node.ts
Deployments fronted by CDNs or reverse proxies that forward client-controlled x-forwarded-* headers

Discovery Timeline

2025-11-13 - CVE-2025-64525 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-64525

Vulnerability Analysis

Astro's on-demand rendering pipeline constructs the incoming request URL from HTTP headers supplied by upstream proxies. The Node.js adapter reads x-forwarded-proto and x-forwarded-port directly, trusting attacker-controlled values without validation. The reconstructed URL then flows into routing, middleware, and any server-side fetch() calls that reference Astro.url or request.url.

Because middleware often decides authorization based on the URL scheme, an attacker who sets x-forwarded-proto: javascript or an unexpected value can alter the effective URL that middleware sees. The same untrusted value can be reflected back to CDNs as part of cached response variants, producing cache poisoning. Server-side code that fetches resources relative to the constructed URL can be coerced into SSRF against internal hosts.

Root Cause

The root cause is missing input validation on forwarded headers inside the Node.js request adapter. The code path in packages/astro/src/core/app/node.ts used the header values verbatim to assemble the URL protocol and port. There was no allowlist for schemes such as http and https, and no numeric validation on the port.

Attack Vector

An unauthenticated attacker sends an HTTP request through the CDN or directly to the origin with crafted forwarded headers. Sample malicious headers include x-forwarded-proto: file or x-forwarded-port: 22. The framework then treats the request as if it arrived over the attacker-specified scheme, altering middleware decisions, cache keys, and outbound request targets.

typescript

// Security patch from packages/astro/src/core/app/node.ts
// Commit: dafbb1ba29912099c4faff1440033edc768af8b4
// Fix: Prevent cache poisoning in x-forwarded headers (#14743)

 import type { IncomingMessage, ServerResponse } from 'node:http';
 import { Http2ServerResponse } from 'node:http2';
 import type { Socket } from 'node:net';
-// matchPattern is used in App.validateForwardedHost, no need to import here
 import type { RemotePattern } from '../../types/public/config.js';
 import type { RouteData } from '../../types/public/internal.js';
 import { clientAddressSymbol, nodeRequestAbortControllerCleanupSymbol } from '../constants.js';

Source: GitHub Commit dafbb1b. The patch introduces validation of forwarded values and centralizes host and protocol handling to reject untrusted inputs.

Detection Methods for CVE-2025-64525

Indicators of Compromise

Requests containing x-forwarded-proto values other than http or https, such as file, gopher, or javascript
Requests containing non-numeric or out-of-range x-forwarded-port values
Anomalous CDN cache variants keyed on abnormal protocol or port values
Middleware bypass patterns where protected routes return 200 responses to unauthenticated clients

Detection Strategies

Inspect reverse proxy and CDN access logs for unusual x-forwarded-proto and x-forwarded-port values
Correlate spikes in cache MISS ratios with header anomalies to identify cache poisoning attempts
Audit server-side outbound connections originating from Astro processes for requests to internal or link-local addresses

Monitoring Recommendations

Enable WAF logging for all x-forwarded-* headers and alert on values outside an allowlist
Monitor Astro process egress traffic and flag connections to RFC1918, 169.254.0.0/16, and localhost ranges
Track HTTP 401 to 200 transitions on middleware-protected routes as a bypass indicator

How to Mitigate CVE-2025-64525

Immediate Actions Required

Upgrade Astro to version 5.15.5 or later on all applications using on-demand rendering
Configure the reverse proxy or CDN to strip inbound x-forwarded-proto and x-forwarded-port headers from client requests and set them authoritatively
Review middleware code that makes decisions based on Astro.url.protocol or Astro.url.port and add explicit validation

Patch Information

Astro version 5.15.5 contains the fix delivered in commit dafbb1b. Details are published in the GitHub Security Advisory GHSA-hr2q-hp5q-x767. Deployments using static rendering only are not affected.

Workarounds

If patching is not immediately possible, configure the upstream proxy to overwrite x-forwarded-proto and x-forwarded-port with trusted values on every request
Deploy WAF rules that reject requests where x-forwarded-proto is not http or https, and where x-forwarded-port is not numeric within the expected range
Disable on-demand rendering for routes that do not require it and serve them as static pages

bash

# Example NGINX configuration to normalize forwarded headers before Astro
location / {
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Port  $server_port;
    proxy_set_header X-Forwarded-Host  $host;
    proxy_pass http://astro_upstream;
}