<?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-11T00:52:43.513556+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-123817</id>
    <title>CVE-2026-123817 — AIOHTTP WebSocket frame reassembly permits excessive memory consumption from tiny reads</title>
    <updated>2026-11-11T00:52:43.515528+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> aio-libs aiohttp</p>
<p>AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.4, the WebSocket reader retains one bytes object for each transport read while reassembling an incomplete frame. A malicious peer can split a frame into many tiny reads so per-object overhead substantially exceeds the payload bytes allowed by max_msg_size. The condition affects a server receiving frames from a malicious client and a client receiving frames from a malicious server, and can cause excessive memory consumption or denial of service. This issue is fixed in version 3.14.4.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-123817"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-2g87-pp6c-29x5</id>
    <title>GHSA-2g87-pp6c-29x5 — aiohttp: Multiple instances of excessive or unbounded memory/CPU use</title>
    <updated>2026-11-11T00:52:43.515619+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: aiohttp</p>
<p>### Summary</p>
<p>While reassembling a WebSocket frame that arrived across many small transport reads, the reader kept one `bytes` object per read with no bound on the count. The per-object overhead is many times larger than the payload bytes, so a frame delivered a few bytes at a time could use far more memory than `max_msg_size` allows.</p>
<p>### Impact</p>
<p>An attacker could cause excessive memory use in a WebSocket server, or a malicious server against a client, by sending a frame in a large number of tiny segments.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-2g87-pp6c-29x5"/>
  </entry>
</feed>
