CVE-2026-104874: 
Python vulnerability analysis and mitigation

CVE-2026-104874 is a reference leak vulnerability in the C extension of the multidict library (aio-libs/multidict) that allows unauthenticated remote attackers to cause unbounded process memory growth, leading to denial of service. It affects multidict versions >= 6.7.0 and <= 6.9.0; the pure-Python build is not affected. The vulnerability was published on September 21, 2026, and fixed in version 6.9.1. It carries a CVSS v3.1 base score of 5.3 (Medium) (Github Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-401 (Missing Release of Memory after Effective Lifetime) and CWE-911 (Improper Update of Reference Count). In multidict/_multilib/views.h, the multidict_itemsview_or2_impl (reflected union: operand | d.items()) and multidict_itemsview_sub1_impl (subtraction: d.items() - operand) functions call _multidict_itemsview_parse_item(), which returns new strong references for both identity (via md_calc_identity()) and value (via Py_NewRef()). The loop body calls only Py_CLEAR(arg) to release the tuple wrapper, but never releases identity or value; on the next iteration these variables are overwritten, permanently losing the previous references. This regression was introduced in 6.7.0 when a key-identity ownership change in hashtable.h made md_calc_identity() return a fresh strong reference that the unchanged parse loop never releases. All sibling paths (and1_impl, and2_impl, or1_impl) correctly clear all three references per iteration. The fix (commit 350b4a0) adds Py_CLEAR(identity); Py_CLEAR(value); after Py_CLEAR(arg) in both affected loops (Github Advisory, Patch Commit).

Exploitation results in an availability-only impact: no confidentiality or integrity loss occurs, and operation results remain correct. An unauthenticated remote attacker can cause the server process's resident memory to grow monotonically and without bound — PoC evidence shows RSS climbing from 15.6 MB to 1,266.8 MB (~250 MB per 2 million operand elements) despite forced garbage collection, which cannot reclaim the leaked objects. In the aio-libs stack, multidict backs HTTP headers and query strings, so any long-lived server application performing items-view union or subtraction over attacker-supplied data is at risk of process termination due to out-of-memory conditions (Github Advisory).

Proof-of-concept exploit code is publicly available in the security advisory itself, comprising three standalone Python scripts (poc_refcount.py, poc_dispatch.py, poc_rss.py) that demonstrate the memory leak via direct library calls. The vulnerability requires no authentication, no user interaction, and is network-reachable with low attack complexity. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.297% (21st percentile), and the vulnerability is not listed in the CISA KEV catalog (Github Advisory, Feedly).

1. Reconnaissance: Identify target applications using the multidict C extension (versions 6.7.0–6.9.0), particularly aiohttp-based or other aio-libs-stack servers that process HTTP headers or query strings and perform items-view set operations.
2. Craft large operand: Construct an HTTP request with many repeated header items or query string parameters (e.g., many Cookie headers or repeated query parameters), each becoming a (key, value) tuple in the operand list passed to the items-view operator.
3. Trigger reflected union or subtraction: Send the crafted request to an endpoint where the application evaluates operand | d.items() (reflected union, routes to or2_impl) or d.items() - operand (subtraction, routes to sub1_impl) over the attacker-influenced sequence of 2-tuples.
4. Leak references per element: Each element in the operand causes _multidict_itemsview_parse_item() to allocate new strong references for identity and value that are never released; two objects leak per element.
5. Repeat with fresh large operands: Repeatedly send requests with large operands (e.g., 50,000-element operands over 200 iterations = 10 million leaked objects), as each operation compounds the unreclaimable memory growth.
6. Exhaust process memory: RSS grows monotonically (demonstrated: 15.6 MB → 1,266.8 MB); forced GC cannot reclaim the leaked objects, eventually causing the server process to be killed by the OS OOM killer, achieving denial of service (Github Advisory).

• Process: Monotonically increasing RSS/memory usage of the Python server process that does not decrease even after garbage collection cycles; process eventually terminated by OOM killer.
• Logs: Application logs showing repeated processing of requests with unusually large numbers of header items or query string parameters; OOM kill events in system logs (/var/log/syslog, dmesg, or journalctl) referencing the Python/aiohttp process.
• Network: High volume of HTTP requests with abnormally large numbers of repeated headers (e.g., many Cookie: or custom header lines) or query parameters targeting the same endpoint from one or few source IPs.
• System: Kernel OOM killer events (oom_kill_process) in system logs attributing memory exhaustion to the affected Python process (Github Advisory).

Upgrade multidict to version 6.9.1 or later, which adds the missing Py_CLEAR(identity); Py_CLEAR(value); calls in both affected loop bodies (commit 350b4a0) (Release Notes, Patch Commit). If immediate patching is not possible, two workarounds are available: (1) avoid performing operand | view.items() or view.items() - operand operations on attacker-influenced operands in application code; or (2) install multidict with the environment variable MULTIDICT_NO_EXTENSIONS=1 to force the pure-Python build, which is not affected by this reference leak (Github Advisory).

The vulnerability was reported by researcher waydeshi and fixed by asvetlov (a core aio-libs maintainer) in the same release cycle. Red Hat tracked the issue as medium severity in their Bugzilla system with a broad CC list of 75 users, indicating significant downstream interest across Red Hat product lines. No notable independent researcher commentary or major media coverage has been identified beyond standard vulnerability database aggregation.