GHSA-c4c3-pg64-4m4v

### 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](https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.16.1). A backport has been made for the v10 branch in c34b07a0815842327e70794d69b0c8c5a1e2a956 and was released in [Mermaid v10.9.8](https://github.com/mermaid-js/mermaid/releases/tag/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/