GHSA-j687-52p2-xcff Astro: XSS in define:vars via incomplete </script> tag sanitization
SummaryThe `defineScriptVars` function in Astro's server-side rendering pipeline uses a case-sensitive regex `/<\/script>/g` to sanitize values injected into inline `<script>` tags via the `define:vars` directive. HTML parsers close `<script>` elements case-insensitively and also accept whitespace or `/` before the closing `>`, allowing an attacker to bypass the sanitization with payloads like `</Script>`, `</script >`, or `</script/>` and inject arbitrary HTML/JavaScript.DetailsThe vulnerable function is `defineScriptVars` at `packages/astro/src/runtime/server/render/util.ts:42-53`:This function is called from `renderElement` at `util.ts:172-174` when a `<script>` element has `define:vars`:The regex `/<\/script>/g` fails to match three classes of closing script tags that HTML parsers accept per the [HTML specification §13.2.6.4](https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inbody):**Case variations**: `</Script>`, `</SCRIPT>`, `</sCrIpT>` — HTML tag names are case-insensitive but the regex has no `i` flag.**Whitespace before `>`**: `</script >`, `</script\t>`, `</script\n>` — after the tag name, the HTML tokenizer enters the "before attribute name" state on ASCII whitespace.**Self-closing slash**: `</script/>` — 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 `<script>` tag → `renderElement` → `defineScriptVars` → incomplete sanitization → injected into `<script>` 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`):**Step 2:** Ensure SSR is enabled in `astro.config.mjs`:**Step 3:** Start the dev server and visit:**Step 4:** View the HTML source. The output contains:The browser's HTML parser matches `</Script>` case-insensitively, closing the script block. The `<img onerror=alert(document.cookie)>` is then parsed as HTML and the JavaScript in `onerror` executes.**Alternative bypass payloads:**ImpactAn 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 `<script>` 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 domainsThe 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 FixReplace 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 `<` characters in the JSON output:This is the standard approach used by frameworks like Next.js and Rails. Replacing every `<` with `\u003c` is safe inside JSON string contexts (JavaScript treats `\u003c` as `<` at runtime) and eliminates all possible `</script>` variants including case variations, whitespace, and self-closing forms.
CVSS v3.1 score: 6.1