<?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-22T19:50:04.799460+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-114144</id>
    <title>fkie_cve-2026-114144</title>
    <updated>2026-10-22T19:50:04.818383+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() passes unbounded hexadecimal, octal, binary, and decimal digit sequences from lib/parser.js to BigInt() before reduceInteger() in lib/compiler.js checks whether the resulting value fits the TOML 64-bit integer range. Converting a sufficiently long integer string consumes super-linear CPU time and synchronously blocks the Node.js event loop, allowing one attacker-supplied TOML document to deny service to concurrent work in the process. The later range check cannot prevent the conversion cost because it executes after BigInt(). This issue is fixed in version 5.0.1.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-114144"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-9qmh-m7c6-f92p</id>
    <title>GHSA-9qmh-m7c6-f92p — toml-node: Uncontrolled resource consumption (CPU DoS) via unbounded-length integer literals in toml.parse()</title>
    <updated>2026-10-22T19:50:04.818458+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: toml</p>
<p>### Summary
`toml.parse()` converts integer literals (hex, octal, binary, and decimal) to `BigInt` without first bounding the length of the digit sequence. Since `BigInt(string)` construction from a very long numeric string runs in super-linear time, a single small, well-formed TOML document containing one long integer literal can pin a Node.js process's event loop at 100% CPU for several seconds — a denial of service for any application that parses attacker-supplied or third-party TOML. No authentication or complex crafting is required.</p>
<p>### Details
In `lib/parser.js`, the grammar actions that build integer nodes call `BigInt()` directly on the matched digit text, with no upper bound on its length:</p>
<p>- `lib/parser.js:326` — hex: `BigInt('0x' + stripUnderscores(digits))`
- `lib/parser.js:327` — octal: `BigInt('0o' + stripUnderscores(digits))`
- `lib/parser.js:328` — binary: `BigInt('0b' + stripUnderscores(digits))`
- `lib/parser.js:329` — decimal: `BigInt(stripUnderscores(text))`</p>
<p>The parser does enforce a nesting-depth limit (`MAX_DEPTH`, default 500, `lib/parser.js:4343`) to guard against stack overflow from deeply nested arrays/inline tables (per GHSA-82x6-q7mm-w9cf). However, that guard only bounds *structural nesting* — it does not bound the length of a single scalar token.</p>
<p>The subsequent 64-bit range check in `lib/compiler.js` (`reduceInteger`, lines 143–150, comparing against `INT64_MIN` / `INT64_MAX` defined at lines 3–4) happens **after** the expensive `BigInt()` co…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-9qmh-m7c6-f92p"/>
  </entry>
</feed>
