Mermaid configuration APIs allow prototype pollutionGHSA-c4c3-pg64-4m4v
Fix: mermaid-js/mermaid#8022GHSA-c4c3-pg64-4m4v is a CWE-1321 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-c4c3-pg64-4m4v.
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's configuration setters (mermaid.initialize, mermaidAPI.setConfig, and mermaidAPI.updateSiteConfig) merge the caller-supplied configuration object into Mermaid's internal config using the assignWithDepth deep-merge helper that is vulnerable to prototype pollution.
Because these APIs are intended to receive trusted configuration supplied by the application integrating Mermaid, Mermaid assesses the practical risk as low. The vulnerability is only reachable if an application forwards attacker-controlled data directly into one of these configuration entry points, which is outside their documented usage.
User-controlled configuration (e.g. configuration in diagram code using %%{init: {}}%% or YAML frontmatter) are already protected from prototype pollution.
Patches
This has been patched in https://github.com/mermaid-js/mermaid/commit/2cd6dcf735533b323507e3e889ffdea870540b43 and released in Mermaid v11.16.1.
A backport has been made for the v10 branch in c34b07a0815842327e70794d69b0c8c5a1e2a956 and was released in Mermaid v10.9.8
Impact
Mermaid believes it's unlikely that anybody is impacted, as these functions are configuration entry points expected to receive trusted, developer-controlled values as they can modify other security-relevant configuration.
Workarounds
Don't pass user-controlled data to the mermaid.initialize, mermaidAPI.setConfig, and mermaidAPI.updateSiteConfig functions. Instead, users can use %%{init: {}}%% or YAML frontmatter in diagrams.
Reporters
- [email protected] (Liyi), https://lzhou1110.github.io/
- [email protected] (Ziyue), https://zyy0530.github.io/
- [email protected] (Strick), https://str1ckl4nd.github.io/
- [email protected] (Maurice), http://maurice.busystar.org/
- [email protected] (Chenchen), https://7thparkk.github.io/
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-c4c3-pg64-4m4v is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-c4c3-pg64-4m4v in your dependencies?
Find it across npm, including transitive dependencies.