GHSA-9QMH-M7C6-F92P
Vulnerability from github – Published: 2026-10-22 16:36 – Updated: 2026-10-22 16:36Summary
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
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.0.0"
},
"package": {
"ecosystem": "npm",
"name": "toml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-114144"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-22T16:36:50Z",
"nvd_published_at": "2026-10-21T21:17:57Z",
"severity": "HIGH"
},
"details": "### Summary\n`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\u0027s event loop at 100% CPU for several seconds \u2014 a denial of service for any application that parses attacker-supplied or third-party TOML. No authentication or complex crafting is required.\n\n### Details\nIn `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:\n\n- `lib/parser.js:326` \u2014 hex: `BigInt(\u00270x\u0027 + stripUnderscores(digits))`\n- `lib/parser.js:327` \u2014 octal: `BigInt(\u00270o\u0027 + stripUnderscores(digits))`\n- `lib/parser.js:328` \u2014 binary: `BigInt(\u00270b\u0027 + stripUnderscores(digits))`\n- `lib/parser.js:329` \u2014 decimal: `BigInt(stripUnderscores(text))`\n\nThe 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* \u2014 it does not bound the length of a single scalar token.\n\nThe subsequent 64-bit range check in `lib/compiler.js` (`reduceInteger`, lines 143\u2013150, comparing against `INT64_MIN` / `INT64_MAX` defined at lines 3\u20134) happens **after** the expensive `BigInt()` conversion has already completed. It therefore provides no protection against this cost \u2014 the CPU time is already spent by the time the value is rejected as out of range.\n\n### PoC\n\n```js\nconst toml = require(\u0027toml\u0027);\n\nconst N = 5_000_000; // ~5 MB request body\nconst doc = \u0027x = 0x\u0027 + \u0027f\u0027.repeat(N);\n\nconst start = Date.now();\ntry {\n toml.parse(doc); // eventually throws \"outside the 64-bit signed integer range\" \u2014\n // but only after the costly conversion has run\n} catch (e) {}\n\nconsole.log(\u0027elapsed:\u0027, Date.now() - start, \u0027ms\u0027);\n```\n\n**Measured results:**\n\n| Digits (hex) | Approx. payload size | Parse time |\n|---:|---:|---:|\n| 200,000 | ~200 KB | 141 ms |\n| 400,000 | ~400 KB | 276 ms |\n| 800,000 | ~800 KB | 685 ms |\n| 1,600,000 | ~1.6 MB | 1,761 ms |\n| 5,000,000 | ~5 MB | 6,061 ms |\n\nGrowth is clearly super-linear. The same behavior reproduces for plain decimal literals (3,000,000 `\u00279\u0027` digits \u2192 ~6.3 s).\n\n### Impact\nAny application that calls `toml.parse()` on untrusted or third-party input \u2014 config upload endpoints, CI/CD tools ingesting user-supplied `.toml` files, package managers, linters, editors/language servers \u2014 is exposed.\n\nDuring 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.\n\n**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.",
"id": "GHSA-9qmh-m7c6-f92p",
"modified": "2026-10-22T16:36:50Z",
"published": "2026-10-22T16:36:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/BinaryMuse/toml-node/security/advisories/GHSA-9qmh-m7c6-f92p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114144"
},
{
"type": "WEB",
"url": "https://github.com/BinaryMuse/toml-node/commit/9d52e384f6030932174d1afb0d910154dd62dead"
},
{
"type": "PACKAGE",
"url": "https://github.com/BinaryMuse/toml-node"
},
{
"type": "WEB",
"url": "https://github.com/BinaryMuse/toml-node/releases/tag/v5.0.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "toml-node: Uncontrolled resource consumption (CPU DoS) via unbounded-length integer literals in toml.parse()"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.