fix(deps): update dependency astro to v5.15.9 [security] #3595

renovate · 2025-08-07T18:07:23Z

This PR contains the following updates:

Package	Change	Age	Confidence
astro (source)	`5.11.0` -> `5.15.9`

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.

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)

CVE-2025-64757

Summary

A vulnerability has been identified in the Astro framework's development server that allows arbitrary local file read access through the image optimization endpoint. The vulnerability affects Astro development environments and allows remote attackers to read any image file accessible to the Node.js process on the host system.

Details

Title: Arbitrary Local File Read in Astro Development Image Endpoint
Type: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Component: /packages/astro/src/assets/endpoint/node.ts
Affected Versions: Astro v5.x development builds (confirmed v5.13.3)
Attack Vector: Network (HTTP GET request)
Authentication Required: None

The vulnerability exists in the Node.js image endpoint handler used during development mode. The endpoint accepts an href parameter that specifies the path to an image file. In development mode, this parameter is processed without adequate path validation, allowing attackers to specify absolute file paths.

Vulnerable Code Location: packages/astro/src/assets/endpoint/node.ts

// Vulnerable code in development mode
if (import.meta.env.DEV) {
    fileUrl = pathToFileURL(removeQueryString(replaceFileSystemReferences(src)));
} else {
    // Production has proper path validation
    // ... security checks omitted in dev mode
}

The development branch bypasses the security checks that exist in the production code path, which validates that file paths are within the allowed assets directory.

PoC

Attack Prerequisites

Astro development server must be running (astro dev)
The /_image endpoint must be accessible to the attacker
Target image files must be readable by the Node.js process

Exploit Steps

Start Astro Development Server:

astro dev  # Typically runs on http://localhost:4321

Craft Malicious Request:

GET /_image?href=/[ABSOLUTE_PATH_TO_IMAGE]&w=100&h=100&f=png HTTP/1.1
Host: localhost:4321

Example Attack:

curl "http://localhost:4321/_image?href=/%2FSystem%2FLibrary%2FImage%20Capture%2FAutomatic%20Tasks%2FMakePDF.app%2FContents%2FResources%2F0blank.jpg&w=100&h=100&f=png" -o stolen.png

Demonstration Results

Test Environment: macOS with Astro v5.13.3

Successful Exploitation:

Target: /System/Library/Image Capture/Automatic Tasks/MakePDF.app/Contents/Resources/0blank.jpg
Response: HTTP 200 OK, Content-Type: image/png
Exfiltration: 303 bytes (100x100 PNG)
File Created: stolen-image.png containing processed system image

Attack Payload:

http://localhost:4321/_image?href=/%2FSystem%2FLibrary%2FImage%20Capture%2FAutomatic%20Tasks%2FMakePDF.app%2FContents%2FResources%2F0blank.jpg&w=100&h=100&f=png

Server Response:

Status: 200 OK
Content-Type: image/png
Content-Length: 303

Impact

Confidentiality Impact: HIGH

Scope: Any image file readable by the Node.js process
Exfiltration Method: Complete file contents via HTTP response (transformed to PNG)

Integrity Impact: NONE

The vulnerability only allows reading files, not modification

Availability Impact: NONE

No direct impact on system availability
Potential for resource exhaustion through repeated large image requests

Affected Components

Primary Component

File: packages/astro/src/assets/endpoint/node.ts
Function: loadLocalImage()
Lines: Development mode branch (~25-35)

Secondary Components

File: packages/astro/src/assets/endpoint/generic.ts
Impact: Uses different code path, not directly vulnerable
Note: Implements proper remote allowlist validation

CVE-2025-64764

Summary

After some research it appears that it is possible to obtain a reflected XSS when the server islands feature is used in the targeted application, regardless of what was intended by the component template(s).

Details

Server islands run in their own isolated context outside of the page request and use the following pattern path to hydrate the page: /_server-islands/[name]. These paths can be called via GET or POST and use three parameters:

e: component to export
p: the transmitted properties, encrypted
s: for the slots

