Sign In

CVE-2026-50159

ADVISORY - github

Summary

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

Common Weakness Enumeration (CWE)

ADVISORY - github

CWE-94⁠

Improper Control of Generation of Code ('Code Injection')

Impacted images

Advisories

GitHub

CREATED

UPDATED

ADVISORY IDGHSA-6x64-9x62-f2gx⁠
EXPLOITABILITY SCORE

-

EXPLOITS FOUND
-
COMMON WEAKNESS ENUMERATION (CWE)
CWE-94⁠

CVSS SCORE

5.3medium
PackageTypeOS NameOS VersionAffected RangesFix Versions
mermaidnpm-->=11.0.0-alpha.1,<11.16.111.16.1
mermaidnpm--<10.9.810.9.8

CVSS:4 Severity and metrics

The CVSS metrics represent different qualitative aspects of a vulnerability that impact the overall score, as defined by the CVSS Specification⁠.

The vulnerable component is bound to the network stack, but the attack is limited at the protocol level to a logically adjacent topology. This can mean an attack must be launched from the same shared physical (e.g., Bluetooth or IEEE 802.11) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., MPLS, secure VPN to an administrative network zone). One example of an Adjacent attack would be an ARP (IPv4) or neighbor discovery (IPv6) flood leading to a denial of service on the local LAN segment (e.g., CVE-2013-6014).

Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success when attacking the vulnerable component.

The successful attack does not depend on the deployment and execution conditions of the vulnerable system. The attacker can expect to be able to reach the vulnerability and execute the exploit under all or most instances of the vulnerability.

The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.

Successful exploitation of this vulnerability requires limited interaction by the targeted user with the vulnerable system and the attacker's payload. These interactions would be considered involuntary and do not require that the user actively subvert protections built into the vulnerable system. Examples include: utilizing a website that has been modified to display malicious content when the page is rendered (most stored XSS or CSRF) running an application that calls a malicious binary that has been planted on the system using an application which generates traffic over an untrusted or compromised network (vulnerabilities requiring an on-path attacker).

There is no loss of confidentiality within the Vulnerable System.

There is some loss of confidentiality. Access to some restricted information is obtained, but the attacker does not have control over what information is obtained, or the amount or kind of loss is limited. The information disclosure does not cause a direct, serious loss to the Subsequent System.

Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact to the Vulnerable System.

Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact to the Subsequent System.

There is no impact to availability within the Vulnerable System.

Performance is reduced or there are interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the Subsequent System are either partially available all of the time, or fully available only some of the time, but overall there is no direct, serious consequence to the Subsequent System.