CVE-2026-41591 — marko
MEDIUMCVE-2026-41591 is a medium-severity (CVSS 6.4) Cross-site Scripting (XSS) vulnerability in marko. A fix is available for marko — see the affected versions and patch details below.
Marko: XSS via case-insensitive script/style closing tag bypass in runtime HTML escaping
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-41591.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
markonpm@marko/runtime-tagsnpmDescription
Summary
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 <script> or <style> 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 </script, </style, and their mixed-case variants before interpolation, or avoid direct interpolation of untrusted values inside these tags entirely.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | marko | all versions | 5.38.36npm install marko@5.38.36 |
| 📦npm | @marko/runtime-tags | all versions | 6.0.164npm install @marko/runtime-tags@6.0.164 |
Affected Products
markoopenjsfmarko\/runtime-tagsopenjsfDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for marko, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update marko to 5.38.36 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-41591 is resolved across your whole dependency graph.
Workarounds
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Frequently Asked Questions
Is CVE-2026-41591 in your dependencies?
Find it across npm, including transitive dependencies.