Description

js-toml is a TOML parser for JavaScript, Prior to version 1.1.2, the interpreter checks whether a key already exists in a parser-built container with `if (object[key])` instead of `if (key in object)`. When the prior value is a falsy primitive — `false`, `0`, `0n`, `0.0`, `-0`, or `""` — the duplicate-key branch is skipped and the value is silently overwritten by a later sub-table, dotted-key sub-table, or array-of-tables sharing the same name. Per the TOML 1.0.0 spec ("Defining a key multiple times is invalid"; "You cannot define any key or table more than once"), this should be a parse error. The result is structural type confusion of attacker-named keys in the value returned by `load()`. A boolean-typed `false` (or numeric `0`) becomes a truthy object. Host applications that gate behavior on `if (config.flag)`, `if (!user.banned)`, `if (config.allowDelete)`, or `if (config.publicMode)` will silently take the truthy branch. This is distinct from GHSA-65fc-cr5f-v7r2 (the 1.0.2 prototype-pollution fix). `Object.prototype` is not polluted. The `Object.create(null)` mitigation from 1.0.2 is intact; the bug here is in the duplicate-key state machine, not in container construction. Version 1.1.2 patches the incorrect comparison.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-14T19:17:18.980Z",
  "pubdate": "2026-08-14T19:17:18.980Z",
  "executiveSummary": "An improper duplicate key validation vulnerability exists in js-toml prior to version 1.1.2. The flaw resides in the parser's duplicate-key state machine, where checking for existing keys via falsy primitives leads to silent overwriting by subsequent sub-tables, dotted-key sub-tables, or arrays-of-tables. This behavior violates the TOML 1.0.0 specification, which mandates that defining any key or table more than once must be treated as a parse error.\nThe primary impact is structural type confusion of attacker-controlled keys within the parsed object returned by the load() function. When a prior value is a falsy primitive such as false, 0, or an empty string, the duplicate-key validation check evaluates to false due to improper boolean coercion. Consequently, the value is overwritten and transformed from a primitive type into a truthy object.\nHost applications that rely on standard truthiness checks for security-critical configuration flags—such as access control, feature gating, or permission validation—will silently execute the incorrect execution branch, potentially leading to unauthorized privilege escalation, unintended feature enablement, or security control bypasses.\nThe vulnerability affects all versions of js-toml prior to 1.1.2. Exploitation requires an attacker to supply a maliciously crafted TOML payload containing duplicate keys mapped to falsy primitives, which is then parsed by an application utilizing the vulnerable library. This issue is distinct from prototype pollution and does not alter Object.prototype.",
  "technicalDetails": "The root cause of the vulnerability lies in the duplicate-key validation logic within the parser's state machine. Specifically, the interpreter checks whether a key already exists within a parser-built container using the conditional statement if (object[key]) rather than the strict property existence check if (key in object).\nWhen a pre-existing key maps to a falsy primitive value—including false, 0, 0n, 0.0, -0, or \"\"—the conditional expression evaluates to false. As a result, the state machine skips the intended duplicate-key rejection branch, bypassing the specification requirement defined in TOML 1.0.0 stating that defining a key or table multiple times is invalid.\nDuring the attack flow, a malicious actor crafts a TOML input where a sensitive configuration parameter is initially defined with a falsy primitive value (e.g., config.publicMode = false or config.allowDelete = 0). Later in the document, the attacker redefines the same key using a sub-table, dotted-key sub-table, or an array-of-tables.\nBecause the initial falsy primitive causes the duplicate check to fail, the parser silently overwrites the primitive value with the newly supplied structure. When the application executes the load() function and subsequently evaluates conditional checks such as if (config.publicMode), the resulting value is a newly constructed, truthy object rather than the intended boolean or numeric primitive.\nThis structural type confusion alters the logical control flow of host applications. Security controls, feature flags, and administrative restrictions designed to enforce security boundaries when configuration properties evaluate to false or zero are bypassed because the overwritten value consistently evaluates to true.\nThe vulnerability is localized to the duplicate-key handling mechanism in the container population routines of js-toml prior to version 1.1.2. Mitigation mechanisms introduced in previous patches, such as container construction using Object.create(null) to prevent prototype pollution, remain intact and unaffected by this logic flaw."
}