The vulnerability arises when js‑toml parses radix‑prefixed integer literals. Its hand‑written BigInt parser multiplies the accumulator by the radix for each digit, making the total cost quadratic in the literal length. An attacker can supply a very long hexadecimal, octal, or binary literal in a TOML document, causing the parser to perform a quadratic number of BigInt multiplications and saturate a CPU core. The result is a single‑request CPU‑exhaustion denial‑of‑service that can render a node process unresponsive. The weakness maps to CWE‑1333 (Excessive CPU Usage), CWE‑400 (Uncontrolled Resource Consumption), and CWE‑407 (Inefficient Algorithm).

The affected product is the js‑toml TOML parser library maintained by sunnyadn. Versions up to and including 1.1.0 (inclusive) are vulnerable, while version 1.1.1 introduces the fix. Any JavaScript runtime that loads vulnerable toml via the library’s load() function—such as configuration upload endpoints, CI/CD pipelines, IDE plugins, or build tools that parse third‑party *.toml files—may be exposed.

The vulnerability has a CVSS score of 7.5, indicating high severity. EPSS is not available, and the flaw is not listed in the CISA KEV catalog. The most likely attack vector is remote, where an attacker can supply malicious TOML payloads to a service that uses js‑toml. Because the DoS can be triggered with a single crafted request, an adversary with network access to a vulnerable service can easily exhaust CPU resources. The impact is limited to availability and can be mitigated by updating the library. When that is not possible, the attacker can still exploit the quadratic cost by sending large literals.