CVE-2026-41159

What it actually does

This vulnerability is a client-side CSS injection issue in Mermaid’s default rendering configuration before versions 10.9.6 and 11.15.0. Mermaid allowed attacker-controlled values in configuration options such as fontFamily, altFontFamily, and themeCSS to be processed by stylis in a way that could escape Mermaid’s intended diagram-only CSS scoping. By abusing stylis handling of the & scope reference, especially patterns such as :not(&), injected CSS could apply to the entire host page rather than only the Mermaid diagram. Global CSS at-rules such as @font-face, @keyframes, and @counter-style could also be hoisted to the document level. The practical impact is page-wide style manipulation, visual defacement, UI tampering, and limited browser-side data exposure through CSS-based techniques such as selectors that infer DOM attributes or page state. This is not a server-side code execution issue, despite the assigned family label; exploitation occurs in the browser of a user who views attacker-controlled Mermaid content.

Why it matters to the business

Applications that render Mermaid diagrams from user-supplied or untrusted Markdown may allow an attacker to alter the appearance and behavior of surrounding pages, which can mislead users, hide warnings, impersonate trusted UI elements, or damage confidence in the affected service. In sensitive applications, CSS-based probing may also expose limited information present in page markup, such as attribute values or state-dependent UI details. The public exploitation signal is currently low: it is not listed in CISA KEV, is not associated with ransomware activity, has no known mature exploit reported in the supplied data, and has a low, flat EPSS trend of approximately 0.004 over 30 days. However, Mermaid is commonly embedded in documentation portals, developer platforms, Markdown renderers, wikis, ticketing systems, and knowledge bases, so exposure can be widespread where untrusted diagrams are rendered.

How an attack unfolds

An attacker first identifies an application that renders Mermaid diagrams from content they can create or influence, such as Markdown pages, documentation comments, issue descriptions, wiki entries, or shared notes. They then craft Mermaid content that includes configuration values for fontFamily, altFontFamily, or themeCSS containing malicious CSS. Instead of remaining scoped to the generated Mermaid container, the CSS uses stylis scope-escaping behavior such as :not(&) or global at-rules to affect the broader page. When a victim views the page, the browser renders the Mermaid diagram and applies the injected styles outside the diagram boundary. The attacker can use this to deface the page, hide or modify surrounding interface elements, create misleading visual prompts, or attempt CSS-based DOM state or attribute inference using selectors such as :has(). Successful exploitation requires user interaction in the form of viewing attacker-controlled content, but does not require authentication if the target application allows anonymous content submission or displays attacker-controlled Mermaid content to other users.

How to fix it

Upgrade Mermaid to a fixed release: version 10.9.6 or later for the 10.x line, or version 11.15.0 or later for the 11.x line. If Mermaid is included transitively through another application, Markdown renderer, documentation platform, or frontend bundle, update the parent package or rebuild the frontend assets so the deployed JavaScript actually contains the fixed Mermaid version. Where immediate upgrade is not possible, treat Mermaid diagrams from untrusted users as active content: disable Mermaid rendering for untrusted Markdown, strip or block Mermaid configuration directives, deny use of themeCSS, fontFamily, and altFontFamily from user-controlled input, and sanitize CSS-related diagram configuration before rendering. Strengthen browser controls with a restrictive Content Security Policy that limits style sources, blocks unexpected external font loads, and restricts outbound connections that could be used for CSS-based exfiltration. Rendering untrusted diagrams in a sandboxed iframe with minimal permissions can further reduce page-wide impact.

How to confirm the fix worked

Confirm the deployed Mermaid version is 10.9.6 or later on the 10.x branch, or 11.15.0 or later on the 11.x branch. Validate both package manifests and built frontend artifacts, because applications may bundle Mermaid into static JavaScript files. Search dependency lockfiles such as package-lock.json, yarn.lock, pnpm-lock.yaml, or SBOMs for mermaid versions below the fixed releases. Functionally test with a benign proof-of-concept diagram that attempts to inject CSS using themeCSS or fontFamily with :not(&) and verify styles do not apply outside the Mermaid diagram container. Also test that global at-rules supplied through Mermaid configuration are not hoisted into the host page. Review application settings to ensure untrusted content cannot enable unsafe Mermaid configuration options. Confirm CSP headers prevent unexpected external style, font, or beacon-like network requests from rendered content.

