---
id: "CVE-2026-114144"
kind: "vulnerability"
aliases: ["CVE-2026-114144", "GHSA-9qmh-m7c6-f92p"]
title: "toml-node: Uncontrolled resource consumption (CPU DoS) via unbounded-length integer literals in toml.parse()"
severity: "high"
cvss: 7.5
epss: 0.003389999968931079
exploited: false
status: "open"
category: "package"
products: [{"name": "toml", "fixed": ["5.0.1"], "affected": "<= 5.0.0", "ecosystem": "npm"}]
ecosystems: ["npm"]
tags: ["cwe-400", "cwe-770", "node.js", "npm", "package", "self-hosted", "toml"]
not_affected_if: ["managed-hosting", "parses-only-trusted-toml", "toml-version-above-5.0.0"]
published_at: "2026-10-21T21:17:57+00:00"
first_seen_at: "2026-10-23T19:11:31+00:00"
updated_at: "2026-10-23T21:57:29+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-9qmh-m7c6-f92p", "first_seen_at": "2026-10-23T19:11:31+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114144", "first_seen_at": "2026-10-23T21:57:29+00:00"}]
---

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

The toml npm package converts integer literals to BigInt without bounding their length, so a single small TOML document with a very long integer literal can block the Node.js event loop for seconds. An attacker who can get the app to parse untrusted TOML can stall all concurrent request handling in a single-threaded process.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- npm:toml affected <= 5.0.0 fixed 5.0.1

## How to check

Run npm ls toml to find the installed version and check whether it is 5.0.0 or lower.
Search your code for require('toml') or import of the toml package to see whether it parses untrusted input.

## Fix

Upgrade the toml package to 5.0.1 or later.
If you cannot upgrade, reject TOML input from untrusted sources before calling toml.parse().

## Timeline

- 2026-10-23T19:11:31+00:00 ghsa https://github.com/advisories/GHSA-9qmh-m7c6-f92p
- 2026-10-23T21:57:29+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-114144

## From the sources

### 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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_