CVE-2026-41067: Astro Cross-Site Scripting Vulnerability

MODERATE

Advisory Identifier: GHSA-j687-52p2-xcff

CVSS 6.1

Published 2026-04-21

Advisory Summary

CVE-2026-41067 is a MODERATE (CVSS 6.1) cross-site scripting vulnerability (CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')) affecting Astro libraries in the npm ecosystem. The issue involves xss in define:vars via incomplete </script> tag sanitization. Remediation is available by upgrading affected packages to version 6.1.6.

CVE-2026-41067 at a Glance

CVE Identifier CVE-2026-41067

GHSA Identifier GHSA-j687-52p2-xcff

Severity MODERATE

CVSS v3.1 Base Score 6.1

CWE Classification CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Affected Product Astro

Package Ecosystem npm

Published Date 2026-04-21

Last Updated 2026-04-27

Security Impact

CVSS: 6.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).

Attack Vector Network (AV:N)

Attack Complexity Low (AC:L)

Privileges Required None (PR:N)

User Interaction Required (UI:R)

Scope Changed (S:C)

Confidentiality Low (C:L)

Integrity Low (I:L)

Availability None (A:N)

How to Fix CVE-2026-41067

To remediate this vulnerability, upgrade all affected Astro dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

astro fixed: 6.1.6

npm install astro@6.1.6

Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls astro

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-41067, inspect your project dependencies using npm:

npm ls astro

Analyze the terminal output to locate any version of Astro in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 6.1.6), your application is affected.

