<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-22T21:36:51.563411+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-114143</id>
    <title>fkie_cve-2026-114143</title>
    <updated>2026-10-22T21:36:51.578009+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>toml-node is a TOML parser for Node.js and the browser. Prior to 5.0.1, toml.parse() repeatedly slices and rejoins every path prefix in lib/compiler.js while processing long dotted keys, table headers, array-of-tables headers, and inline-table keys in assign(), deepRef(), and setNestedKey(). The resulting quadratic work can block the Node.js event loop for several seconds, and sufficiently long paths can terminate the process through memory exhaustion. The maxDepth option does not limit key-segment count and therefore does not mitigate this path. This issue is fixed in version 5.0.1.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-114143"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-9j65-hcg3-gc64</id>
    <title>GHSA-9j65-hcg3-gc64 — toml-node: Quadratic-complexity DoS via long dotted keys or table paths in toml.parse()</title>
    <updated>2026-10-22T21:36:51.578100+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: toml</p>
<p>## Summary</p>
<p>`toml.parse()` is vulnerable to a quadratic-complexity (O(n²)) denial-of-service via a single
long dotted key, table header, or inline-table key. A ~100KB crafted document causes a
multi-second synchronous hang; a ~200KB document crashes the Node.js process outright with an
uncatchable out-of-memory error. This is a separate, unpatched code path from the previously
fixed stack-overflow DoS (`GHSA-82x6-q7mm-w9cf`) — it requires no array/inline-table nesting at
all, and is confirmed unaffected by the `maxDepth` option that fixed that earlier issue.</p>
<p>## Affected component / version</p>
<p>- Package: `toml` (npm), repository `BinaryMuse/toml-node`
- Functions: `assign()`, `deepRef()`, `setNestedKey()` in `lib/compiler.js`
- Confirmed present in the audited checkout at commit `1b2ac40` (2026-07-16), one commit past
  the `v5.0.0` tag (a changelog-only change) — i.e. present in `v5.0.0`, the latest release.
  Not exhaustively verified against every prior release, but the affected functions are
  unrelated to `v5.0.0`'s BigInt/Temporal changes (per `CHANGELOG.md`), so the defect likely
  predates that release as well.</p>
<p>## Details</p>
<p>`toml.parse(input, options)` (`index.js:5-9`) forwards the caller-supplied string to
`parser.parse()` and then `compiler.compile()` with no length or structural validation.
Inside `lib/compiler.js`, three separate functions each walk a dotted key's segments in a
`for` loop and, on **every** iteration, recompute the full path-prefix string from scrat…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-9j65-hcg3-gc64"/>
  </entry>
</feed>