Slots are placeholders for external HTML content, and therefore allow, by default, the injection of code if the component template supports it, nothing exceptional in principle, just a feature.

This is where it becomes problematic: it is possible, independently of the component template used, even if it is completely empty, to inject a slot containing an XSS payload, whose parent is a tag whose name is is the absolute path of the island file. Enabling reflected XSS on any application, regardless of the component templates used, provided that the server islands is used at least once.

How ?

By default, when a call is made to the endpoint /_server-islands/[name], the value of the parameter e is default, pointing to a function exported by the component's module.

Upon further investigation, we find that two other values are possible for the component export (param e) in a typical configuration: url and file. file returns a string value corresponding to the absolute path of the island file. Since the value is of type string, it fulfills the following condition and leads to this code block:

An entire template is created, completely independently, and then returned:

the absolute path name is sanitized and then injected as the tag name
childSlots, the value provided to the s parameter, is injected as a child

All of this is done using markHTMLString. This allows the injection of any XSS payload, even if the component template intended by the application is initially empty or does not provide for the use of slots.

Proof of concept

For our Proof of Concept (PoC), we will use a minimal repository:

Latest Astro version at the time (5.15.6)
Use of Island servers, with a completely empty component, to demonstrate what we explained previously

Download the PoC repository

Access the following URL and note the opening of the popup, demonstrating the reflected XSS:

http://localhost:4321/_server-islands/ServerTime?e=file&p=&s={%22zhero%22:%22%3Cimg%20src=x%20onerror=alert(0)%3E%22}

The value of the parameter s must be in JSON format and the payload must be injected at the value level, not the key level :

Despite the initial template being empty, it is created because the value of the URL parameter e is set to file, as explained earlier. The parent tag is the name of the component's internal route, and its child is the value of the key "zhero" (the name doesn't matter) of the URL parameter s.

Credits

Allam Rachid (zhero;)
Allam Yasser (inzo)

CVE-2025-64765

A mismatch exists between how Astro normalizes request paths for routing/rendering and how the application’s middleware reads the path for validation checks. Astro internally applies decodeURI() to determine which route to render, while the middleware uses context.url.pathname without applying the same normalization (decodeURI).

This discrepancy may allow attackers to reach protected routes (e.g., /admin) using encoded path variants that pass routing but bypass validation checks.

https://github.com/withastro/astro/blob/ebc4b1cde82c76076d5d673b5b70f94be2c066f3/packages/astro/src/vite-plugin-astro-server/request.ts#L40-L44

/** The main logic to route dev server requests to pages in Astro. */
export async function handleRequest({
    pipeline,
    routesList,
    controller,
    incomingRequest,
    incomingResponse,
}: HandleRequest) {
    const { config, loader } = pipeline;
    const origin = `${loader.isHttps() ? 'https' : 'http'}://${
        incomingRequest.headers[':authority'] ?? incomingRequest.headers.host
    }`;

    const url = new URL(origin + incomingRequest.url);
    let pathname: string;
    if (config.trailingSlash === 'never' && !incomingRequest.url) {
        pathname = '';
    } else {
        // We already have a middleware that checks if there's an incoming URL that has invalid URI, so it's safe
        // to not handle the error: packages/astro/src/vite-plugin-astro-server/base.ts
        pathname = decodeURI(url.pathname); // here this url is for routing/rendering
    }

    // Add config.base back to url before passing it to SSR
    url.pathname = removeTrailingForwardSlash(config.base) + url.pathname; // this is used for middleware context

Consider an application having the following middleware code:

import { defineMiddleware } from "astro/middleware";

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

context.url.pathname is validated , if it's equal to /admin the isAuthed property must be true for the next() method to be called. The same example can be found in the official docs https://docs.astro.build/en/guides/authentication/

context.url.pathname returns the raw version which is /%61admin while pathname which is used for routing/rendering /admin, this creates a path normalization mismatch.

By sending the following request, it's possible to bypass the middleware check

GET /%61dmin HTTP/1.1
Host: localhost:3000

Remediation

Ensure middleware context has the same normalized pathname value that Astro uses internally, because any difference could allow it to bypass such checks. In short maybe something like this

        pathname = decodeURI(url.pathname);
    }

    // Add config.base back to url before passing it to SSR
