CVE-2026-71438: Prototype Pollution in Mermaid Configuration APIs

Mermaid is a widely deployed client-side and server-side JavaScript library designed to parse Markdown-inspired text and generate structured charts, flowcharts, and sequence diagrams. In modern single-page applications, content-management portals, and documentation frameworks, Mermaid is heavily integrated as the rendering engine for visualization payloads. The library exposes public APIs allowing developers to specify layout preferences, security controls, and visual styling configurations globally or dynamically.\n\nThe attack surface of interest involves Mermaid's configuration-setting interfaces, specifically the initialize, setConfig, and updateSiteConfig APIs. When a host application initializes or updates its diagramming parameters, these APIs ingest data structured as nested JSON properties. To merge the incoming values into the internal configuration object without overriding adjacent properties, the library relies on an internal deep-merge utility named assignWithDepth.\n\nThe vulnerability, designated CVE-2026-71438 and mapped under CWE-1321, arises because assignWithDepth recursively merges properties without checking for special keys that access the global object prototype. Consequently, if a downstream application accepts untrusted configurations from external inputs and directly passes them to the initialization endpoints, an attacker can supply malicious keys to overwrite prototype behaviors. This introduces a vector for prototype pollution, which can be leveraged to disable security sandboxes or alter core application configurations.

The vulnerability resides in packages/mermaid/src/assignWithDepth.ts within the recursive helper utility assignWithDepth. This function takes a destination object and a source object, then recursively copies key-value pairs from the source to the destination. Because the loop was designed to handle arbitrarily nested objects, it evaluates each key without validating whether the key string is a forbidden descriptor, such as proto or constructor.\n\nWhen processing an untrusted object, the engine iterates over its properties using Object.keys(src). If the source object contains a nested key named proto, the function evaluates the expression (dst[key] === undefined || typeof dst[key] === 'object'). Since proto naturally exists on the prototype chain of any standard JavaScript object, querying dst['proto'] returns the base Object.prototype. This causes the typeof check to evaluate to 'object' instead of resolving to undefined.\n\nFollowing this lookup, the algorithm attempts to merge properties of the nested object into the base prototype by calling assignWithDepth recursively with the prototype itself as the new destination. Because JavaScript objects inherit from this prototype, any modifications written to it pollute the global context. Subsequent lookups for these key-value pairs on completely unrelated objects will yield the polluted values, altering global state across the entire execution sandbox.

The core issue is apparent when comparing the vulnerable assignment logic to the patched version. In the vulnerable code path, property evaluation is performed directly using bracket notation accessor checks without validating the inheritance structure. The following snippet illustrates the original implementation of the recursive loop:\n\ntypescript\n// VULNERABLE IMPLEMENTATION\nObject.keys(src).forEach((key) => {\n if (\n typeof src[key] === 'object' &&\n src[key] !== null &&\n (dst[key] === undefined || typeof dst[key] === 'object')\n ) {\n if (dst[key] === undefined) {\n dst[key] = Array.isArray(src[key]) ? [] : {};\n }\n dst[key] = assignWithDepth(dst[key], src[key], { depth: depth - 1, clobber });\n } else if (clobber || (typeof dst[key] !== 'object' && typeof src[key] !== 'object')) {\n dst[key] = src[key];\n }\n});\n\n\nThis implementation is unsafe because bracket accessors traverse the inheritance chain. The patch resolves this behavior by replacing simple key checks with Object.hasOwn() and Object.defineProperty(). Rather than assigning properties directly with bracket notation, the patched algorithm ensures that any property modified must be an own property of the target object:\n\ntypescript\n// PATCHED IMPLEMENTATION\nObject.entries(src).forEach(([key, srcValue]) => {\n if (typeof srcValue === 'object') {\n if (srcValue === null) {\n return;\n }\n if (!Object.hasOwn(dst, key)) {\n Object.defineProperty(dst, key, {\n value: undefined,\n writable: true,\n enumerable: true,\n configurable: true,\n });\n }\n if (dstWithKeys[key] === undefined) {\n dstWithKeys[key] = Array.isArray(srcValue) ? [] : {};\n }\n if (typeof dstWithKeys[key] === 'object') {\n dstWithKeys[key] = assignWithDepth(dstWithKeys[key], srcValue, { depth: depth - 1 });\n }\n } else if (typeof dstWithKeys[key] !== 'object') {\n if (Object.hasOwn(dst, key)) {\n dstWithKeys[key] = srcValue;\n } else {\n Object.defineProperty(dst, key, {\n value: srcValue,\n writable: true,\n enumerable: true,\n configurable: true,\n });\n }\n }\n});\n\n\nBy leveraging Object.hasOwn(dst, key), the utility checks whether dst contains the property directly. If dst does not own the key, Object.defineProperty is used to declare an own property on dst with a value of undefined. This physically overrides the prototype lookup mechanism, isolating any subsequent writes to this local property and preventing global leakage.