Note: The npm ls astro command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), where the product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users. In Astro, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary The `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. ## Details The vulnerable function is `defineScriptVars` at `packages/astro/src/runtime/server/render/util.ts:42-53`: ```typescript export function defineScriptVars(vars: Record<any, any>) { let output = ''; for (const [key, value] of Object.entries(vars)) { output += `const ${toIdent(key)} = ${JSON.stringify(value)?.replace( /<\/script>/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 `<script>` element has `define:vars`: ```typescript if (name === 'script') { delete props.hoist; children = defineScriptVars(defineVars) + '\n' + children; } ``` 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): 1. **Case variations**: `</Script>`, `</SCRIPT>`, `</sCrIpT>` — HTML tag names are case-insensitive but the regex has no `i` flag. 2. **Whitespace before `>`**: `</script >`, `</script\t>`, `</script\n>` — after the tag name, the HTML tokenizer enters the "before attribute name" state on ASCII whitespace. 3. **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`): ```astro --- const name = Astro.url.searchParams.get('name') || 'World'; --- <html> <body> <h1>Hello</h1> <script define:vars={{ name }}> console.log(name); </script> </body> </html> ``` **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=</Script><img/src=x%20onerror=alert(document.cookie)> ``` **Step 4:** View the HTML source. The output contains: ```html <script>const name = "</Script><img/src=x onerror=alert(document.cookie)>"; console.log(name); </script> ``` 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:** ``` /?name=</script ><img/src=x onerror=alert(1)> /?name=</script/><img/src=x onerror=alert(1)> /?name=</SCRIPT><img/src=x onerror=alert(1)> ``` ## 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 `<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 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 `<` characters in the JSON output: ```typescript export function defineScriptVars(vars: Record<any, any>) { let output = ''; for (const [key, value] of Object.entries(vars)) { output += `const ${toIdent(key)} = ${JSON.stringify(value)?.replace( /</g, '\\u003c', )};\n`; } return markHTMLString(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.

CVE-2026-41067 Affected Astro Versions

1 component(s)

Fixed Versions:

6.1.6

Product / Package	Ecosystem	Affected Versions	Fixed Version
astro npm/astro	npm	< 6.1.6	6.1.6

References

GitHub Advisory / Wiki ADVISORY

https://github.com/withastro/astro/security/advisories/GHSA-j687-52p2-xcff

NVD — CVE-2026-41067 NVD

https://nvd.nist.gov/vuln/detail/CVE-2026-41067

Astro Source Repository REPOSITORY

https://github.com/withastro/astro

Astro Release RELEASE

https://github.com/withastro/astro/releases/tag/astro@6.1.6

Frequently Asked Questions

What is CVE-2026-41067?

CVE-2026-41067 is a security vulnerability in Astro involving XSS in define:vars via incomplete </script> tag sanitization under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').

Which Astro versions are affected?

Affected versions include releases prior to 6.1.6 across affected packages: astro.

What version fixes CVE-2026-41067?

Upgrading to 6.1.6 (or the latest patched release for your respective branch) resolves the vulnerability.

Is astro affected?

Yes, astro is affected in releases prior to 6.1.6. Upgrade your dependency to 6.1.6 or later.

What is the CVSS score of CVE-2026-41067?

CVE-2026-41067 has a CVSS v3.1 base score of 6.1 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N.

What CWE is associated with CVE-2026-41067?

CVE-2026-41067 is classified under CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.).

How can I check npm dependencies for CVE-2026-41067?

Run the dependency tree command: 'npm ls astro'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.

Machine-readable OSV JSON OSV v1.5 Schema

Normalized schema output

View Raw JSON

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-j687-52p2-xcff",
  "modified" : "2026-04-27T16:43:27Z",
  "published" : "2026-04-21T20:39:49Z",
  "aliases" : [ "CVE-2026-41067" ],
  "summary" : "Astro: XSS in define:vars via incomplete </script> tag sanitization",
  "details" : "## Summary\n\nThe `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.\n\n## Details\n\nThe vulnerable function is `defineScriptVars` at `packages/astro/src/runtime/server/render/util.ts:42-53`:\n\n```typescript\nexport function defineScriptVars(vars: Record<any, any>) {\n\tlet output = '';\n\tfor (const [key, value] of Object.entries(vars)) {\n\t\toutput += `const ${toIdent(key)} = ${JSON.stringify(value)?.replace(\n\t\t\t/<\\/script>/g,       // ← Case-sensitive, exact match only\n\t\t\t'\\\\x3C/script>',\n\t\t)};\\n`;\n\t}\n\treturn markHTMLString(output);\n}\n```\n\nThis function is called from `renderElement` at `util.ts:172-174` when a `<script>` element has `define:vars`:\n\n```typescript\nif (name === 'script') {\n\tdelete props.hoist;\n\tchildren = defineScriptVars(defineVars) + '\\n' + children;\n}\n```\n\nThe 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):\n\n1. **Case variations**: `</Script>`, `</SCRIPT>`, `</sCrIpT>` — HTML tag names are case-insensitive but the regex has no `i` flag.\n2. **Whitespace before `>`**: `</script >`, `</script\\t>`, `</script\\n>` — after the tag name, the HTML tokenizer enters the \"before attribute name\" state on ASCII whitespace.\n3. **Self-closing slash**: `</script/>` — the tokenizer enters \"self-closing start tag\" state on `/`.\n\n`JSON.stringify()` does not escape `<`, `>`, or `/` characters, so all these payloads pass through serialization unchanged.\n\n**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.\n\n## PoC\n\n**Step 1:** Create an SSR Astro page (`src/pages/index.astro`):\n\n```astro\n---\nconst name = Astro.url.searchParams.get('name') || 'World';\n---\n<html>\n<body>\n  <h1>Hello</h1>\n  <script define:vars={{ name }}>\n    console.log(name);\n  </script>\n</body>\n</html>\n```\n\n**Step 2:** Ensure SSR is enabled in `astro.config.mjs`:\n\n```js\nexport default defineConfig({\n  output: 'server'\n});\n```\n\n**Step 3:** Start the dev server and visit:\n\n```\nhttp://localhost:4321/?name=</Script><img/src=x%20onerror=alert(document.cookie)>\n```\n\n**Step 4:** View the HTML source. The output contains:\n\n```html\n<script>const name = \"</Script><img/src=x onerror=alert(document.cookie)>\";\n  console.log(name);\n</script>\n```\n\nThe 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.\n\n**Alternative bypass payloads:**\n\n```\n/?name=</script ><img/src=x onerror=alert(1)>\n/?name=</script/><img/src=x onerror=alert(1)>\n/?name=</SCRIPT><img/src=x onerror=alert(1)>\n```\n\n## Impact\n\nAn 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.\n\nExploitation enables:\n- **Session hijacking** via cookie theft (`document.cookie`)\n- **Credential theft** by injecting fake login forms or keyloggers\n- **Defacement** of the rendered page\n- **Redirection** to attacker-controlled domains\n\nThe 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.\n\n## Recommended Fix\n\nReplace 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:\n\n```typescript\nexport function defineScriptVars(vars: Record<any, any>) {\n\tlet output = '';\n\tfor (const [key, value] of Object.entries(vars)) {\n\t\toutput += `const ${toIdent(key)} = ${JSON.stringify(value)?.replace(\n\t\t\t/</g,\n\t\t\t'\\\\u003c',\n\t\t)};\\n`;\n\t}\n\treturn markHTMLString(output);\n}\n```\n\nThis 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "astro"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "6.1.6"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/withastro/astro/security/advisories/GHSA-j687-52p2-xcff"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-41067"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/withastro/astro"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/withastro/astro/releases/tag/astro@6.1.6"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-79" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-21T20:39:49Z",
    "nvd_published_at" : "2026-04-24T17:16:21Z"
  }
}

CVSS V3

6.1 MODERATE