Skip to main content
VulnerabilityPublished Updated

CVE-2026-49293: sunnyadn js-toml · Uncontrolled Resource Consumption

Affects sunnyadn js-tomlSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 7.5 High : upgrade to 1.1.1 soon.

Data as of 1 Nov 2026, 22:58 UTC

CVSS 3.1 base score
7.5High
How severe the flaw is on the 0–10 CVSS scale.
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:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 19 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
sunnyadnjs-tomlAffected
  • <1.1.1
Fixed in
  • 1.1.1
npmjs-tomlpkg:npm/js-tomlOther threatsAffected
  • <=1.1.0
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.

References

Community reviews

Loading reviews…