Quadratic-time parsing in smol-toml parse() enables denial of service
Key facts
- Attack vector
- —
- Privileges required
- —
- User interaction
- —
- Attack complexity
- —
- Impact type
- Denial of service
- Confidentiality · integrity · availability
- —
- Fix status
- Fixed
No CVSS vector from any source. Fix status from GitHub. Impact type from CWE-407.
Summary
smol-toml before 1.9.0 has a quadratic-time path in its parse() function. The parseKey function searches the whole document for a dotted-key separator on every key and table-header line, so a document with many dot-free keys takes time that grows with the square of its length (CWE-407). An attacker who can supply TOML to a service that calls parse() with default options can make it run for a long time and block the event loop, with a body of about 7 MB pinning a CPU core for about a minute.
Written with Claude Haiku 5.5 from the sources below · 2026-10-29
Description from the GitHub advisory
### Summary `parse()` has a quadratic-time path in `parseKey`, reachable on default options with ordinary valid input. For every key line and table-header line, `parseKey` (dist/struct.js, lines 58 and 86) finds the dotted-key separator with `ctx.s.indexOf('.', ctx.p)`, where `ctx.s` is the whole document. When a key has no `.` ahead of it, that search runs all the way to the end of the input, and the result is then clamped back to the line terminator `endPtr` - so everything scanned past the current line is wasted. `parseKey` runs once per line, so a document of N dot-free keys costs O(n^2). The most ordinary TOML shape triggers it: a flat list of `key = value` lines, or a repeated `[[a]]` table. No dotted keys, no special options, valid input throughout. ### Proof of concept ```js import { parse } from 'smol-toml' let doc = '' for (let i = 0; i < 256000; i++) doc += 'k' + i + ' = 1\n' console.time('parse') parse(doc) // ~2.8 MB of valid TOML, default options console.timeEnd('parse') ``` Doubling the line count roughly quadruples the time: | lines | size | parse() | |---|---|---| | 32k | 0.3 MB | 0.3 s | | 64k | 0.7 MB | 1.0 s | | 128k | 1.4 MB | 3.5 s | | 256k | 2.8 MB | 14 s | ### Impact Any service that runs `parse()` on attacker-supplied TOML can be stalled. The work is synchronous, so it blocks the whole event loop, and the quadratic is unbounded: a ~7 MB body pins a core for about a minute, larger bodies for several. ### Patches Version 1.9.0 uses a different implementation for parsing keys which is strictly linear. ### Workarounds Limit the maximum document size accepted when parsing arbitrary documents.
Why it matters now
SSVC decision points
Not available: CISA has not published SSVC decision points for this record.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| — | smol-toml (npm) | before 1.9.0 | 1.9.0 | Patch available | GHSA-r4xh-jqrq-34v2 |
- smol-toml (npm) Vendor— Affected before 1.9.0 Fixed in 1.9.0 Patch available GHSA-r4xh-jqrq-34v2
Remediation
Upgrade smol-toml to version 1.9.0, which parses keys with a linear implementation. Until then, limit the maximum document size accepted when parsing untrusted TOML.
Written with Claude Haiku 5.5 from the sources below · 2026-10-29
- Fix · GHSA-r4xh-jqrq-34v2 smol-toml (npm) Fixed in 1.9.0 Advisory →
Timeline
- 2026-10-06 Threatist record created from GHSA-r4xh-jqrq-34v2
References
Sources
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences