CVE-2026-50029 in js-toml
Summary
by MITRE • 08/14/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/14/2026
The js-toml library presents a critical parsing vulnerability that stems from improper duplicate key detection logic within its interpreter. This flaw exists specifically in versions prior to 1.1.2 where the parser employs a faulty conditional check using `if (object[key])` rather than the correct `if (key in object)` syntax when validating whether a key already exists in the parser-built container. The vulnerability manifests when processing TOML documents containing duplicate keys with falsy primitive values such as boolean false, numeric zero, empty strings, or negative zero. Under normal circumstances, these falsy values should trigger a parse error according to the TOML 1.0.0 specification which explicitly states that defining any key or table more than once is invalid and results in structural type confusion.
The technical implementation flaw creates a scenario where legitimate duplicate key detection fails due to JavaScript's truthiness evaluation rather than existence checking. When a falsy value like false or 0 is encountered as a prior key value, the condition `if (object[key])` evaluates to false, causing the parser to skip the duplicate key branch and silently overwrite the existing value with subsequent occurrences. This behavior violates the TOML specification's requirement for explicit parse errors on duplicate definitions. The consequence of this vulnerability extends beyond simple parsing failures into potential security implications for applications that rely on configuration values for access control decisions, authentication checks, or privilege management.
Applications utilizing js-toml for configuration parsing face significant operational risks from this vulnerability as it enables attackers to manipulate configuration structures in unexpected ways. Host applications that depend on conditional logic such as `if (config.flag)`, `if (!user.banned)`, `if (config.allowDelete)`, or `if (config.publicMode)` will experience silent behavior changes when falsy values are overwritten by subsequent duplicate keys. The boolean false value gets replaced with a truthy object, causing applications to incorrectly take branches that should remain inaccessible. This vulnerability operates at the level of structural type confusion rather than prototype pollution as seen in related issues like GHSA-65fc-cr5f-v7r2, making it distinct in both scope and impact.
The security implications of this vulnerability align with several ATT&CK techniques including privilege escalation through configuration manipulation and execution of malicious code via modified application behavior. The CWE classification for this issue would be CWE-1287 - Improper Handling of Duplicate Keys in Configuration Files, which falls under the broader category of configuration management flaws. This vulnerability demonstrates how seemingly minor implementation details in parsing logic can result in significant security consequences, particularly when applications perform runtime decisions based on parsed configuration values. The fix implemented in version 1.1.2 addresses the core comparison logic issue while maintaining the existing Object.create(null) mitigation strategy that was introduced in version 1.0.2, ensuring that the duplicate key state machine operates correctly without compromising other security measures.