GHSA-j687-52p2-xcff Astro: XSS in define:vars via incomplete </script> tag sanitization

• npm astro: < 6.1.6 → fixed in 6.1.6

Summary The `defineScriptVars` function in Astro's server-side rendering pipeline uses a case-sensitive regex `//g` to sanitize values injected into inline `` tags via the `define:vars` directive. HTML parsers close `` elements case-insensitively and also accept whitespace or `/` before the closing `>`, allowing an attacker to bypass the sanitization with payloads like ``, ``, or `` and inject arbitrary HTML/JavaScript. Details The vulnerable function is `defineScriptVars` at `packages/astro/src/runtime/server/render/util.ts:42-53`: ```typescript export function defineScriptVars(vars: Record) { let output = ''; for (const [key, value] of Object.entries(vars)) { output += `const ${toIdent(key)} = ${JSON.stringify(value)?.replace( //g, // ← Case-sensitive, exact match only '\\x3C/script>', )};\n`; } return markHTMLString(output); } ``` This function is called from `renderElement` at `util.ts:172-174` when a `` element has `define:vars`: ```typescript if (name === 'script') { delete props.hoist; children = defineScriptVars(defineVars) + '\n' + children; } ``` The regex `//g` fails to match three classes of closing script tags that HTML parsers accept per the HTML specification §13.2.6.4: 1. Case variations: ``, ``, `` — HTML tag names are case-insensitive but the regex has no `i` flag. 2. Whitespace before `>`: ``, ``, `` — after the tag name, the HTML tokenizer enters the "before attribute name" state on ASCII whitespace. 3. Self-closing slash: `` — the tokenizer enters "self-closing start tag" state on `/`. `JSON.stringify()` does not escape ``, or `/` characters, so all these payloads pass through serialization unchanged. Execution flow: User-controlled input (e.g., `Astro.url.searchParams`) → assigned to a variable → passed via `define:vars` on a `` tag → `renderElement` → `defineScriptVars` → incomplete sanitization → injected into `` block in HTML response → browser closes the script element early → attacker-controlled HTML parsed and executed. PoC Step 1: Create an SSR Astro page (`src/pages/index.astro`): ```astro --- const name = Astro.url.searchParams.get('name') || 'World'; --- Hello console.log(name); ``` Step 2: Ensure SSR is enabled in `astro.config.mjs`: ```js export default defineConfig({ output: 'server' }); ``` Step 3: Start the dev server and visit: ``` http://localhost:4321/?name= ``` Step 4: View the HTML source. The output contains: ```html const name = ""; console.log(name); ``` The browser's HTML parser matches `` case-insensitively, closing the script block. The `` is then parsed as HTML and the JavaScript in `onerror` executes. Alternative bypass payloads: ``` /?name= /?name= /?name= ``` Impact An attacker can execute arbitrary JavaScript in the context of a victim's browser session on any SSR Astro application that passes request-derived data to `define:vars` on a `` tag. This is a documented and expected usage pattern in Astro. Exploitation enables: • Session hijacking via cookie theft (`document.cookie`) • Credential theft by injecting fake login forms or keyloggers • Defacement of the rendered page • Redirection to attacker-controlled domains The vulnerability affects all Astro versions that support `define:vars` and is exploitable in any SSR deployment where user input reaches a `define:vars` script variable. Recommended Fix Replace the case-sensitive exact-match regex with a comprehensive escape that covers all HTML parser edge cases. The simplest correct fix is to escape all `) { let output = ''; for (const [key, value] of Object.entries(vars)) { output += `const ${toIdent(key)} = ${JSON.stringify(value)?.replace( /` variants including case variations, whitespace, and self-closing forms.