chore(deps): update dependency astro to v5.15.6 [security] #9749

renovate · 2025-10-11T01:11:03Z

This PR contains the following updates:

Package	Change	Age	Confidence
astro (source)	`5.5.6` -> `5.15.6`

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

GitHub Vulnerability Alerts

CVE-2025-54793

Summary

There is an Open Redirection vulnerability in the trailing slash redirection logic when handling paths with double slashes. This allows an attacker to redirect users to arbitrary external domains by crafting URLs such as https://mydomain.com//malicious-site.com/. This increases the risk of phishing and other social engineering attacks.

This affects Astro >=5.2.0 sites that use on-demand rendering (SSR) with the Node or Cloudflare adapter. It does not affect static sites, or sites deployed to Netlify or Vercel.

Background

Astro performs automatic redirection to the canonical URL, either adding or removing trailing slashes according to the value of the trailingSlash configuration option. It follows the following rules:

If trailingSlash is set to "never", https://example.com/page/ will redirect to https://example.com/page
If trailingSlash is set to "always", https://example.com/page will redirect to https://example.com/page/

It also collapses multiple trailing slashes, according to the following rules:

If trailingSlash is set to "always" or "ignore" (the default), https://example.com/page// will redirect to https://example.com/page/
If trailingSlash is set to "never", https://example.com/page// will redirect to https://example.com/page

It does this by returning a 301 redirect to the target path. The vulnerability occurs because it uses a relative path for the redirect. To redirect from https://example.com/page to https://example.com/page/, it sending a 301 response with the header Location: /page/. The browser resolves this URL relative to the original page URL and redirects to https://example.com/page/

Details

The vulnerability occurs if the target path starts with //. A request for https://example.com//page will send the header Location: //page/. The browser interprets this as a protocol-relative URL, so instead of redirecting to https://example.com//page/, it will attempt to redirect to https://page/. This is unlikely to resolve, but by crafting a URL in the form https://example.com//target.domain/subpath, it will send the header Location: //target.domain/subpath/, which the browser translates as a redirect to https://target.domain/subpath/. The subpath part is required because otherwise Astro will interpret /target.domain as a file download, which skips trailing slash handling.

This leads to an Open Redirect vulnerability.

The URL needed to trigger the vulnerability varies according to the trailingSlash setting.

If trailingSlash is set to "never", a URL in the form https://example.com//target.domain/subpath/
If trailingSlash is set to "always", a URL in the form https://example.com//target.domain/subpath
For any config value, a URL in the form https://example.com//target.domain/subpath//

Impact

This is classified as an Open Redirection vulnerability (CWE-601). It affects any user who clicks on a specially crafted link pointing to the affected domain. Since the domain appears legitimate, victims may be tricked into trusting the redirected page, leading to possible credential theft, malware distribution, or other phishing-related attacks.

No authentication is required to exploit this vulnerability. Any unauthenticated user can trigger the redirect by clicking a malicious link.

Mitigation

You can test if your site is affected by visiting https://yoursite.com//docs.astro.build/en//. If you are redirected to the Astro docs then your site is affected and must be updated.

Upgrade your site to Astro 5.12.8. To mitigate at the network level, block outgoing redirect responses with a Location header value that starts with //.

CVE-2025-55303

Summary

In affected versions of astro, the image optimization endpoint in projects deployed with on-demand rendering allows images from unauthorized third-party domains to be served.

Details

On-demand rendered sites built with Astro include an /_image endpoint which returns optimized versions of images.

The /_image endpoint is restricted to processing local images bundled with the site and also supports remote images from domains the site developer has manually authorized (using the image.domains or image.remotePatterns options).

However, a bug in impacted versions of astro allows an attacker to bypass the third-party domain restrictions by using a protocol-relative URL as the image source, e.g. /_image?href=//example.com/image.png.

Proof of Concept

Create a new minimal Astro project ([email protected]).

Configure it to use the Node adapter (@astrojs/[email protected] — newer versions are not impacted):

// astro.config.mjs
import { defineConfig } from 'astro/config';
import node from '@&#8203;astrojs/node';

export default defineConfig({
	adapter: node({ mode: 'standalone' }),
});

Build the site by running astro build.
Run the server, e.g. with astro preview.
Append /_image?href=//placehold.co/600x400 to the preview URL, e.g. http://localhost:4321/_image?href=//placehold.co/600x400
The site will serve the image from the unauthorized placehold.co origin.

