toml-node: Uncontrolled resource consumption (CPU DoS) via unbounded-length integer literals in toml.parse()

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

toml-node is a TOML parser for Node.js and the browser. Prior to 5.0.1, toml.parse() passes unbounded hexadecimal, octal, binary, and decimal digit sequences from lib/parser.js to BigInt() before reduceInteger() in lib/compiler.js checks whether the resulting value fits the TOML 64-bit integer range. Converting a sufficiently long integer string consumes super-linear CPU time and synchronously blocks the Node.js event loop, allowing one attacker-supplied TOML document to deny service to concurrent work in the process. The later range check cannot prevent the conversion cost because it executes after BigInt(). This issue is fixed in version 5.0.1.

Source published

21 Oct 2026 20:32:54 UTC

Source modified

30 Oct 2026 14:30:11 UTC

Observed here

30 Oct 2026 15:45:26 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

toml-node is a TOML parser for Node.js and the browser. Prior to 5.0.1, toml.parse() passes unbounded hexadecimal, octal, binary, and decimal digit sequences from lib/parser.js to BigInt() before reduceInteger() in lib/compiler.js checks whether the resulting value fits the TOML 64-bit integer range. Converting a sufficiently long integer string consumes super-linear CPU time and synchronously blocks the Node.js event loop, allowing one attacker-supplied TOML document to deny service to concurrent work in the process. The later range check cannot prevent the conversion cost because it executes after BigInt(). This issue is fixed in version 5.0.1.

Source published

Oct 21, 2026, 8:32:54 PM (timezone not stated)

Source modified

Oct 30, 2026, 2:30:11 PM (timezone not stated)

Observed here

7 Nov 2026 04:36:02 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

toml-node is a TOML parser for Node.js and the browser. Prior to 5.0.1, toml.parse() passes unbounded hexadecimal, octal, binary, and decimal digit sequences from lib/parser.js to BigInt() before reduceInteger() in lib/compiler.js checks whether the resulting value fits the TOML 64-bit integer range. Converting a sufficiently long integer string consumes super-linear CPU time and synchronously blocks the Node.js event loop, allowing one attacker-supplied TOML document to deny service to concurrent work in the process. The later range check cannot prevent the conversion cost because it executes after BigInt(). This issue is fixed in version 5.0.1.

Source published

21 Oct 2026 21:17:57 UTC

Source modified

30 Oct 2026 15:16:45 UTC

Observed here

31 Oct 2026 06:57:45 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

### Summary `toml.parse()` converts integer literals (hex, octal, binary, and decimal) to `BigInt` without first bounding the length of the digit sequence. Since `BigInt(string)` construction from a very long numeric string runs in super-linear time, a single small, well-formed TOML document containing one long integer literal can pin a Node.js process's event loop at 100% CPU for several seconds — a denial of service for any application that parses attacker-supplied or third-party TOML. No authentication or complex crafting is required. ### Details In `lib/parser.js`, the grammar actions that build integer nodes call `BigInt()` directly on the matched digit text, with no upper bound on its length: - `lib/parser.js:326` — hex: `BigInt('0x' + stripUnderscores(digits))` - `lib/parser.js:327` — octal: `BigInt('0o' + stripUnderscores(digits))` - `lib/parser.js:328` — binary: `BigInt('0b' + stripUnderscores(digits))` - `lib/parser.js:329` — decimal: `BigInt(stripUnderscores(text))` The parser does enforce a nesting-depth limit (`MAX_DEPTH`, default 500, `lib/parser.js:4343`) to guard against stack overflow from deeply nested arrays/inline tables (per GHSA-82x6-q7mm-w9cf). However, that guard only bounds *structural nesting* — it does not bound the length of a single scalar token. The subsequent 64-bit range check in `lib/compiler.js` (`reduceInteger`, lines 143–150, comparing against `INT64_MIN` / `INT64_MAX` defined at lines 3–4) happens **after** the expensive `BigInt()` conversion has already completed. It therefore provides no protection against this cost — the CPU time is already spent by the time the value is rejected as out of range. ### PoC ```js const toml = require('toml'); const N = 5_000_000; // ~5 MB request body const doc = 'x = 0x' + 'f'.repeat(N); const start = Date.now(); try { toml.parse(doc); // eventually throws "outside the 64-bit signed integer range" — // but only after the costly conversion has run } catch (e) {} console.log('elapsed:', Date.now() - start, 'ms'); ``` **Measured results:** | Digits (hex) | Approx. payload size | Parse time | |---:|---:|---:| | 200,000 | ~200 KB | 141 ms | | 400,000 | ~400 KB | 276 ms | | 800,000 | ~800 KB | 685 ms | | 1,600,000 | ~1.6 MB | 1,761 ms | | 5,000,000 | ~5 MB | 6,061 ms | Growth is clearly super-linear. The same behavior reproduces for plain decimal literals (3,000,000 `'9'` digits → ~6.3 s). ### Impact Any application that calls `toml.parse()` on untrusted or third-party input — config upload endpoints, CI/CD tools ingesting user-supplied `.toml` files, package managers, linters, editors/language servers — is exposed. During the conversion, the event loop is fully blocked. In a typical single-threaded Node.js server this stalls **all** concurrent request handling, not just the request containing the malicious payload. A single ~5 MB request is sufficient to cause several seconds of full CPU denial of service. **Suggested fix:** Reject digit sequences above a reasonable length *before* calling `BigInt()`, analogous to the existing `maxDepth` option. A 64-bit signed integer requires at most 20 decimal digits or 16 hex digits, so any digit sequence significantly longer than that is guaranteed to fail the existing range check anyway, and can be rejected with a cheap `.length` comparison instead of paying for the full `BigInt` conversion.

Source published

22 Oct 2026 16:36:50 UTC

Source modified

22 Oct 2026 16:45:03 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Publisher rating · HIGH