CVE-2026-49293
HighCVSS 7.5Exploitation Probability (EPSS)
Elevated risk51th percentile - higher than 51% of all known CVEs
Summary
js-toml up to and including 1.1.1 parses hex/octal/binary integer literals in an O(n²) loop with no upper bound on literal length. A single TOML document with a ~500 kB hex literal pins one CPU core for ~40 seconds, enabling a CPU exhaustion DoS.
Risk Assessment
Applications calling load() on attacker-controlled TOML (config upload endpoints, CI/CD, IDE plugins) are exposed to single-request CPU exhaustion. This can lead to service unavailability.
Recommendation
Upgrade js-toml to version 1.1.2 which fixes the issue. Additionally, consider limiting the size of TOML documents processed.
Other vulnerabilities in js-toml
See all- CVE-2026-63386Medium
js-toml is a TOML parser for JavaScript. Prior to 1.1.3, load() does not bound nesting or dotted-key depth in the recursive parser, so deeply nested arrays, deeply nested inline tables, or long dotted keys can exhaust the V8 call stack and throw a raw RangeError instead of the documented SyntaxParseError. Applications that parse attacker-controlled TOML and handle only SyntaxParseError can rethrow the unexpected exception, which can terminate a worker or process and cause denial of service. The issue does not affect confidentiality or integrity and is fixed in version 1.1.3.
- CVE-2026-50029Medium
js-toml, a TOML parser for JavaScript, before version 1.1.2 contains a vulnerability due to incorrect duplicate key checking. Instead of checking `if (key in object)`, it uses `if (object[key])`, causing that when the previous value is falsy (e.g., `false`, `0`, `""`), the duplicate key branch is skipped and the value is silently overwritten. This leads to structural type confusion in the returned object.
Original NVD description (English source)
js-toml is a TOML parser for JavaScript, fully compliant with the TOML 1.0.0 Spec. Versions up to and including 1.1.1 parse hexadecimal / octal / binary integer literals via a hand-written `parseBigInt` loop that multiplies a `BigInt` accumulator by the radix once per input digit. Each iteration performs a `BigInt * BigInt` operation on an accumulator that grows linearly with the number of digits already consumed, so the whole loop is O(n²) in the literal length. The lexer regex places no upper bound on the literal length, so a single TOML document containing one ~500 kB hex literal pins one CPU core for ~40 seconds on a modern laptop (Apple M-series, Node v22). Memory amplification is bounded but CPU amplification is severe and grows quadratically: doubling the literal length quadruples the work. A caller that invokes `load()` on attacker-controlled TOML (configuration upload endpoints, CI/CD systems ingesting third-party `*.toml`, IDE plugins, build tools) is exposed to a single-request CPU exhaustion DoS. Version 1.1.2 fixes the issue.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS