Mermaid allows CSS injection applying to sibling elements of the diagramGHSA-6x64-9x62-f2gx
Fix: mermaid-js/mermaid#8022GHSA-6x64-9x62-f2gx is a Code Injection vulnerability in mermaid. A fix is available for mermaid — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-6x64-9x62-f2gx.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
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.
mermaidnpmDescription
Summary
Mermaid does not fully restrict CSS to the rendered SVG subtree. Although selectors are prefixed with #mermaid-X, sibling (~ and +) combinators can still escape the Mermaid container and inject styles to DOM elements adjacent to the diagram <svg>.
Most users of mermaid would not be affected by this, as mermaid adds its <svg> as an only child of it's parent element. However, you may be affected if you manually insert the <svg> (or other elements) into the DOM yourself.
Details
Mermaid namespaces CSS through with a middleware intended to scope all rules to the diagram's SVG element. CSS nesting expands & ~ * { ... } to #svgId ~ *, which selects all sibling elements following the SVG in the DOM, outside the diagram boundary.
Impact
An attacker able to supply diagram source to a page (e.g., user-generated content rendered by Mermaid) could inject CSS rules affecting sibling elements to the diagram <svg> on the host page. This can be used for UI redressing, hiding content, conditional CSS-based probing, or phishing-style visual manipulation.
JavaScript execution is not possible via this vector.
Patches
This has been patched in https://github.com/mermaid-js/mermaid/commit/12d472c9ed43f94814b110da8d7a9ae6dd5266ed and released in Mermaid v11.16.1.
A backport has been made for the v10 branch in 7e83f1533318b307764d961906a73377266f4c5e and was released in Mermaid v10.9.8
Workarounds
If you are inserting the <svg> into the DOM yourself, you can wrap it in an element with no other children, e.g. <div><svg>...</svg></div> or element.innerHTML = svg. Alternatively, you can use mermaid.run() or mermaid.initialize() which will do this for you.
Setting "securityLevel": "sandbox" will also prevent this, or setting the secure config value in the mermaid config to avoid allowing diagrams to modify fontFamily, themeCSS, altFontFamily, and themeVariables.
To test, you can try using a themeCSS with & + * { /* my CSS here */} and see if it's applied outside of your mermaid <svg>.
---
config:
themeCSS: |-
& + * { background:red !important; width:100vw !important; height:100vh !important; position:fixed !important; inset:0 !important; }
---
info
References
- GHSA-87f9-hvmw-gh4p/CVE-2026-41159 (related vulnerability)
- https://github.com/mermaid-js/mermaid/commit/12d472c9ed43f94814b110da8d7a9ae6dd5266ed
- https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1
- https://github.com/mermaid-js/mermaid/commit/7e83f1533318b307764d961906a73377266f4c5e
- https://github.com/mermaid-js/mermaid/releases/tag/v10.9.8
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | mermaid | ≥ 11.0.0-alpha.1&&< 11.16.1 | 11.16.1npm install mermaid@11.16.1 |
| 📦npm | mermaid | all versions | 10.9.8npm install mermaid@10.9.8 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for mermaid, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update mermaid to 11.16.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6x64-9x62-f2gx is resolved across your whole dependency graph.
Workarounds
Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Red Hat ships Mermaid embedded in the same code-server based developer workbench images: OpenShift AI's odh-workbench-codeserver-datascience-cpu-py312 workbench image and OpenShift Dev Spaces' code-rhel9 image. The bundled version (>=11.0.0-alpha.1,<11.16.1) allows an attacker who controls diagram text to inject…
Avoid rendering untrusted or externally-sourced Mermaid diagram definitions in the affected workbench images until the pinned mermaid dependency is upgraded to 11.16.1 or later.Source: Red Hat security advisory for GHSA-6x64-9x62-f2gx (CC BY 4.0)
Frequently Asked Questions
Is GHSA-6x64-9x62-f2gx in your dependencies?
Find it across npm, including transitive dependencies.