PT-2026-48689 · Pypi · Zeroconf
Published
2026-06-11
·
Updated
2026-06-11
·
CVE-2026-48045
CVSS v3.1
6.5
Medium
| Vector | AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
Impact
AsyncListener.handle query or defer retained every truncated (TC-bit) incoming query in self. deferred[addr] and armed a per-addr timer in self. timers[addr] that flushed the reassembled query within ~500 ms (RFC 6762 §18.5). Neither the per-addr list nor the number of distinct addr keys was capped, and the dedup check (for incoming in reversed(deferred): if incoming.data == msg.data) ran O(N) over the per-addr list on every arrival.Any unauthenticated host on the local link (UDP/5353,
224.0.0.251 / ff02::fb) can stream byte-distinct TC-flagged mDNS queries — each up to MAX MSG ABSOLUTE = 8966 bytes, with DNSIncoming retaining the raw data buffer plus parsed-record state. Trivially spoofed source IPs multiply the effect across deferred / timers, and the O(N) data compare burns CPU quadratically as each per-addr queue grows. On memory-constrained deployments (Home Assistant on Raspberry-Pi-class hardware is the canonical victim) sustained traffic OOM-kills the process; under lighter load, the per-arrival scan and event-loop scheduler starvation break unrelated zeroconf consumers (discovery, registration, ServiceBrowser callbacks).Patches
Workarounds
There is no in-process workaround; upgrading is the fix. Otherwise, restrict mDNS (UDP/5353) to trusted Layer-2 segments via AP client isolation, guest-network separation, or host firewall rules.
Resources
- PR #1751, fix
- RFC 6762 §18.5, CWE-400
Fix
Allocation of Resources Without Limits
Resource Exhaustion
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Zeroconf