CVE-2026-49293: js-toml vulnerable to CPU exhaustion via O(n^2) BigInt construction on radix-prefixed integer literals
Affects js-tomlSource GCVE Database
Not known to be exploited · CVSS 7.5 High : upgrade to 1.1.2 soon.
Data as of 4 Nov 2026, 04:16 UTC
Thin evidence
One scorer or none| CNA (GitHub_M) | CVSS 3.1 | 7.5 |
|---|
- Patch
- Available – fixed in 1.1.2
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 19 Jun 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 3 Nov 2026.
What to do
Upgrade js-toml to 1.1.2.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| npmjs-toml | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
A fix is available in js-toml version 1.1.2. Users should upgrade to version 1.1.2 or later to resolve this CPU exhaustion vulnerability. Until upgraded, applications should restrict the size of TOML inputs or avoid processing untrusted TOML documents with the load() function. No other configuration or options are required to trigger or mitigate the issue.
Description
js-toml versions up to and including 1.1.0 contain a vulnerability in the parsing of radix-prefixed integer literals (hexadecimal, octal, binary) where a quadratic time complexity in BigInt construction can cause CPU exhaustion. The parser's loop multiplies a BigInt accumulator by the radix for each digit, resulting in O(n²) complexity with respect to the literal length. There is no upper bound on the length of these literals, allowing an attacker to craft a single large literal (~500 kB) that can pin a CPU core for about 40 seconds, causing a denial of service. This affects any use of the load() function on attacker-controlled TOML input. The issue is fixed in version 1.1.2.
References
- github.com/sunnyadn/js-toml/security/advisories/GHSA-wp3c-266w-4qfq (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-49293 (opens in a new tab)
- github.com/sunnyadn/js-toml/commit/1e45ca56ba12e98508f8aae3e31c4aff7603d711 (opens in a new tab)
- github.com/sunnyadn/js-toml (opens in a new tab)
- github.com/sunnyadn/js-toml/releases/tag/v1.1.2 (opens in a new tab)