CVE-2026-114144

### 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) {} con