The CVSS 5.3 score for CVE-2026-50029 badly understates the real risk. This is not a typical configuration-tampering flaw — it is a semantic type-confusion defect in js-toml where the duplicate-key detection state machine uses a truthiness check (if (object[key])) instead of a membership check (if (key in object)). When a prior key holds a falsy primitive like false or 0, the check fails silently, and the parser overwrites that value with a subsequent table structure. The consuming application then receives a truthy object where it expects a boolean false, and any downstream if (config.allowDelete) or if (!user.banned) check becomes an unauthenticated control-flow oracle controlled by attacker-chosen keys.
What makes this analytically distinct from typical config injection is that the attacker does not bypass any schema validation — the parser itself performs the mutation. Schema validators check the post-mutation object, not the semantic intent of the TOML spec. An application that validates 'allowDelete must be boolean' will pass after the parser has already corrupted the type, because the validator sees a truthy object, not the original boolean false.
The realistic attack surface depends on how many js-toml consumers gate security decisions on boolean config flags. Applications checking if (config.publicMode) or if (config.adminEnabled) face severe outcomes. The CVSS 5.3 reflects a scoring model that cannot capture downstream usage patterns — a config file gating access control is fundamentally riskier than one setting numeric thresholds.
This bug likely persisted because post-patch audit culture treats the patched code path as sealed while adjacent logic remains unexamined. The 1.0.2 prototype-pollution fix addressed a visible vulnerability, but the duplicate-key bypass was quieter and required specific downstream usage patterns to notice. The same falsy-check bypass has appeared in other TOML parsers — Python's toml library and a Rust TOML crate both had similar flaws — suggesting this is a systemic pattern rather than a one-off error. The conceptual framework developers use for "key already exists" defaults to truthiness checks instead of membership checks across multiple parser implementations.
Audit your application: if you consume js-toml and make security decisions based on boolean config flags, you need schema validation after every load() call that explicitly checks the type of each flag, not just its presence. The fix in js-toml exists, but the remediation timeline requires downstream consumers to upgrade a transitive dependency they may not know they're using, and the exposure window extends until that chain propagates.