Impact

Allows a non-authorized third-party to create URLs on an impacted site’s origin that serve unauthorized image content.
In the case of SVG images, this could include the risk of cross-site scripting (XSS) if a user followed a link to a maliciously crafted SVG.

CVE-2025-61925

Summary

When running Astro in on-demand rendering mode using a adapter such as the node adapter it is possible to maliciously send an X-Forwarded-Host header that is reflected when using the recommended Astro.url property as there is no validation that the value is safe.

Details

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 not impossible to imagine 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.

PoC

Check out the minimal Astro example found here: https://github.com/Chisnet/minimal_dynamic_astro_server
nvm use
yarn run build
node ./dist/server/entry.mjs
curl --location 'http://localhost:4321/' --header 'X-Forwarded-Host: www.evil.com' --header 'Host: www.example.com'
Observe that the response reflects the malicious X-Forwarded-Host header

For the more advanced / dangerous attack vector deploy the application behind a caching proxy, e.g. Cloudflare, set a non-zero cache time, perform the above curl request a few times to establish a cache, then perform the request without the malicious headers and observe that the malicious data is persisted.

Impact

This could affect anyone using Astro in an on-demand/dynamic rendering mode behind a caching proxy.

CVE-2025-64745

Summary

A Reflected Cross-Site Scripting (XSS) vulnerability exists in Astro's development server error pages when the trailingSlash configuration option is used. An attacker can inject arbitrary JavaScript code that executes in the victim's browser context by crafting a malicious URL. While this vulnerability only affects the development server and not production builds, it could be exploited to compromise developer environments through social engineering or malicious links.

Details

Vulnerability Location

https://github.com/withastro/astro/blob/5bc37fd5cade62f753aef66efdf40f982379029a/packages/astro/src/template/4xx.ts#L133-L149

Root Cause

