CVE-2026-71438

ADVISORY - github

Summary

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

Common Weakness Enumeration (CWE)

ADVISORY - github

Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')


GitHub

CREATED

UPDATED

EXPLOITABILITY SCORE

-

EXPLOITS FOUND
-
COMMON WEAKNESS ENUMERATION (CWE)

CVSS SCORE

2.4low
PackageTypeOS NameOS VersionAffected RangesFix Versions
mermaidnpm-->=11.0.0-alpha.1,<11.16.111.16.1
mermaidnpm--<10.9.810.9.8

CVSS:4 Severity and metrics

The CVSS metrics represent different qualitative aspects of a vulnerability that impact the overall score, as defined by the CVSS Specification.

The vulnerable component is not bound to the network stack and the attacker's path is via read/write/execute capabilities. Either: The attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or remotely (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document).

Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success when attacking the vulnerable component.

The successful attack depends on the presence of specific deployment and execution conditions of the vulnerable system that enable the attack. These include: A race condition must be won to successfully exploit the vulnerability. The successfulness of the attack is conditioned on execution conditions that are not under full control of the attacker. The attack may need to be launched multiple times against a single target before being successful. Network injection. The attacker must inject themselves into the logical network path between the target and the resource requested by the victim (e.g. vulnerabilities requiring an on-path attacker).

The attacker requires privileges that provide significant (e.g., administrative) control over the vulnerable system allowing full access to the vulnerable system's settings and files.

Successful exploitation of this vulnerability requires a targeted user to perform specific, conscious interactions with the vulnerable system and the attacker's payload, or the user's interactions would actively subvert protection mechanisms which would lead to exploitation of the vulnerability. Examples include: importing a file into a vulnerable system in a specific manner placing files into a specific directory prior to executing code submitting a specific string into a web application (e.g. reflected or self XSS) dismiss or accept prompts or security warnings prior to taking an action (e.g. opening/editing a file, connecting a device).

There is no loss of confidentiality within the Vulnerable System.

There is a total loss of confidentiality, resulting in all resources within the Subsequent System being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.

Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. The data modification does not have a direct, serious impact to the Vulnerable System.

There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the Subsequent System. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the Subsequent System.

Performance is reduced or there are interruptions in resource availability. Even if repeated exploitation of the vulnerability is possible, the attacker does not have the ability to completely deny service to legitimate users. The resources in the Vulnerable System are either partially available all of the time, or fully available only some of the time, but overall there is no direct, serious consequence to the Vulnerable System.

There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the Subsequent System; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the Subsequent System (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).