CVE-2025-55207: Astro Framework Open Redirect Vulnerability

CVE-2025-55207 Overview

CVE-2025-55207 is an open redirect vulnerability [CWE-601] in the Astro web framework affecting versions prior to 9.4.1. The flaw is an incomplete fix for CVE-2025-54793, which addressed protocol-relative URL redirection. When Astro is deployed using the Node adapter in standalone mode with trailingSlash set to "always", the framework still redirects requests such as https://example.com//astro.build/press to the external origin //astro.build/press. Attackers can craft links that appear to originate from a trusted Astro-hosted domain but silently redirect victims to attacker-controlled destinations. This enables phishing, credential theft, and malware distribution scenarios.

Critical Impact
Attackers can abuse trusted Astro-hosted domains to redirect victims to malicious sites, facilitating phishing and credential theft campaigns.

Affected Products

Astro framework versions prior to 9.4.1
Astro deployments using the Node adapter in standalone mode
Astro configurations with trailingSlash set to "always"

Discovery Timeline

2025-08-15 - CVE-2025-55207 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-55207

Vulnerability Analysis

The vulnerability resides in Astro's static file serving logic within the Node adapter. Astro 5.12.8 previously patched CVE-2025-54793 by rejecting protocol-relative paths that browsers interpret as external URLs. The fix was incomplete for a specific deployment configuration. When the Node adapter runs in standalone mode and trailingSlash is configured to "always", the framework's URL normalization logic reintroduces the redirect behavior.

A request path beginning with // is treated by browsers as a protocol-relative URL, meaning //astro.build/press resolves to https://astro.build/press. When Astro issues an HTTP redirect using this unsanitized path, the browser navigates to the attacker-specified external host rather than a local resource. The victim sees a legitimate-looking link on the trusted domain but lands on a page controlled by the attacker.

Root Cause

The root cause is missing validation of internal versus external paths in the serve-static.ts module of the Node integration. The pre-patch code did not distinguish between application-internal paths and paths that browsers would interpret as protocol-relative URLs. The patch introduces an isInternalPath helper from @astrojs/internal-helpers/path to enforce this distinction before generating redirect responses.

Attack Vector

Exploitation requires only that a victim clicks a specially crafted link pointing at an affected Astro deployment. No authentication, user interaction beyond the click, or privileged access is required. The attacker constructs a URL such as https://victim-astro-site.example//attacker.tld/phish and delivers it through email, chat, social media, or embedded content. The victim's browser receives an HTTP redirect from the trusted Astro domain and follows it to the attacker's site.

typescript

// Patch applied to packages/integrations/node/src/serve-static.ts
 import type { IncomingMessage, ServerResponse } from 'node:http';
 import path from 'node:path';
 import url from 'node:url';
-import { hasFileExtension } from '@astrojs/internal-helpers/path';
+import { hasFileExtension, isInternalPath } from '@astrojs/internal-helpers/path';
 import type { NodeApp } from 'astro/app/node';
 import send from 'send';
 import type { Options } from './types.js';

Source: GitHub Commit 5fc3c59. The patch imports and applies isInternalPath to reject protocol-relative paths before generating redirects.

Detection Methods for CVE-2025-55207

Indicators of Compromise

HTTP request paths beginning with // followed by an external hostname reaching Astro Node adapter endpoints
Web server access logs showing 301 or 302 redirect responses with Location headers pointing to external domains not owned by the deployment
Unusual referrer patterns in downstream systems showing traffic originating from trusted Astro-hosted URLs but landing on unfamiliar destinations

Detection Strategies

Inspect reverse proxy and Astro Node process logs for request paths matching the pattern ^//[^/]+
Correlate outbound redirect responses from Astro applications with the destination host in the Location header, flagging redirects to hosts outside the application's allowlist
Deploy web application firewall rules that normalize double-slash prefixes in request paths before they reach the Astro adapter

Monitoring Recommendations

Enable verbose HTTP access logging on the Node process and any fronting proxy to capture full request paths including leading slashes
Alert on redirect response codes paired with external Location header values from Astro-served hosts
Track user reports of unexpected redirects from your Astro-powered domains and correlate with server-side logs

How to Mitigate CVE-2025-55207

Immediate Actions Required

Upgrade Astro to version 9.4.1 or later across all deployments using the Node adapter
Inventory all Astro projects and identify those using the Node standalone adapter with trailingSlash: "always"
Review recent access logs for exploitation attempts and notify affected users if suspicious redirects were served

Patch Information

The vulnerability is patched in Astro 9.4.1. The fix adds an isInternalPath check in packages/integrations/node/src/serve-static.ts that rejects protocol-relative paths before they reach redirect handling. Details are documented in the GitHub Security Advisory GHSA-9x9c-ghc5-jhw9 and the corresponding patch commit.

Workarounds

Change trailingSlash to a value other than "always" if application design permits
Place a reverse proxy such as nginx in front of the Node adapter to normalize or reject request paths containing //
Deploy a WAF rule to block inbound requests where the URI path begins with //

bash

# nginx configuration to reject protocol-relative path requests
server {
    listen 443 ssl;
    server_name your-astro-site.example;

    # Reject requests where the path begins with //
    if ($request_uri ~ ^//) {
        return 400;
    }

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
    }
}