<?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://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T08:52:28.448804+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" 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://vulnerability.circl.lu/vuln/cve-2026-13697</id>
    <title>CVE-2026-13697 — undici vulnerable to cross-user information disclosure and parse-time crash via degenerate private cache directives</title>
    <updated>2026-09-28T08:52:28.459222+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> undici</p>
<p>undici's cache interceptor mishandles malformed Cache-Control private directives. In undici 7.0.0 up to before 7.29.0 and 8.0.0 up to before 8.9.0, a response carrying a degenerate qualified private directive, such as private set to an empty value, can be stored in the default shared cache and later served to a different caller with the same cache key, disclosing private response bodies and headers including Set-Cookie. Separately, a Cache-Control header that combines an unqualified private directive with a qualified one triggers an uncaught TypeError in the cache-control parser, which rejects the request and, depending on the consumer's error handling, can terminate the process. Both issues affect applications using the cache interceptor in shared mode, including the default configuration. The issues are fixed in undici 7.29.0 and 8.9.0.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-13697"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-55q2-fjhq-7xh7</id>
    <title>GHSA-55q2-fjhq-7xh7 — DOMPurify: IN_PLACE hook removal leaves a detached subtree executable, causing XSS</title>
    <updated>2026-09-28T08:52:28.459289+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: dompurify</p>
<p>### Summary</p>
<p>During `IN_PLACE` sanitization, a hook that removes an element can leave that element's detached descendants executable. A descendant image can retain its attacker-provided `onload` handler and fire after `sanitize()` returns, even though the returned root is clean and the image remains disconnected from the document.</p>
<p>### Details</p>
<p>In DOMPurify 3.4.12, `_sanitizeElements()` in `src/purify.ts:1862-1904` runs the `beforeSanitizeElements` or `uponSanitizeElement` hook and returns immediately when the hook detached the current node. The return does not call `_neutralizeSubtree(currentNode)`.</p>
<p>The detached subtree is not added to `DOMPurify.removed`, so the post-walk `IN_PLACE` neutralization cannot reach it. If the browser queued a resource event while the application constructed the detached dirty root, a descendant can therefore retain its handler and execute after sanitization.</p>
<p>The hook only rejects the containing element and does not add or approve the event handler. DOMPurify's ordinary removal path de-arms the same queued event; only the hook-detachment early return skips the existing subtree neutralization.</p>
<p>### PoC</p>
<p>Load the published `dompurify@3.4.12` `dist/purify.js` before this script in Chromium:</p>
<p>```html
&lt;div id="result"&gt;not fired&lt;/div&gt;
&lt;script&gt;
const root = document.createElement('div');
root.innerHTML = `
  &lt;footer&gt;
    &lt;img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7"
         onload="result.textContent = 'XS…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-55q2-fjhq-7xh7"/>
  </entry>
</feed>
