js‑toml uses a hand‑written parseBigInt loop that multiplies a BigInt accumulator by the radix for each input digit. Each multiplication grows with the size of the accumulator, so the total cost is quadratic in the literal length. The lexer regex imposes no upper bound on literal length, allowing an attacker to supply a very long hexadecimal, octal or binary literal that forces the parser to perform an enormous number of BigInt multiplications. A single request containing such a literal can tie a CPU core for dozens of seconds, effectively bringing a Node.js process to a halt. This uncontrolled CPU consumption results in a denial‑of‑service attack.

The affected product is the js‑toml TOML parser library maintained by sunnyadn. Versions up to and including 1.1.1 are vulnerable; version 1.1.2 contains 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, build tools or services that ingest third‑party *.toml files—may be exposed to this CPU‑exhaustion denial‑of‑service attack.

The vulnerability has a CVSS score of 7.5, indicating high severity. EPSS is < 1%, 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 a single crafted request can trigger the denial‑of‑service, 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.