Astro CVE-2025-61925

Exploitation requires Astro to be running in on-demand/dynamic (SSR) rendering mode via a server adapter such as the Node adapter - statically generated Astro sites are NOT affected - AND application code that consumes Astro.url (e.g. for canonical links, login/registration, or form action URLs). The reverse proxy / web server in front (such as nginx) must forward the attacker-supplied X-Forwarded-Host header to the app. For the per-request case the impact is confined to the attacker's own session; the high-impact cross-user case additionally requires a caching proxy (e.g. Cloudflare) configured with a non-zero cache TTL so the poisoned value persists to other users. Limiting factors: no auth and no user interaction are needed (PR:N/UI:N), but the dependence on SSR mode, actual use of Astro.url in code, header-forwarding configuration, and a cache for stored impact all substantially narrow the realistic attack surface.

This is a moderate, context-dependent risk rather than a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) correctly reflects that a remote, unauthenticated attacker can trigger the flaw with a single crafted request and no user interaction, which is why the base score lands at 6.5. However, the real-world severity signals are modest and consistent with each other: EPSS is low at 0.41% (33rd percentile), the CVE is NOT on CISA KEV, and there is no evidence of active exploitation - only a publicly available proof-of-concept exists (the minimal demo server plus curl commands in the GitHub advisory). The CWE-470 label is a poor fit for what is functionally a host-header-injection / cache-poisoning issue, so do not over-weight it. The impact is genuinely limited by exploitation conditions: it only matters when Astro runs in on-demand/SSR mode, application code actually consumes Astro.url (e.g. for canonical links or form actions), and - for the dangerous cross-user case - a caching proxy persists the poisoned value. A single-user per-request reflection is low impact; the escalation to a stored/cached open-redirect affecting other users is what justifies attention. Net: a real but config-gated priority for teams running dynamic Astro behind a cache, and a non-issue for the large share of Astro deployments that are statically generated.

An attacker sends an HTTP request to a dynamically-rendered Astro site with a legitimate Host header and a malicious X-Forwarded-Host header (e.g. www.evil.com); Astro reflects the attacker-controlled value through Astro.url, corrupting a canonical link or form action to point at the attacker's domain. If the site sits behind a caching proxy with a non-zero TTL, the poisoned page is cached and served to subsequent legitimate visitors, enabling credential-harvesting redirects or SEO/phishing abuse. A working proof-of-concept (a minimal Astro server plus curl reproduction steps) is publicly documented in the GitHub Security Advisory.