3vulnerabilities
- Critical0 (0.0%)
- High2 (66.7%)
- Medium0 (0.0%)
- Moderate1 (33.3%)
- Low0 (0.0%)
js-toml
Ecosystem: npm
Downloads: 164.45 K
- 0CriticalAffects 0 versions
- 2HighAffects 2 versions
- 0MediumAffects 0 versions
- 1ModerateAffects 1 version
- 0LowAffects 0 versions
Monthly breakdown
- Critical
- High
- Medium
- Moderate
- Low
- 2 vulnerabilities
- Critical: 0
- High: 1
- Medium: 0
- Moderate: 1
- Low: 0
- 1 vulnerabilities
- Critical: 0
- High: 1
- Medium: 0
- Moderate: 0
- Low: 0
Vulnerabilities (3)
Known vulnerabilities affecting js-toml, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-m34p-749j-x6m6 | Moderate | js-toml has silent type confusion via falsy-primitive duplicate-key bypass### Summary `js-toml`'s interpreter checks whether a key already exists in a parser-built container with `if (object[key])` instead of `if (key in object)`. When the prior value is a falsy primitive — `false`, `0`, `0n`, `0.0`, `-0`, or `""` — the duplicate-key branch is skipped and the value is silently overwritten by a later sub-table, dotted-key sub-table, or array-of-tables sharing the same name. Per the TOML 1.0.0 spec ("Defining a key multiple times is invalid"; "You cannot define any key or table more than once"), this should be a parse error. The result is **structural type confusion |
| GitHub (opens in a new tab) | |
| GHSA-wp3c-266w-4qfq | High | js-toml vulnerable to CPU exhaustion via O(n^2) BigInt construction on radix-prefixed integer literals## Summary `js-toml` 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 (A |
| GitHub (opens in a new tab) | |
| GHSA-65fc-cr5f-v7r2 | High | js-toml Prototype Pollution VulnerabilityA prototype pollution vulnerability in `js-toml` allows a remote attacker to add or modify properties of the global `Object.prototype` by parsing a maliciously crafted TOML input. ### Impact The `js-toml` library is vulnerable to Prototype Pollution. When parsing a TOML string containing the specially crafted key `__proto__`, an attacker can add or modify properties on the global `Object.prototype`. While the `js-toml` library itself does not contain known vulnerable "gadgets", this can lead to severe security vulnerabilities in applications that use the library. For example, if the consumi |
| GitHub (opens in a new tab) |
- GHSA-m34p-749j-x6m6Moderatejs-toml has silent type confusion via falsy-primitive duplicate-key bypass
< 1.1.2
### Summary `js-toml`'s interpreter checks whether a key already exists in a parser-built container with `if (object[key])` instead of `if (key in object)`. When the prior value is a falsy primitive — `false`, `0`, `0n`, `0.0`, `-0`, or `""` — the duplicate-key branch is skipped and the value is silently overwritten by a later sub-table, dotted-key sub-table, or array-of-tables sharing the same name. Per the TOML 1.0.0 spec ("Defining a key multiple times is invalid"; "You cannot define any key or table more than once"), this should be a parse error. The result is **structural type confusion
CVE: CVE-2026-50029
- GHSA-wp3c-266w-4qfqHighjs-toml vulnerable to CPU exhaustion via O(n^2) BigInt construction on radix-prefixed integer literals
< 1.1.2
## Summary `js-toml` 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 (A
CVE: CVE-2026-49293
A prototype pollution vulnerability in `js-toml` allows a remote attacker to add or modify properties of the global `Object.prototype` by parsing a maliciously crafted TOML input. ### Impact The `js-toml` library is vulnerable to Prototype Pollution. When parsing a TOML string containing the specially crafted key `__proto__`, an attacker can add or modify properties on the global `Object.prototype`. While the `js-toml` library itself does not contain known vulnerable "gadgets", this can lead to severe security vulnerabilities in applications that use the library. For example, if the consumi
CVE: CVE-2025-54803