EUVD-2026-38060
GHSA-wp3c-266w-4qfq
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Single attacker-controlled TOML document parsed by an unauthenticated network-reachable caller (AV:N/AC:L/PR:N/UI:N) causes CPU exhaustion only (C:N/I:N/A:H).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
4DescriptionCVE.org
js-toml is a TOML parser for JavaScript, fully compliant with the TOML 1.0.0 Spec. Versions up to and including 1.1.0 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.1 fixes the issue.
AnalysisAI
Denial of service in js-toml versions up to and including 1.1.0 allows remote attackers to exhaust CPU resources by submitting a single TOML document containing an oversized hexadecimal, octal, or binary integer literal. The hand-written parseBigInt loop exhibits O(n²) complexity, and a ~500 kB literal pins one CPU core for ~40 seconds; no public exploit identified at time of analysis, but the patched commit and test suite serve as a clear blueprint. Applies to any service invoking load() on attacker-controlled TOML, such as configuration upload endpoints, CI/CD pipelines, IDE plugins, and build tools.
Technical ContextAI
js-toml is a JavaScript TOML 1.0.0-compliant parser (cpe:2.3:a:sunnyadn:js-toml). The flaw is a classic CWE-400 Uncontrolled Resource Consumption: the NonDecimalInteger token interpreter parsed 0x/0o/0b literals by repeatedly executing result = result * BigInt(radix) + BigInt(digit), and because JavaScript BigInt multiplication cost scales with operand size, the accumulator grows linearly with digits consumed, yielding total O(n²) work. The lexer regex imposed no upper bound on literal length, so a single ~500 kB hex literal triggers ~40 seconds of synchronous CPU on Node v22 on an Apple M-series chip, blocking the event loop. The fix in commit 1abcb31 switches to the V8-native BigInt(prefixedString) constructor (O(n)) and additionally caps radix literal length to 1000 digits - matching jackson-core's StreamReadConstraints.maxNumberLength default - throwing SyntaxParseError beyond that bound.
RemediationAI
Vendor-released patch: upgrade js-toml to 1.1.1 or later (https://github.com/sunnyadn/js-toml/releases/tag/v1.1.1), which introduces a 1000-digit cap on radix-prefixed integer literals and replaces the quadratic parseBigInt loop with the native BigInt constructor (commit 1abcb31dc7b1fa88e4c848a8d108891cfbb96fa2). If immediate upgrade is not possible, applications calling load() on untrusted input should reject TOML documents above a conservative size threshold (e.g. tens of kilobytes) at the HTTP/upload layer before parsing, or pre-scan input with a regex rejecting 0x/0o/0b literals longer than ~1000 digits - note that body-size limits alone may impair legitimate large configuration files. Running load() in a worker thread with a wall-clock timeout contains the blast radius to a single core but does not eliminate amplification under concurrent requests.
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today