CVE-2026-48045: 
Python vulnerability analysis and mitigation

CVE-2026-48045 is an unbounded TC-deferred queue vulnerability in python-zeroconf (the zeroconf pip package) that allows unauthenticated LAN-adjacent attackers to cause memory exhaustion and quadratic CPU burn via a spoofed-source mDNS flood. It affects all versions of zeroconf prior to 0.149.12. The vulnerability was disclosed by maintainer bdraco on May 21, 2026, with the fix merged the same day and the GitHub Advisory Database entry published on June 11, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) (Github Advisory, GHSA Security Advisory).

The root cause is uncontrolled resource consumption (CWE-400) and allocation without limits or throttling (CWE-770) in AsyncListener.handle_query_or_defer. When a truncated (TC-bit) mDNS query arrives, the method stores it in self._deferred[addr] and arms a per-address timer in self._timers[addr] per RFC 6762 §18.5, but neither the per-address list length nor the total number of distinct addr keys was capped. Each stored packet can be up to _MAX_MSG_ABSOLUTE = 8966 bytes, and the deduplication check (for incoming in reversed(deferred): if incoming.data == msg.data) runs O(N) over the growing per-address queue on every packet arrival, resulting in quadratic CPU cost. An attacker on the local link can stream byte-distinct TC-flagged UDP/5353 queries to the multicast address (224.0.0.251 / ff02::fb) and trivially spoof source IPs to multiply entries across _deferred and _timers, exhausting both memory and CPU (Github Advisory, Fix PR #1751).

Successful exploitation results in a denial-of-service condition with no confidentiality or integrity impact. On memory-constrained deployments — the canonical example being Home Assistant running on Raspberry Pi-class hardware — sustained flooding OOM-kills the zeroconf process. Under lighter load, event-loop scheduler starvation caused by the quadratic CPU burn disrupts unrelated zeroconf consumers including service discovery, registration, and ServiceBrowser callbacks. There is no lateral movement or data exfiltration risk; the impact is limited to availability of the affected process and any services depending on mDNS (Github Advisory, GHSA Security Advisory).

1. Gain LAN adjacency: Position on the same Layer-2 network segment as the target host running a vulnerable version of python-zeroconf (< 0.149.12), or gain access to a host on that segment.
2. Craft TC-flagged mDNS queries: Generate byte-distinct mDNS query packets with the TC (truncation) bit set, each up to 8966 bytes, targeting UDP port 5353 and the multicast address 224.0.0.251 (IPv4) or ff02::fb (IPv6). Tools such as Scapy can be used to craft these packets.
3. Spoof source IP addresses: Set distinct spoofed source IPs on each packet (e.g., rotating through RFC 5737 documentation ranges or arbitrary addresses) to create separate entries in _deferred and _timers for each fake source, multiplying memory consumption.
4. Flood continuously: Stream a high volume of byte-distinct TC-flagged packets. Each new unique source IP adds an unbounded entry to _deferred/_timers, and each packet to an existing source triggers an O(N) dedup scan, causing quadratic CPU burn.
5. Achieve DoS: Sustain the flood until the target process is OOM-killed (on memory-constrained hardware) or until event-loop starvation disrupts mDNS-dependent services such as Home Assistant service discovery (Github Advisory, Fix PR #1751).

• Network: High-volume UDP traffic to port 5353 (224.0.0.251 or ff02::fb) from many distinct source IP addresses in rapid succession; TC-bit set in mDNS query packets; source IPs that do not correspond to known LAN devices or appear in documentation/reserved ranges (e.g., 203.0.113.x, 198.51.100.x, 192.0.2.x).
• Process: Rapidly increasing memory consumption by the Python process running zeroconf; high CPU utilization on the zeroconf process without a corresponding increase in legitimate mDNS activity; OOM-kill events in system logs targeting the zeroconf or Home Assistant process.
• Logs: System OOM killer log entries (oom-kill or Out of memory: Kill process) referencing the zeroconf or Home Assistant process; application-level errors or timeouts in mDNS service discovery, registration, or ServiceBrowser callbacks coinciding with unusual network traffic.

Upgrade to zeroconf version 0.149.12 or later, which introduces per-address queue caps (_MAX_DEFERRED_PER_ADDR = 16) and a total-address cap (_MAX_DEFERRED_ADDRS = 512) with FIFO eviction, bounding worst-case memory at approximately 72 MB even under a spoofed-source flood (Release 0.149.12, Fix PR #1751). There is no in-process workaround available for unpatched versions. As a network-level mitigation, restrict mDNS traffic (UDP/5353) to trusted Layer-2 segments using AP client isolation, guest-network separation, or host firewall rules to limit exposure to untrusted LAN peers (Github Advisory).

The fix was authored and merged by the primary maintainer (bdraco) on May 20, 2026, with the security advisory published the following day. The openSUSE security team issued a security announcement for the package update, and Tenable published Nessus detection plugins (IDs 324891 and 327765) for the vulnerability. The fix was also backported into downstream projects such as Music Assistant. No significant broader media coverage or notable researcher commentary beyond the maintainer's own detailed advisory has been identified (openSUSE Announcement, Tenable Plugin).