CVE-2026-49293: sunnyadn js-toml · Uncontrolled Resource Consumption
Affects sunnyadn js-tomlSource CVE Database V5
Not known to be exploited · CVSS 7.5 High : upgrade to 1.1.1 soon.
Data as of 1 Nov 2026, 22:58 UTC
- EPSS
- 0.6% chance of exploitation in 30 days – higher than 50% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 1.1.1
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 1 Nov 2026.
What to do
Upgrade sunnyadn js-toml to 1.1.1.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| sunnyadnjs-toml | Affected
| Fixed in
|
npmjs-tomlpkg:npm/js-tomlOther threats | 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
Upgrade js-toml to version 1.1.1 or later, where this vulnerability is fixed. Until then, avoid processing untrusted TOML inputs or implement input size restrictions on integer literals to mitigate CPU exhaustion. Patch status is not explicitly stated in the vendor advisory, but version 1.1.1 is confirmed to fix the issue.
Description
js-toml is a TOML parser for JavaScript, fully compliant with the TOML 1.0.0 Spec. Versions up to and including 1.1.0 parse hexadecimal / octal / binary integer literals via a hand-written `parseBigInt` loop that multiplies a `BigInt` accumulator by the radix once per input digit. Each iteration performs a `BigInt * BigInt` operation on an accumulator that grows linearly with the number of digits already consumed, so the whole loop is O(n²) in the literal length. The lexer regex places no upper bound on the literal length, so a single TOML document containing one ~500 kB hex literal pins one CPU core for ~40 seconds on a modern laptop (Apple M-series, Node v22). Memory amplification is bounded but CPU amplification is severe and grows quadratically: doubling the literal length quadruples the work. A caller that invokes `load()` on attacker-controlled TOML (configuration upload endpoints, CI/CD systems ingesting third-party `*.toml`, IDE plugins, build tools) is exposed to a single-request CPU exhaustion DoS. Version 1.1.1 fixes the issue.