-    url.pathname = removeTrailingForwardSlash(config.base) + url.pathname;
+    url.pathname = removeTrailingForwardSlash(config.base) + decodeURI(url.pathname);

Thankyou, let me know if any more info is needed happy to help :)

CVE-2025-65019

Summary
A Cross-Site Scripting (XSS) vulnerability exists in Astro when using the @astrojs/cloudflare adapter with output: 'server'. The built-in image optimization endpoint (/_image) uses isRemoteAllowed() from Astro’s internal helpers, which unconditionally allows data: URLs. When the endpoint receives a valid data: URL pointing to a malicious SVG containing JavaScript, and the Cloudflare-specific implementation performs a 302 redirect back to the original data: URL, the browser directly executes the embedded JavaScript. This completely bypasses any domain allow-listing (image.domains / image.remotePatterns) and typical Content Security Policy mitigations.

Affected Versions

@astrojs/cloudflare ≤ 12.6.10 (and likely all previous versions)
Astro ≥ 4.x when used with output: 'server' and the Cloudflare adapter

Root Cause – Vulnerable Code
File: node_modules/@astrojs/internal-helpers/src/remote.ts

export function isRemoteAllowed(src: string, ...): boolean {
  if (!URL.canParse(src)) {
    return false;
  }
  const url = new URL(src);

  // Data URLs are always allowed 
  if (url.protocol === 'data:') {
    return true;
  }

  // Non-http(s) protocols are never allowed
  if (!['http:', 'https:'].includes(url.protocol)) {
    return false;
  }
  // ... further http/https allow-list checks
}

In the Cloudflare adapter, the /_image endpoint contains logic similar to:

	const href = ctx.url.searchParams.get('href');
	if (!href) {
		// return error 
	}

	if (isRemotePath(href)) {
		if (isRemoteAllowed(href, imageConfig) === false) {
			// return error
		} else {
            //redirect to return the image 
			return Response.redirect(href, 302);
		}
	}

Because data: URLs are considered “allowed”, a request such as:
https://example.com/_image?href=data:image/svg+xml;base64,PHN2Zy... (base64-encoded malicious SVG)

triggers a 302 redirect directly to the data: URL, causing the browser to render and execute the malicious JavaScript inside the SVG.

Proof of Concept (PoC)

Create a minimal Astro project with Cloudflare adapter (output: 'server').
Deploy to Cloudflare Pages or Workers.
Request the image endpoint with the following payload:

https://yoursite.com/_image?href=data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjxzY3JpcHQ+YWxlcnQoJ3pvbWFzZWMnKTwvc2NyaXB0Pjwvc3ZnPg==

(Base64 decodes to: <svg xmlns="http://www.w3.org/2000/svg"><script>alert('zomasec')</script></svg>)

The endpoint returns a 302 redirect to the data: URL → browser executes the <script> → alert() fires.

Impact

Reflected/Strored XSS (depending on application usage)
Session hijacking (access to cookies, localStorage, etc.)
Account takeover when combined with CSRF
Data exfiltration to attacker-controlled servers
Bypasses image.domains / image.remotePatterns configuration entirely

Safe vs Vulnerable Behavior
Other Astro adapters (Node, Vercel, etc.) typically proxy and rasterize SVGs, stripping JavaScript. The Cloudflare adapter currently redirects to remote resources (including data: URLs), making it uniquely vulnerable.

References

Vulnerable function: https://github.com/withastro/astro/blob/main/packages/internal-helpers/src/remote.ts
Similar data: URL bypass in WordPress: CVE-2025-2575

Minor Changes

#14543 9b3241d Thanks @matthewp! - Adds two new adapter configuration options assetQueryParams and internalFetchHeaders to the Adapter API.

Official and community-built adapters can now use client.assetQueryParams to specify query parameters that should be appended to asset URLs (CSS, JavaScript, images, fonts, etc.). The query parameters are automatically appended to all generated asset URLs during the build process.

