CVE WatchAug 6, 2026

CVE-2026-71438

Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. Prior to 10.9.8 and 11.16.1, Mermaid

CVSS

—

No CVSS

EPSS

—

KEV

—

Exploit Today

—

0-100

Published: Aug 6, 2026 · Last modified: Aug 6, 2026 · CWE-1321

EPSS · 30d

Not enough EPSS history yet.

Technical description

Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. Prior to 10.9.8 and 11.16.1, Mermaid's configuration setters (mermaid.initialize, mermaidAPI.setConfig, and mermaidAPI.updateSiteConfig) merge caller-supplied configuration into Mermaid's internal config using the assignWithDepth deep-merge helper, which is vulnerable to prototype pollution. This is only exploitable if an application forwards untrusted data directly into one of these configuration entry points, which is outside their documented usage; diagram-supplied configuration (e.g. %%{init: {}}%% or YAML frontmatter) is not affected. This issue is fixed in versions 10.9.8 and 11.16.1.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-71437—

—

———Mermaid is a JavaScript tool that uses Markdown-inspired text to create and modify diagrams and charts. From version 11.5.0 until 11.16.1, Mermaid Architecture Diagrams are vulnerable to prototype pollution when a diagram defines a group with an id of __proto__. Because the group id is used directly as an object property key without validation, an attacker who can supply diagram text can pollute Object.prototype, potentially affecting the behavior of the embedding application. This issue is fixed in version 11.16.1.4h CVE-2026-706105.4 MED

—

——0Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.9, 40.9.2, 41.2.2, and 42.0.0-beta.4, objects copied across the contextBridge boundary from untrusted content could carry an attacker-influenced prototype, enabling prototype-pollution-style attacks against preload code despite context isolation being enabled. Apps are only affected if their preload code accepts object arguments from untrusted content and reads properties from them without own-property checks, while apps that only accept primitive arguments or validate object arguments are not affected. This issue is fixed in 39.8.9, 40.9.2, 41.2.2, and 42.0.0-beta.4.11h CVE-2026-14574—

—

——0In Eclipse Theia versions 0.7.0 and up until including 1.73.1, the `PreferenceUtils.merge` function in `@theia/core` recursively merges preference values without rejecting prototype-related keys (`__proto__`, `constructor`, `prototype`). Because this function is invoked by `PreferenceServiceImpl.doResolve` for every preference resolution across scopes (default, user, workspace, folder), a crafted preference value in a workspace settings file (`.theia/settings.json` or `.vscode/settings.json`) can pollute `Object.prototype` when the user opens the workspace, potentially altering application logic across the Theia process.10h CVE-2026-67319—

17.3%

——5axios before 0.33.0 (and 1.x before 1.18.0) can consume inherited properties from nested request option objects when the JavaScript process's Object.prototype has already been polluted by another component. While the top-level merged config uses a null prototype, nested plain objects such as auth and paramsSerializer are cloned into ordinary objects and read without own-property checks. When an application passes placeholder nested objects such as auth: {} or paramsSerializer: {}, inherited username/password values can cause silent injection of an Authorization: Basic header, and inherited encode/serialize values can alter query-string serialization (full serializer replacement requires a function-valued pollution primitive). This is exploitable only in the presence of pre-existing prototype pollution.3d CVE-2026-67316—

17.3%

——5axios is vulnerable to read-side prototype-pollution gadgets that can alter request construction when Object.prototype has already been polluted by a separate vulnerability or dependency. In the bodyless method aliases (axios.get(), axios.delete(), axios.head(), axios.options()), inherited data is read via (config || {}).data before config normalization, causing an attacker-controlled body to be sent on requests that did not set one. Additional low-level paths, only reachable when calling exported adapters/helpers (e.g. lib/adapters/http.js, unsafe/helpers/resolveConfig.js) directly with plain configs and no own proxy or paramsSerializer, can inherit polluted proxy values (routing requests through an attacker-controlled proxy) or paramsSerializer values (attacker-controlled URL serialization). These low-level gadgets do not reproduce through normal high-level axios calls on 1.15.2+. The issue is fixed in axios 1.18.0 and 0.33.0.3d CVE-2026-67314—

29.2%

——9axios versions >=1.15.2 and <1.18.0 contain prototype-pollution read-side gadgets in Basic auth subfield handling (lib/adapters/http.js and lib/helpers/resolveConfig.js). When an application is already affected by a separate prototype-pollution primitive and makes an axios request with an own auth object that omits the username and/or password properties, axios reads the inherited Object.prototype.username and Object.prototype.password values and uses them to construct an outbound 'Authorization: Basic ...' header. axios itself does not pollute prototypes. The practical impact is outbound request tampering: an attacker who controls the polluted prototype values can inject attacker-chosen Basic auth credentials or replace an existing Authorization header. Credential disclosure is only possible under additional application-specific conditions.3d