<?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-11-15T07:50:53.435836+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/cve-2026-119235</id>
    <title>CVE-2026-119235</title>
    <updated>2026-11-15T07:50:53.441144+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Facebook proxygen</p>
<p>proxygen's QPACK decoder enforced its size limit on a string literal in an encoder-stream instruction only after the entire literal had been received. A remote, unauthenticated HTTP/3 peer could send an insert instruction on the QPACK encoder stream that declares an arbitrarily large literal and then keep sending data, causing the decoder to buffer it without bound for the lifetime of the connection and exhaust memory, leading to denial of service. The issue occurs regardless of the advertised QPACK dynamic table capacity, including when the dynamic table is disabled. This issue affects proxygen versions prior to v2026.11.09.00.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-119235"/>
  </entry>
</feed>