Adapters can also use client.internalFetchHeaders to specify headers that should be included in Astro's internal fetch calls (Actions, View Transitions, Server Islands, Prefetch).

This enables features like Netlify's skew protection, which requires the deploy ID to be sent with both internal requests and asset URLs to ensure client and server versions match during deployments.
#14489 add4277 Thanks @dev-shetty! - Adds a new Copy to Clipboard button to the error overlay stack trace.

When an error occurs in dev mode, you can now copy the stack trace with a single click to more easily share it in a bug report, a support thread, or with your favorite LLM.
#14564 5e7cebb Thanks @florian-lefebvre! - Updates astro add cloudflare to scaffold more configuration files

Running astro add cloudflare will now emit wrangler.jsonc and public/.assetsignore, allowing your Astro project to work out of the box as a worker.

Patch Changes

#14591 3e887ec Thanks @matthewp! - Adds TypeScript support for the components prop on MDX Content component when using await render(). Developers now get proper IntelliSense and type checking when passing custom components to override default MDX element rendering.
#14598 7b45c65 Thanks @delucis! - Reduces terminal text styling dependency size by switching from kleur to picocolors
#13826 8079482 Thanks @florian-lefebvre! - Adds the option to specify i

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

netlify · 2025-08-07T18:07:32Z

✅ Deploy Preview for brilliant-pasca-3e80ec ready!

Name	Link
🔨 Latest commit	`d26a8b6`
🔍 Latest deploy log	https://app.netlify.com/projects/brilliant-pasca-3e80ec/deploys/691e452ee9b53f00070a679a
😎 Deploy Preview	https://deploy-preview-3595--brilliant-pasca-3e80ec.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

github-actions · 2025-08-07T18:12:03Z

🚀 Performance Test Results

Test Configuration:

VUs: 4
Duration: 1m0s

Test Metrics:

Requests/s: 44.41
Iterations/s: 14.81
Failed Requests: 0.00% (0 of 2669)

📜 Logs


> [email protected] run-tests:testenv /home/runner/work/rafiki/rafiki/test/performance
> ./scripts/run-tests.sh -e test "-k" "-q" "--vus" "4" "--duration" "1m"

Cloud Nine GraphQL API is up: http://localhost:3101/graphql
Cloud Nine Wallet Address is up: http://localhost:3100/
Happy Life Bank Address is up: http://localhost:4100/
cloud-nine-wallet-test-backend already set
cloud-nine-wallet-test-auth already set
happy-life-bank-test-backend already set
happy-life-bank-test-auth already set
     data_received..................: 963 kB 16 kB/s
     data_sent......................: 2.0 MB 34 kB/s
     http_req_blocked...............: avg=8.06µs   min=2.19µs   med=5.23µs   max=1.69ms   p(90)=6.43µs   p(95)=6.85µs  
     http_req_connecting............: avg=1.34µs   min=0s       med=0s       max=1.64ms   p(90)=0s       p(95)=0s      
     http_req_duration..............: avg=89.51ms  min=10.52ms  med=71.65ms  max=599.79ms p(90)=156.43ms p(95)=183.71ms
       { expected_response:true }...: avg=89.51ms  min=10.52ms  med=71.65ms  max=599.79ms p(90)=156.43ms p(95)=183.71ms
     http_req_failed................: 0.00%  ✓ 0         ✗ 2669
     http_req_receiving.............: avg=83.81µs  min=28.31µs  med=74µs     max=1.19ms   p(90)=110.82µs p(95)=136.24µs
     http_req_sending...............: avg=39.34µs  min=9.81µs   med=26.9µs   max=2.43ms   p(90)=39.07µs  p(95)=53.64µs 
     http_req_tls_handshaking.......: avg=0s       min=0s       med=0s       max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=89.38ms  min=10.26ms  med=71.56ms  max=599.7ms  p(90)=156.29ms p(95)=183.61ms
     http_reqs......................: 2669   44.407097/s
     iteration_duration.............: avg=270.01ms min=174.62ms med=252.69ms max=1.11s    p(90)=334.55ms p(95)=362.08ms
     iterations.....................: 890    14.807912/s
     vus............................: 4      min=4       max=4 
     vus_max........................: 4      min=4       max=4

