CVE-2026-41149

What it actually does

Mermaid versions 10.9.5 and earlier and 11.0.0-alpha.1 through 11.14.0 improperly validate content supplied through the classDef directive in state diagrams. Under the default configuration, crafted diagram text can inject HTML into the rendered DOM and escape the intended SVG rendering context. Mermaid strips <script> tags, which materially limits classic script-based cross-site scripting, but the flaw can still allow attacker-controlled markup to be inserted into pages that render untrusted Mermaid diagrams. This can affect page integrity, visual trust boundaries, embedded content, links, forms, and other DOM elements depending on the surrounding application.

Why it matters to the business

Applications that allow users to submit or edit Mermaid diagrams may let an attacker alter what other users see in documentation, wikis, issue trackers, knowledge bases, dashboards, or developer portals. The most likely consequences are content spoofing, misleading links or forms, defacement-like changes, phishing inside a trusted interface, or forced loading of attacker-controlled external resources. The issue is not currently in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a low EPSS score of 0.00401 with no 30-day increase, so emergency internet-wide exploitation is not indicated; however, remediation is still important for platforms that render untrusted diagrams.

How an attack unfolds

An attacker first identifies an application that renders user-controlled Mermaid diagrams using an affected Mermaid version and the default security configuration. The attacker then submits a crafted state diagram containing a classDef directive with HTML designed to break out of the SVG context. When another user opens the page, issue, document, comment, or preview containing the diagram, Mermaid renders the attacker-supplied markup into the surrounding DOM. Because <script> tags are stripped, the attacker is constrained away from straightforward script execution, but can still inject visible or interactive HTML, such as deceptive content, embedded external resources, links, overlays, or form-like elements. The practical attack depends on where Mermaid is embedded and what browser and application controls are in place.

How to fix it

Upgrade Mermaid to a fixed version: 10.9.6 for the 10.x line or 11.15.0 for the 11.x line. If immediate upgrade is not possible, configure Mermaid with "securityLevel": "sandbox" so diagrams are rendered inside a sandboxed iframe, preventing the DOM escape path. For applications rendering untrusted content, also validate and sanitize Mermaid input before rendering, restrict who can create or edit rendered diagrams, apply a restrictive Content Security Policy, disallow unnecessary external resource loading, and ensure Markdown/HTML sanitization occurs after all rendering transformations where applicable.

How to confirm the fix worked

Inventory frontend bundles, package-lock.json, yarn.lock, pnpm-lock.yaml, npm-shrinkwrap.json, and dependency manifests for Mermaid versions. Confirm deployed assets use Mermaid 10.9.6 or 11.15.0 or later, or verify that runtime configuration sets "securityLevel": "sandbox". Test representative pages that render user-supplied Mermaid state diagrams and confirm crafted classDef HTML is not inserted into the parent page DOM. Browser developer tools, automated UI tests, and dependency scanners can be used to verify both package version and rendering behavior. Also confirm that cached/static bundles, documentation builds, and downstream packaged copies have been rebuilt after the upgrade.

Typical attack path

1. Find a site, documentation platform, issue tracker, wiki, or application feature that renders Mermaid diagrams from user-supplied Markdown or text.
2. Confirm the application uses Mermaid versions 10.9.5 or earlier, or 11.0.0-alpha.1 through 11.14.0, and has not set securityLevel to sandbox.
3. Create a Mermaid state diagram that uses the classDef directive with crafted HTML payload content.
4. Submit the payload through a page, comment, pull request, issue, document, profile field, or other content input that will be rendered for other users.
5. Wait for a victim to view the rendered diagram.
6. Use the injected HTML to alter page content, display misleading UI, embed external resources, or direct users to attacker-controlled locations.

How to detect it

To determine whether this was already abused, review content that stores or renders Mermaid diagrams, especially Markdown documents, comments, tickets, wiki pages, pull requests, documentation pages, and user-editable fields. Search application logs, audit logs, content revision history, web access logs, and source repositories for Mermaid state diagrams containing classDef directives with raw HTML, iframe/object/embed tags, image tags, form elements, inline event handlers, javascript: URLs, data: URLs, or suspicious external domains. Examine rendered pages for unexpected DOM nodes outside the expected SVG diagram container. Network telemetry may show browsers requesting attacker-controlled resources embedded by injected HTML. Because this issue strips <script> tags and no public exploitation indicators or named threat actors are provided, detection should focus on anomalous Mermaid payload content and unexpected external resource loads from pages that normally only render diagrams.

• stateDiagram
• stateDiagram-v2
• classDef
• classDef.*<iframe
• classDef.*<object
• classDef.*<embed
• classDef.*<img
• classDef.*<form
• classDef.*<input
• classDef.*<button
• classDef.*<a
• classDef.*onerror=
• classDef.*onload=
• classDef.*onclick=
• classDef.*javascript:
• classDef.*data:text/html
• classDef.*src=http
• classDef.*href=http
• securityLevel.*sandbox

What your security team should do

• Prioritize patching systems that render Mermaid diagrams from untrusted or semi-trusted users, such as public documentation, collaboration platforms, issue trackers, wikis, and customer-facing portals.
• Upgrade Mermaid to 10.9.6 or 11.15.0 or later across source code, lockfiles, built assets, and container images.
• If patching is delayed, set Mermaid "securityLevel" to "sandbox" and restrict Mermaid rendering to trusted authors only.
• Search repositories, content stores, and application logs for suspicious Mermaid state diagrams using classDef with embedded HTML or event-handler-like attributes.
• Review pages containing suspicious diagrams for injected links, forms, iframes, images, or external resource references.
• Harden hosting applications with Content Security Policy controls that restrict frame, image, form, connect, and navigation destinations.
• Add regression tests to prevent Mermaid-rendered HTML from escaping into the parent DOM when user-controlled diagram content is rendered.