Exploiting CVE-2026-71438 requires a specific application architecture. The hosting application must ingest configuration objects directly from a user-controlled, unsanitized source—such as a JSON payload delivered via a REST API, query parameters, or form fields. Once received, the application must pass this configuration object directly into mermaid.initialize(), mermaidAPI.setConfig(), or mermaidAPI.updateSiteConfig().\n\nAn attacker can craft a payload containing a proto property containing a nested securityLevel assignment. The structured JSON attack vector is shown below:\n\njson\n{\n \"__proto__\": {\n \"securityLevel\": \"loose\"\n }\n}\n\n\nWhen the host application passes this object to the vulnerable Mermaid configuration sink, assignWithDepth traverses the proto key. It verifies that typeof dst['proto'] is 'object', then recursively processes the nested object. Consequently, the value of Object.prototype.securityLevel is set to 'loose'.\n\nOnce global prototype pollution is achieved, the security sandbox configurations of all subsequent diagram renderers are compromised. Because Mermaid defaults to checking securityLevel during parser execution, any subsequently generated diagram will execute under the polluted loose security context. This disables default script filtering and sandbox protection, allowing the attacker to trigger client-side Cross-Site Scripting (XSS) or arbitrary HTML execution through standard diagram syntaxes. It is important to note that configuration declarations embedded inside diagram syntax itself, such as frontmatter blocks or directive comments, are processed via isolated sanitization pipelines and are not vulnerable.

The impact of CVE-2026-71438 is classified as Medium, receiving a CVSS v4.0 score of 2.4. This low direct score is due to the severe prerequisites required for exploitation. An attacker must find an application that directly exposes the programmatic configuration interface of the Mermaid library to unvalidated user-controlled JSON data, which is an uncommon design pattern in standard integrations.\n\nIn scenarios where this configuration capability is exposed, the downstream impact is significant. Corrupting the Object.prototype globally can lead to widespread execution flow bypasses, modification of default rendering properties, or unexpected denial-of-service conditions in the host application. The primary hazard is the disabling of the securityLevel sandbox, which transitions the application from a safe diagram renderer to an unvalidated scripting environment.\n\nFurthermore, because JavaScript prototype pollution affects all objects running in the same thread, the state corruption can bleed into unrelated application components. If the application runs in a Node.js context (such as a server-side diagram generator), the pollution of Object.prototype can manipulate routing mechanisms, templating engines, or data-validation frameworks, introducing secondary execution vectors across the entire platform.

Remediation of CVE-2026-71438 requires upgrading the Mermaid library to safe versions. Applications using the v11 release line must upgrade to version 11.16.1 or later, while projects locked to the v10 release line must upgrade to version 10.9.8 or later. These versions contain the hardened assignWithDepth implementation that physically prevents prototype modification via Object.hasOwn and Object.defineProperty.\n\nIf immediate dependency upgrades are not possible, host applications must implement input-validation controls at the ingestion boundary. This involves sanitizing incoming JSON payloads by stripping or blocking keys containing proto, constructor, or prototype properties before passing the object to Mermaid's initialization routines. An example validation filter is illustrated below:\n\njavascript\nfunction sanitizeConfig(config) {\n const serialized = JSON.stringify(config);\n if (serialized.includes('__proto__') || serialized.includes('constructor')) {\n throw new Error('Malicious configuration payload detected');\n }\n return config;\n}\n\n\nAdditionally, developers should note that mermaidAPI.setConfig has been formally deprecated. The configuration management has been refactored to compile rendering parameters dynamically during execution, ensuring that state is not persistently stored on vulnerable global variables. Adopting Content Security Policy (CSP) headers that restrict script execution to trusted domains further mitigates any successful downstream XSS attempts.