The vulnerability was introduced in commit 536175528 (PR #12994) , as part of a feature to "redirect trailing slashes on on-demand rendered pages." The feature added a helpful 404 error page in development mode to alert developers of trailing slash mismatches.

Issue: The corrected variable, which is derived from the user-controlled pathname parameter, is directly interpolated into the HTML without proper escaping. While the pathname variable itself is escaped elsewhere in the same file (line 114: escape(pathname)), the corrected variable is not sanitized before being inserted into both the href attribute and the link text.

Attack Vector

When a developer has configured trailingSlash to 'always' or 'never' and visits a URL with a mismatched trailing slash, the development server returns a 404 page containing the vulnerable template. An attacker can craft a URL with JavaScript payloads that will be executed when the page is rendered.

PoC

Local Testing (localhost)

Basic vulnerability verification in local development environment

Show details

astro.config.mjs:

import { defineConfig } from 'astro/config';

export default defineConfig({
  trailingSlash: 'never', // or 'always'
  server: {
    port: 3000,
    host: true
  }
});

package.json:

{
  "name": "astro-xss-poc-victim",
  "version": "0.1.0",
  "scripts": {
    "dev": "astro dev"
  },
  "dependencies": {
    "astro": "5.15.5"
  }
}

Start the development server:

npm install
npm run dev

Access the following malicious URL depending on your configuration:

For trailingSlash: 'never' (requires trailing slash):

http://localhost:3000/"></code><script>alert(document.domain)</script><!--/

For trailingSlash: 'always' (no trailing slash):

http://localhost:3000/"></code><script>alert(document.domain)</script><!--

When accessing the malicious URL:

The development server returns a 404 page due to trailing slash mismatch
The JavaScript payload (alert(document.domain)) executes in the browser
An alert dialog appears, demonstrating arbitrary code execution

Remote Testing (ngrok)

Reproduce realistic attack scenario via external malicious link

Show details

Prerequisites: ngrok account and authtoken configured (ngrok config add-authtoken <key>)

Setup and Execution:

#!/bin/bash
set -e

mkdir -p logs

npm i
npm run dev > ./logs/victim.log 2>&1 &

ngrok http 3000 > ./logs/ngrok.log 2>&1 &

sleep 3

NGROK_URL=$(curl -s http://localhost:4040/api/tunnels | grep -o '"public_url":"https://[^"]*' | head -1 | cut -d'"' -f4)
echo ""
echo "=== Attack URLs ==="
echo ""
echo "For trailingSlash: 'never' (requires trailing slash):"
echo "${NGROK_URL}/\"></code><script>alert(document.domain)</script><!--/"
echo ""
echo "For trailingSlash: 'always' (no trailing slash):"
echo "${NGROK_URL}/\"></code><script>alert(document.domain)</script><!--"
echo ""
wait

When a remote user accesses either of the generated attack URLs:

The request is tunneled through ngrok to the local development server
The development server returns a 404 page due to trailing slash mismatch
The JavaScript payload (alert(document.domain)) executes in the user's browser

Both URL patterns work depending on your trailingSlash configuration ('never' or 'always').

Impact

This only affects the development server. Risk depends on how and where the dev server is exposed.

Security impact

Developer environment compromise: Visiting a crafted URL can run arbitrary JS in the developer's browser.
Session hijacking: Active developer sessions can be stolen if services are open in the browser.
Local resource access: JS may probe localhost endpoints or dev tools depending on browser policies.
Supply-chain risk: Malicious packages or CI that start dev servers can widen exposure.

Attack scenarios

Social engineering: Malicious link sent to a developer triggers the XSS when opened.
Malicious documentation: Attack URLs embedded in issues, PRs, chat, or docs.
Dependency/CI abuse: Packages or automation that spawn public dev servers expose many targets.

Remediation

The fix is straightforward and requires escaping the corrected variable before inserting it into the HTML template. The codebase already imports and uses the escape() function from the html-escaper package.

CVE-2025-64525

Summary

In impacted versions of Astro using on-demand rendering, request headers x-forwarded-proto and x-forwarded-port are insecurely used, without sanitization, to build the URL. This has several consequences the most important of which are:

Middleware-based protected route bypass (only via x-forwarded-proto)
DoS via cache poisoning (if a CDN is present)
SSRF (only via x-forwarded-proto)
URL pollution (potential SXSS, if a CDN is present)
WAF bypass

Details

The x-forwarded-proto and x-forwarded-port headers are used without sanitization in two parts of the Astro server code. The most important is in the createRequest() function. Any configuration, including the default one, is affected:

https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L97
https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L121

These header values are then used directly to construct URLs.

By injecting a payload at the protocol level during URL creation (via the x-forwarded-proto header), the entire URL can be rewritten, including the host, port and path, and then pass the rest of the URL, the real hostname and path, as a query so that it doesn't affect (re)routing.

If the following header value is injected when requesting the path /ssr:

x-forwarded-proto: https://www.malicious-url.com/?tank=

The complete URL that will be created is: https://www.malicious-url.com/?tank=://localhost/ssr

As a reminder, URLs are created like this:

url = new URL(`${protocol}://${hostnamePort}${req.url}`);

The value is injected at the beginning of the string (${protocol}), and ends with a query ?tank= whose value is the rest of the string, ://${hostnamePort}${req.url}.

This way there is control over the routing without affecting the path, and the URL can be manipulated arbitrarily. This behavior can be exploited in various ways, as will be seen in the PoC section.

The same logic applies to x-forwarded-port, with a few differences.

Note

The createRequest function is called every time a non-static page is requested. Therefore, all non-static pages are exploitable for reproducing the attack.

PoC

The PoC will be tested with a minimal repository:

Latest Astro version at the time (2.16.0)
The Node adapter
Two simple pages, one SSR (/ssr), the other simulating an admin page (/admin) protected by a middleware
A middleware example copied and pasted from the official Astro documentation to protect the admin page based on the path

Download the PoC repository

Middleware-based protected route bypass - x-forwarded-proto only

The middleware has been configured to protect the /admin route based on the official documentation:

// src/middleware.ts
import { defineMiddleware } from "astro/middleware";

export const onRequest = defineMiddleware(async (context, next) => {
  const isAuthed = false; // auth logic
  if (context.url.pathname === "/admin" && !isAuthed) {
    return context.redirect("/");
  }
  return next();
});

When tryint to access /admin the attacker is naturally redirected :
```
curl -i http://localhost:4321/admin
```
The attackr can bypass the middleware path check using a malicious header value:
```
curl -i -H "x-forwarded-proto: x:admin?" http://localhost:4321/admin
```

How is this possible?

Here, with the payload x:admin?, the attacker can use the URL API parser to their advantage:

x: is considered the protocol
Since there is no //, the parser considers there to be no authority, and everything before the ? character is therefore considered part of the path: admin

During a path-based middleware check, the path value begins with a /: context.url.pathname === "/admin". However, this is not the case with this payload; context.url.pathname === "admin", the absence of a slash satisfies both the middleware check and the router and consequently allows us to bypass the protection and access the page.

SSRF

As seen, the request URL is built from untrusted input via the x-forwarded-protocol header, if it turns out that this URL is subsequently used to perform external network calls, for an API for example, this allows an attacker to supply a malicious URL that the server will fetch, resulting in server-side request forgery (SSRF).

Example of code reusing the "origin" URL, concatenating it to the API endpoint :

DoS via cache poisoning

If a CDN is present, it is possible to force the caching of bad pages/resources, or 404 pages on the application routes, rendering the application unusable.

A 404 cab be forced, causing an error on the /ssr page like this : curl -i -H "x-forwarded-proto: https://localhost/vulnerable?" http://localhost:4321/ssr

Same logic applies to x-forwarded-port : curl -i -H "x-forwarded-port: /vulnerable?" http://localhost:4321/ssr

How is this possible?

The router sees the request for the path /vulnerable, which does not exist, and therefore returns a 404, while the potential CDN sees /ssr and can then cache the 404 response, consequently serving it to all users requesting the path /ssr.

URL pollution

The exploitability of the following is also contingent on the presence of a CDN, and is therefore cache poisoning.

If the value of request.url is used to create links within the page, this can lead to Stored XSS with x-forwarded-proto and the following value:

x-forwarded-proto: javascript:alert(document.cookie)//

results in the following URL object:

It is also possible to inject any link, always, if the value of request.url is used on the server side to create links.

x-forwarded-proto: https://www.malicious-site.com/bad?

The attacker is more limited with x-forwarded-port

If the value of request.url is used to create links within the page, this can lead to broken links, with the header and the following value:

X-Forwarded-Port: /nope?

Example of an Astro website:

WAF bypass

For this section, Astro invites users to read previous research on the React-Router/Remix framework, in the section "Exploitation - WAF bypass and escalations". This research deals with a similar case, the difference being that the vulnerable header was x-forwarded-host in their case:

https://zhero-web-sec.github.io/research-and-things/react-router-and-the-remixed-path

Note: A section addressing DoS attacks via cache poisoning using the same vector was also included there.

CVE-2025-61925 complete bypass

It is possible to completely bypass the vulnerability patch related to the X-Forwarded-Host header.

By sending x-forwarded-host with an empty value, the forwardedHostname variable is assigned an empty string. Then, during the subsequent check, the condition fails because forwardedHostname returns false, its value being an empty string:

if (forwardedHostname && !App.validateForwardedHost(...))

Consequently, the implemented check is bypassed. From this point on, since the request has no host (its value being an empty string), the path value is retrieved by the URL parser to set it as the host. This is because the http/https schemes are considered special schemes by the WHATWG URL Standard Specification, requiring an authority state.

From there, the following request on the example SSR application (astro repo) yields an SSRF:

empty x-forwarded-host + the target host in the path

Credits

Allam Rachid (zhero;)
Allam Yasser (inzo)

Release Notes

withastro/astro (astro)

Uh oh!

chore(deps): update dependency astro to v5.15.6 [security] #9749

Are you sure you want to change the base?

chore(deps): update dependency astro to v5.15.6 [security] #9749

Conversation

renovate bot commented Oct 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GitHub Vulnerability Alerts

Summary

Background

Details

Impact

Mitigation

Summary

Details

Proof of Concept

Impact

Summary

Details

PoC

Impact

Summary

Details

Vulnerability Location

Root Cause

Attack Vector

PoC

Local Testing (localhost)

Remote Testing (ngrok)

Impact

Security impact

Attack scenarios

Remediation

Summary

Details

PoC

Middleware-based protected route bypass - x-forwarded-proto only

How ​​is this possible?

SSRF

DoS via cache poisoning

How ​​is this possible?

URL pollution

WAF bypass

CVE-2025-61925 complete bypass

Credits

Release Notes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Minor Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

⚠️ Breaking change for experimental live content collections only

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Minor Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Configuration

Uh oh!

changeset-bot bot commented Oct 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ No Changeset found

Uh oh!

coderabbitai bot commented Oct 11, 2025

Review skipped

Uh oh!

nx-cloud bot commented Oct 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

renovate bot commented Oct 11, 2025 •

edited

Loading

How is this possible?

How is this possible?

changeset-bot bot commented Oct 11, 2025 •

edited

Loading

nx-cloud bot commented Oct 11, 2025 •

edited

Loading