npm · mermaid
Mermaid configuration APIs allow prototype pollution
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.
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
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.
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.
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.