VulnerabilityPublished 10 Oct 2025

CVE-2025-61925: withastro astro · Unsafe Reflection

Affects withastro astroSource CVE Database V5

Not known to be exploited · CVSS 6.5 Medium : upgrade to 5.14.2 when convenient.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 3.1 base score

6.5Medium

How severe the flaw is on the 0–10 CVSS scale.

EPSS: 0.4% chance of exploitation in 30 days – higher than 34% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in 5.14.2

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

Attack Vector: Network
Attack Complexity: Low
Privileges Required: None
User Interaction: None
Scope: Unchanged
Confidentiality: None
Integrity: Low
Availability: Low

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable component is bound to the network stack and the set of possible attackers extends beyond the other options listed, up to and including the entire Internet. Such a vulnerability is often termed 'remotely exploitable' and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: Low: Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
Privileges Required: None: The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.
User Interaction: None: The vulnerable system can be exploited without any interaction from any user.
Scope: Unchanged: An exploited vulnerability can only affect resources managed by the same security authority. In this case, the vulnerable component and the impacted component are either the same, or both are managed by the same security authority.
Confidentiality: None: There is no loss of confidentiality within the impacted component.
Integrity: Low: Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact on the impacted component.
Availability: Low: Performance is reduced or there are interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the impacted component are either partially available all of the time, or fully available only some of the time, but overall there is no direct, serious consequence to the impacted component.

Definitions: FIRST CVSS v3.1 specification.

Exploitation evidence

Disclosed: evidence found.
CVE published 10 Oct 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade withastro astro to 5.14.2.

Affected software

Product	Affected	Fixed in
withastro astro	Affected <5.14.2	Fixed in 5.14.2

AI-suggested

European organizations should immediately upgrade all Astro framework instances to version 5.14.2 or later, where the vulnerability is patched. For environments where immediate upgrade is not feasible, implement strict validation and sanitization of the X-Forwarded-Host header at the web server or application gateway level, ensuring only trusted domains are accepted. Configure caching proxies to avoid caching responses that include user-controllable headers or disable caching for dynamic pages that use Astro.url. Employ Content Security Policy (CSP) headers to restrict redirection targets and mitigate the impact of malicious URL injection. Conduct thorough code reviews to identify any usage of Astro.url that could be influenced by headers and refactor to use safer alternatives or explicit allowlists. Monitor web logs for anomalous requests with mismatched Host and X-Forwarded-Host headers. Educate developers on the risks of unsafe reflection and the importance of header validation. Finally, integrate automated security testing in CI/CD pipelines to detect similar header injection issues in future development.

Description

Astro is a web framework. Prior to version 5.14.2, Astro reflects the value in `X-Forwarded-Host` in output when using `Astro.url` without any validation. It is common for web servers such as nginx to route requests via the `Host` header, and forward on other request headers. As such as malicious request can be sent with both a `Host` header and an `X-Forwarded-Host` header where the values do not match and the `X-Forwarded-Host` header is malicious. Astro will then return the malicious value. This could result in any usages of the `Astro.url` value in code being manipulated by a request. For example if a user follows guidance and uses `Astro.url` for a canonical link the canonical link can be manipulated to another site. It is theoretically possible that the value could also be used as a login/registration or other form URL as well, resulting in potential redirecting of login credentials to a malicious party. As this is a per-request attack vector the surface area would only be to the malicious user until one considers that having a caching proxy is a common setup, in which case any page which is cached could persist the malicious value for subsequent users. Many other frameworks have an allowlist of domains to validate against, or do not have a case where the headers are reflected to avoid such issues. This could affect anyone using Astro in an on-demand/dynamic rendering mode behind a caching proxy. Version 5.14.2 contains a fix for the issue.

Impact

For European organizations, this vulnerability poses a risk primarily to web applications built using vulnerable versions of the Astro framework (<5.14.2) that rely on dynamic or on-demand rendering and are deployed behind caching proxies such as nginx. The manipulation of URLs can lead to phishing attacks, credential interception, and user redirection to malicious sites, undermining user trust and potentially causing data integrity issues. Cached malicious responses can affect multiple users, increasing the scope of impact. Industries with high web presence such as e-commerce, finance, government portals, and healthcare could be particularly affected due to the sensitivity of user credentials and data. The vulnerability does not directly expose confidential data but can facilitate indirect compromise through social engineering or session hijacking. Availability could also be impacted if attackers exploit the vulnerability to disrupt normal URL routing or cause denial of service via cache poisoning. Given the widespread adoption of Astro in modern web development and the common use of caching proxies in European IT infrastructure, the threat is relevant and should be addressed promptly to avoid reputational damage and regulatory consequences under GDPR if user data is compromised.

Summary

CVE-2025-61925 is a vulnerability classified under CWE-470 (Use of Externally-Controlled Input to Select Classes or Code, also known as Unsafe Reflection) affecting the Astro web framework versions prior to 5.14.2. The core issue arises because Astro reflects the value of the HTTP header X-Forwarded-Host in the output of Astro.url without any validation or sanitization. Typically, web servers like nginx use the Host header to route requests and forward other headers such as X-Forwarded-Host. An attacker can craft a request with mismatched Host and X-Forwarded-Host headers, injecting malicious values into Astro.url output. This can manipulate URLs used in the application, such as canonical links or login/registration URLs, potentially redirecting users to attacker-controlled domains. This redirection can facilitate phishing or credential theft. The risk is amplified in setups where Astro is used in on-demand or dynamic rendering mode behind caching proxies, as maliciously crafted pages can be cached and served to subsequent users, expanding the attack surface beyond the initial attacker. Unlike many other frameworks that implement allowlists or avoid reflecting such headers, Astro lacked this validation prior to version 5.14.2. The vulnerability has a CVSS v3.1 score of 6.5 (medium severity), with network attack vector, low attack complexity, no privileges or user interaction required, impacting integrity and availability but not confidentiality directly. No known exploits are currently reported in the wild. The fix involves proper validation or sanitization of the X-Forwarded-Host header before reflecting it in Astro.url output, as implemented in version 5.14.2.

CWE-470Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') (opens in a new tab)
Base weaknessOWASP Top 10 A05:2025: Injection (opens in a new tab)
The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.
Architecture and Design
Refactor your code to avoid using reflection.
Architecture and Design
Do not use user-controlled inputs to select and load classes or code.
Implementation
Apply strict input validation by using allowlists or indirect selection to ensure that the user is only selecting allowable classes or code.
OWASP Cheat Sheets
XML Security (opens in a new tab)
Mass Assignment (opens in a new tab)
Injection Prevention (opens in a new tab)
SQL Injection Prevention (opens in a new tab)
Injection Prevention in Java (opens in a new tab)
OWASP ASVS 4.0.3
V13.3.1 (opens in a new tab)
V5.1.4 (opens in a new tab)
V5.1.3 (opens in a new tab)
Attack patterns
Reflection Injection (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…

Exploitation evidence

What to do

Affected software

Description

AI analysisMachine-generated, updated 10 Oct 2025, 19:53 UTC

WeaknessesCWE-470

Technical details

References

Community reviews

Related threats