GHSA-x9fj-57fh-c8wq

Suggest an improvement
Source
https://github.com/advisories/GHSA-x9fj-57fh-c8wq
Import Source
https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/04/GHSA-x9fj-57fh-c8wq/GHSA-x9fj-57fh-c8wq.json
JSON Data
https://api.osv.dev/v1/vulns/GHSA-x9fj-57fh-c8wq
Aliases
  • CVE-2026-41591
Published
2026-04-22T19:55:51Z
Modified
2026-05-13T13:54:56.772894Z
Severity
  • 6.4 (Medium) CVSS_V3 - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N CVSS Calculator
Summary
Marko: XSS via case-insensitive script/style closing tag bypass in runtime HTML escaping
Details

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 19d4b37d0fix: 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.

Database specific
{
    "github_reviewed": true,
    "severity": "MODERATE",
    "nvd_published_at": "2026-05-08T16:16:11Z",
    "cwe_ids": [
        "CWE-79"
    ],
    "github_reviewed_at": "2026-04-22T19:55:51Z"
}
References

Affected packages

npm / marko

Package

Affected ranges

Type
SEMVER
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
5.38.36

Database specific

source
"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/04/GHSA-x9fj-57fh-c8wq/GHSA-x9fj-57fh-c8wq.json"

npm / @marko/runtime-tags

Package

Name
@marko/runtime-tags
View open source insights on deps.dev
Purl
pkg:npm/%40marko/runtime-tags

Affected ranges

Type
SEMVER
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.0.164

Database specific

source
"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/04/GHSA-x9fj-57fh-c8wq/GHSA-x9fj-57fh-c8wq.json"