GHSA-X9FJ-57FH-C8WQ
Vulnerability from github – Published: 2026-04-22 19:55 – Updated: 2026-05-13 13:29Summary
When dynamic text is interpolated into a <script> or <style> tag the Marko runtime failed to prevent tag breakout when the closing tag used non-lowercase casing.
An attacker able to place input inside a <script> or <style> block could break out of the tag with </SCRIPT>, </Style>, etc. and inject arbitrary HTML/JavaScript, resulting in cross-site scripting.
Details
The affected helpers used case-sensitive regular expressions to detect attempts at closing the surrounding tag:
// packages/runtime-tags/src/html/content.ts
const unsafeScriptReg = /<\/script/g;
const unsafeStyleReg = /<\/style/g;
// packages/runtime-class/src/runtime/html/helpers/escape-script-placeholder.js
const unsafeCharsReg = /<\/script/g;
// packages/runtime-class/src/runtime/html/helpers/escape-style-placeholder.js
const unsafeCharsReg = /<\/style/g;
HTML tag names are case-insensitive in the browser parser, so inputs such as </SCRIPT>, </Script>, or </sTyLe> were not matched by these regexes and passed through the helpers unchanged. A browser rendering the output treats the mixed-case end tag as a valid closing tag, terminating the script or style context, and then parses anything that follows as HTML.
The Marko compiler routes interpolated values inside <script> and <style> tags through these helpers automatically (see native-tag.ts:1080-1085), so application code following the framework's conventions had no way to detect or compensate for the gap.
PoC
$ const userCode = "</SCRIPT><script>alert(1)//";
<script>
const data = ${JSON.stringify(userCode)};
</script>
Would yield the following:
<script>const data = "</SCRIPT><script>alert(1)//";</script>
Which is then parsed in any WHATWG-compliant browser as:
<script>const data = "</script>
<script>alert(1)//";</script>
Impact
Cross-site scripting. Any Marko template that explicitly interpolates untrusted data inside a <script> or <style> block is affected.
Stored XSS is trivial if the value originates from any persisted user input (username, profile bio, comment body, etc.) that is later embedded in a script tag during rendering. Exploitation yields arbitrary JavaScript execution in the victim's browser, enabling session token theft, account takeover, and arbitrary actions as the victim.
Since the internal _escape_script and _escape_style helpers are the framework's designated defense against script/style tag breakout, applications following standard Marko patterns had no obvious reason to add a second layer of sanitization.
This does not affect scripts or hydration state serialized by Marko itself — only templates that explicitly interpolate untrusted values inside a or tag.
Patch
Commit 19d4b37d0 — fix: html script, style, and comment escaping.
- const unsafeScriptReg = /<\/script/g;
+ const unsafeScriptReg = /<\/script/gi;
- const unsafeStyleReg = /<\/style/g;
+ const unsafeStyleReg = /<\/style/gi;
The same commit also introduced an _escape_comment helper and corresponding escape-comment-placeholder.js, hardening HTML comment escaping as a related preventative fix. Test fixtures were added under escape-script-case, escape-style-case, and escape-comment.
Workarounds
Upgrade to the patched release. As a short-term mitigation on affected versions, pre-sanitize any untrusted data before it reaches a template position rendered inside a <script> or <style> tag — e.g. normalize `
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "marko"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.38.36"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@marko/runtime-tags"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.164"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41591"
],
"database_specific": {
"cwe_ids": [
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-22T19:55:51Z",
"nvd_published_at": "2026-05-08T16:16:11Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nWhen dynamic text is interpolated into a `\u003cscript\u003e` or `\u003cstyle\u003e` tag the Marko runtime failed to prevent tag breakout when the closing tag used non-lowercase casing.\nAn attacker able to place input inside a `\u003cscript\u003e` or `\u003cstyle\u003e` block could break out of the tag with `\u003c/SCRIPT\u003e`, `\u003c/Style\u003e`, etc. and inject arbitrary HTML/JavaScript, resulting in cross-site scripting.\n\n### Details\n\nThe affected helpers used case-sensitive regular expressions to detect attempts at closing the surrounding tag:\n\n```js\n// packages/runtime-tags/src/html/content.ts\nconst unsafeScriptReg = /\u003c\\/script/g;\nconst unsafeStyleReg = /\u003c\\/style/g;\n\n// packages/runtime-class/src/runtime/html/helpers/escape-script-placeholder.js\nconst unsafeCharsReg = /\u003c\\/script/g;\n\n// packages/runtime-class/src/runtime/html/helpers/escape-style-placeholder.js\nconst unsafeCharsReg = /\u003c\\/style/g;\n```\n\nHTML tag names are case-insensitive in the browser parser, so inputs such as `\u003c/SCRIPT\u003e`, `\u003c/Script\u003e`, or `\u003c/sTyLe\u003e` were not matched by these regexes and passed through the helpers unchanged. A browser rendering the output treats the mixed-case end tag as a valid closing tag, terminating the script or style context, and then parses anything that follows as HTML.\n\nThe Marko compiler routes interpolated values inside `\u003cscript\u003e` and `\u003cstyle\u003e` tags through these helpers automatically (see `native-tag.ts:1080-1085`), so application code following the framework\u0027s conventions had no way to detect or compensate for the gap.\n\n### PoC\n\n```marko\n$ const userCode = \"\u003c/SCRIPT\u003e\u003cscript\u003ealert(1)//\";\n\u003cscript\u003e\n const data = ${JSON.stringify(userCode)};\n\u003c/script\u003e\n```\n\nWould yield the following:\n\n```html\n\u003cscript\u003econst data = \"\u003c/SCRIPT\u003e\u003cscript\u003ealert(1)//\";\u003c/script\u003e\n```\n\nWhich is then parsed in any WHATWG-compliant browser as:\n```html\n\u003cscript\u003econst data = \"\u003c/script\u003e\n\u003cscript\u003ealert(1)//\";\u003c/script\u003e\n```\n\n### Impact\n\nCross-site scripting. Any Marko template that explicitly interpolates untrusted data inside a `\u003cscript\u003e` or `\u003cstyle\u003e` block is affected.\n\nStored XSS is trivial if the value originates from any persisted user input (username, profile bio, comment body, etc.) that is later embedded in a script tag during rendering. Exploitation yields arbitrary JavaScript execution in the victim\u0027s browser, enabling session token theft, account takeover, and arbitrary actions as the victim.\n\nSince the internal `_escape_script` and `_escape_style` helpers are the framework\u0027s designated defense against script/style tag breakout, applications following standard Marko patterns had no obvious reason to add a second layer of sanitization.\n\nThis does not affect scripts or hydration state serialized by Marko itself \u2014 only templates that explicitly interpolate untrusted values inside a \u003cscript\u003e or \u003cstyle\u003e tag.\n\n### Patch\n\nCommit `19d4b37d0` \u2014 `fix: html script, style, and comment escaping`.\n\n```diff\n- const unsafeScriptReg = /\u003c\\/script/g;\n+ const unsafeScriptReg = /\u003c\\/script/gi;\n\n- const unsafeStyleReg = /\u003c\\/style/g;\n+ const unsafeStyleReg = /\u003c\\/style/gi;\n```\n\nThe same commit also introduced an `_escape_comment` helper and corresponding `escape-comment-placeholder.js`, hardening HTML comment escaping as a related preventative fix. Test fixtures were added under `escape-script-case`, `escape-style-case`, and `escape-comment`.\n\n### Workarounds\n\nUpgrade to the patched release. As a short-term mitigation on affected versions, pre-sanitize any untrusted data before it reaches a template position rendered inside a `\u003cscript\u003e` or `\u003cstyle\u003e` tag \u2014 e.g. normalize `\u003c/script`, `\u003c/style`, and their mixed-case variants before interpolation, or avoid direct interpolation of untrusted values inside these tags entirely.",
"id": "GHSA-x9fj-57fh-c8wq",
"modified": "2026-05-13T13:29:43Z",
"published": "2026-04-22T19:55:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/marko-js/marko/security/advisories/GHSA-x9fj-57fh-c8wq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41591"
},
{
"type": "PACKAGE",
"url": "https://github.com/marko-js/marko"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Marko: XSS via case-insensitive script/style closing tag bypass in runtime HTML escaping"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.