Typical attack path

1. Find an application or service that uses Mermaid to render diagrams in Markdown or similar user-controlled content.
2. Submit or modify content containing a Mermaid diagram with attacker-controlled configuration values.
3. Inject CSS through vulnerable Mermaid options such as fontFamily, altFontFamily, or themeCSS.
4. Use stylis scope-escape patterns such as :not(&) or top-level at-rules such as @font-face, @keyframes, or @counter-style to break out of Mermaid’s intended CSS scope.
5. Wait for another user to view the content in a browser where the vulnerable Mermaid version renders the diagram.
6. Apply page-wide CSS effects to deface the page, alter UI elements, hide security-relevant information, or attempt CSS-based DOM attribute/state inference.
7. Optionally use external CSS resources or font URLs as a signaling channel if outbound browser requests are permitted by the page’s content security policy.

How to detect it

To determine whether this was already exploited, review content repositories, Markdown bodies, wiki pages, issue descriptions, documentation comments, and any database or object storage locations where Mermaid source text is stored. Look for Mermaid initialization blocks or directives containing suspicious use of themeCSS, fontFamily, or altFontFamily with CSS syntax that should not be present in normal diagram styling. Pay particular attention to scope-escape constructs such as :not(&), CSS selectors using :has(), and global at-rules such as @font-face, @keyframes, and @counter-style. Web access logs may show victims loading pages containing malicious diagrams, but exploitation itself executes in the browser and may not produce server-side errors. If the injected CSS references external resources, inspect proxy, DNS, CDN, and browser telemetry for unexpected font, stylesheet, image, or network requests triggered from pages that render Mermaid diagrams. Review CSP violation reports for blocked inline styles, external font loads, or style-src/font-src violations on Mermaid-rendering pages. In endpoint/browser telemetry, focus on unusual outbound requests from browsers immediately after users open pages with Mermaid diagrams. Forensic review should include rendered page snapshots, saved Markdown revisions, audit history for edited documents, and frontend error/security logs around the time suspicious content was created or viewed.

• themeCSS
• fontFamily
• altFontFamily
• :not(&)
• :has(
• @font-face
• @keyframes
• @counter-style
• %%{init:
• %%{initialize:
• securityLevel
• mermaid.initialize
• mermaid.render
• mermaid.min.js
• node_modules/mermaid
• package-lock.json
• yarn.lock
• pnpm-lock.yaml

What your security team should do

• Inventory applications that render Mermaid diagrams, especially documentation portals, Markdown viewers, wikis, developer collaboration tools, issue trackers, and knowledge-base systems.
• Prioritize upgrades for internet-facing or multi-user systems where untrusted users can submit Mermaid or Markdown content viewed by other users.
• Upgrade Mermaid to 10.9.6 or later for 10.x deployments, or 11.15.0 or later for 11.x deployments, and rebuild/redeploy bundled frontend assets.
• Temporarily disable Mermaid rendering or strip Mermaid configuration directives from untrusted content if an upgrade cannot be completed quickly.
• Add regression tests that verify Mermaid CSS remains scoped to the diagram container and cannot alter surrounding page elements.
• Review Content Security Policy for affected applications and restrict style-src, font-src, img-src, and connect-src to reduce CSS-assisted data leakage or signaling.
• Search existing user-generated Mermaid content for suspicious CSS escape patterns, global at-rules, external font/style URLs, and selectors designed to inspect DOM state.
• Monitor web logs and frontend telemetry for unexpected external font or style loads initiated from pages that render Mermaid diagrams.
• Because EPSS is low, flat, and there is no KEV listing, handle through normal vulnerability management unless the application renders untrusted diagrams in a sensitive or high-traffic context.