renovate bot added the dependencies Pull requests that update a dependency label Aug 7, 2025

github-actions bot added the pkg: documentation Changes in the documentation package. label Aug 7, 2025

renovate bot force-pushed the renovate-npm-astro-vulnerability branch 2 times, most recently from 2600748 to 7a64610 Compare August 13, 2025 16:50

renovate bot force-pushed the renovate-npm-astro-vulnerability branch from 7a64610 to f59c82c Compare August 19, 2025 16:16

renovate bot changed the title ~~fix(deps): update dependency astro to v5.12.8 [security]~~ fix(deps): update dependency astro to v5.13.2 [security] Aug 19, 2025

renovate bot force-pushed the renovate-npm-astro-vulnerability branch from f59c82c to 89d359b Compare August 31, 2025 14:35

renovate bot force-pushed the renovate-npm-astro-vulnerability branch from 89d359b to ed21e5e Compare September 25, 2025 14:52

renovate bot force-pushed the renovate-npm-astro-vulnerability branch from ed21e5e to 490f428 Compare October 11, 2025 00:52

renovate bot changed the title ~~fix(deps): update dependency astro to v5.13.2 [security]~~ fix(deps): update dependency astro to v5.14.3 [security] Oct 11, 2025

renovate bot force-pushed the renovate-npm-astro-vulnerability branch from 490f428 to 610a9be Compare October 21, 2025 10:54

renovate bot force-pushed the renovate-npm-astro-vulnerability branch from 610a9be to fa05c30 Compare October 31, 2025 16:12

renovate bot force-pushed the renovate-npm-astro-vulnerability branch 2 times, most recently from 7e6e69b to 402cc47 Compare November 13, 2025 23:42

renovate bot changed the title ~~fix(deps): update dependency astro to v5.14.3 [security]~~ fix(deps): update dependency astro to v5.15.6 [security] Nov 13, 2025

renovate bot force-pushed the renovate-npm-astro-vulnerability branch from 402cc47 to 81ce27f Compare November 18, 2025 14:06

fix(deps): update dependency astro to v5.15.9 [security]

d26a8b6

renovate bot force-pushed the renovate-npm-astro-vulnerability branch from 81ce27f to d26a8b6 Compare November 19, 2025 22:31

renovate bot changed the title ~~fix(deps): update dependency astro to v5.15.6 [security]~~ fix(deps): update dependency astro to v5.15.9 [security] Nov 19, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(deps): update dependency astro to v5.15.9 [security] #3595

fix(deps): update dependency astro to v5.15.9 [security] #3595

Uh oh!

renovate bot commented Aug 7, 2025 •

edited

Loading

Uh oh!

netlify bot commented Aug 7, 2025 •

edited

Loading

Uh oh!

github-actions bot commented Aug 7, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

fix(deps): update dependency astro to v5.15.9 [security] #3595

Are you sure you want to change the base?

fix(deps): update dependency astro to v5.15.9 [security] #3595

Uh oh!

Conversation

renovate bot commented Aug 7, 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

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

Summary

Details

PoC

Attack Prerequisites

Exploit Steps

Demonstration Results

Impact

Confidentiality Impact: HIGH

Integrity Impact: NONE

Availability Impact: NONE

Affected Components

Primary Component

Secondary Components

Summary

Details

Proof of concept

Credits

Release Notes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Patch Changes

Minor Changes

Patch Changes

Configuration

Uh oh!

netlify bot commented Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for brilliant-pasca-3e80ec ready!

Uh oh!

github-actions bot commented Aug 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

renovate bot commented Aug 7, 2025 •

edited

Loading

How is this possible?

How is this possible?

netlify bot commented Aug 7, 2025 •

edited

Loading

github-actions bot commented Aug 7, 2025 •

edited

Loading