<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-05T05:53:19.820122+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/cve-2026-12590</id>
    <title>CVE-2026-12590 — body-parser vulnerable to denial of service when invalid limit value silently disables size enforcement</title>
    <updated>2026-10-05T05:53:20.184583+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> body-parser</p>
<p>Impact: In body-parser versions prior to 1.20.6 (1.x line) and 2.3.0 (2.x line), when the parser is configured with an invalid limit option value such as an unparseable string or NaN, bytes.parse returns null and the request body size check is silently skipped. Applications that rely on limit as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service. Patches: This issue is fixed in body-parser 1.20.6 and 2.3.0. After the fix, invalid limit values throw a clear error at parser construction time instead of silently disabling enforcement, while null and undefined continue to fall back to the default limit of 100kb. Workarounds: Validate the limit value before passing it to body-parser. For example, parse the value at startup and reject any configuration where the result is null or a non-finite number.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-12590"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-2v35-w6hq-6mfw</id>
    <title>GHSA-2v35-w6hq-6mfw — xmldom: Uncontrolled recursion in XML serialization leads to DoS</title>
    <updated>2026-10-05T05:53:20.184672+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: @xmldom/xmldom, npm: xmldom</p>
<p>## Summary</p>
<p>Seven recursive traversals in `lib/dom.js` operate without a depth limit. A sufficiently deeply
nested DOM tree causes a `RangeError: Maximum call stack size exceeded`, crashing the application.</p>
<p>**Reported operations:**
- `Node.prototype.normalize()` — reported by @praveen-kv (email 2026-04-05) and @KarimTantawey (GHSA-fwmp-8wwc-qhv6, via `DOMParser.parseFromString()`)
- `XMLSerializer.serializeToString()` — reported by @Jvr2022 (GHSA-2v35-w6hq-6mfw) and @KarimTantawey (GHSA-j2hf-fqwf-rrjf)</p>
<p>**Additionally, discovered in research:**
- `Element.getElementsByTagName()` / `getElementsByTagNameNS()` / `getElementsByClassName()` / `getElementById()`
- `Node.cloneNode(true)`
- `Document.importNode(node, true)`
- `node.textContent` (getter)
- `Node.isEqualNode(other)`</p>
<p>All seven share the same root cause: pure-JavaScript recursive tree traversal with no depth guard.
A single deeply nested document (parsed successfully) triggers any or all of these operations.</p>
<p>---</p>
<p>## Details</p>
<p>### Root cause</p>
<p>`lib/dom.js` implements DOM tree traversals as depth-first recursive functions. Each level of
element nesting adds one JavaScript call frame. The JS engine's call stack is finite; once
exhausted, a `RangeError: Maximum call stack size exceeded` is thrown. This error may not be
caught reliably at stack-exhaustion depths because the catch handler itself requires stack
frames to execute — especially in async scenarios, where an uncaught `RangeError` inside a
callback or promise chain…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-2v35-w6hq-6mfw"/>
  </entry>
</feed>
