withastro up to 5.14.1 Header X-Forwarded-Host externally-controlled input to select classes or code

Summaryinfo

A vulnerability, which was classified as critical, has been found in withastro astro up to 5.14.1. This vulnerability affects unknown code of the component Header Handler. This manipulation of the argument X-Forwarded-Host causes use of externally-controlled input to select classes or code. The identification of this vulnerability is CVE-2025-61925. It is possible to initiate the attack remotely. There is no exploit available. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability classified as critical was found in withastro astro up to 5.14.1. Affected by this vulnerability is an unknown functionality of the component Header Handler. The manipulation of the argument X-Forwarded-Host with an unknown input leads to a use of externally-controlled input to select classes or code vulnerability. The CWE definition for the vulnerability is CWE-470. 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. As an impact it is known to affect integrity, and availability. The summary by CVE is:

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.

It is possible to read the advisory at github.com. This vulnerability is known as CVE-2025-61925 since 10/04/2025. The exploitation appears to be easy. The attack can be launched remotely. The exploitation doesn't need any form of authentication. Technical details of the vulnerability are known, but there is no available exploit.

Upgrading to version 5.14.2 eliminates this vulnerability.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Vendor

• withastro

Name

• astro

Version

• 5.14.0
• 5.14.1

Website

• Product: https://github.com/withastro/astro/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion