<?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-10-20T06:44:34.289468+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/fkie_cve-2026-109829</id>
    <title>fkie_cve-2026-109829</title>
    <updated>2026-10-20T06:44:34.309346+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>undici is an HTTP client library for Node.js. In versions 7.0.0 through 7.30.0 and 8.0.0 through 8.12.1, when an originless Agent composes the redirect and cache interceptors in that order with a shared cache store, the cache builds its key from the original request URL before the redirect handler changes the origin, so a response produced after a cross-origin redirect is stored under the original key. An attacker who controls the target of a redirect from a trusted URL can have their response cached under that trusted URL and served to later callers, allowing persistent cache poisoning, and the same key confusion lets a private, non-stored redirect response to a user-specific resource be stored under the original URL and served to a later unauthenticated caller, disclosing private data. Applications are affected only when an originless Agent, a shared cache store, and the redirect-then-cache composition are all used. The issue is fixed in undici 7.30.1 and 8.12.2, which verify the producing origin still matches the cache key and preserve each redirect hop's cache-control policy before storing, and users should upgrade to one of those versions or later. As a workaround, compose the cache interceptor before the redirect interceptor, use per-origin dispatchers and cache stores, or disable shared caching on redirect-capable requests.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-109829"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/rhsa-2026:84657</id>
    <title>RHSA-2026:84657 — Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update</title>
    <updated>2026-10-20T06:44:34.309433+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>undici: undici: Denial of Service via TLS renegotiation with mismatched certificate undici: undici: Denial of Service via unhandled exception in decompress interceptor brace-expansion: brace-expansion: Denial of Service via stack exhaustion from crafted brace patterns undici: undici: Certificate validation bypass via dropped TLS options in Agent undici: undici: Cache poisoning and information disclosure via improper cross-origin redirect caching undici: undici: Subresource Integrity bypass via non-lowercase algorithm tokens undici: undici: Denial of Service via unhandled stream error on excessive content encodings undici: undici: Denial of Service via memory exhaustion in EventSource client undici: undici: Denial of Service via unbounded WebSocket PONG buffering</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/rhsa-2026:84657"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-109829</id>
    <title>UBUNTU-CVE-2026-109829</title>
    <updated>2026-10-20T06:44:34.309484+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:24.04:LTS: node-undici, Ubuntu:26.10: node-undici, Ubuntu:26.04:LTS: node-undici</p>
<p>undici is an HTTP client library for Node.js. In versions 7.0.0 through 7.30.0 and 8.0.0 through 8.12.1, when an originless Agent composes the redirect and cache interceptors in that order with a shared cache store, the cache builds its key from the original request URL before the redirect handler changes the origin, so a response produced after a cross-origin redirect is stored under the original key. An attacker who controls the target of a redirect from a trusted URL can have their response cached under that trusted URL and served to later callers, allowing persistent cache poisoning, and the same key confusion lets a private, non-stored redirect response to a user-specific resource be stored under the original URL and served to a later unauthenticated caller, disclosing private data. Applications are affected only when an originless Agent, a shared cache store, and the redirect-then-cache composition are all used. The issue is fixed in undici 7.30.1 and 8.12.2, which verify the producing origin still matches the cache key and preserve each redirect hop's cache-control policy before storing, and users should upgrade to one of those versions or later. As a workaround, compose the cache interceptor before the redirect interceptor, use per-origin dispatchers and cache stores, or disable shared caching on redirect-capable requests.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-109829"/>
  </entry>
</feed>
