What is the CVSS score of CVE-2026-48045?

CVE-2026-48045 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-48045?

Yes, a patch is available for CVE-2026-48045. Update the affected software to the latest version immediately.

python-zeroconf CVE-2026-48045

MEDIUM

Uncontrolled Resource Consumption (CWE-400)

2026-06-11 https://github.com/python-zeroconf/python-zeroconf

GHSA-9663-mqmp-p9mm

Python Canonical Denial Of Service Suse

6.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

6.5 MEDIUM

AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

6.5 MEDIUM

Adjacent vector because exploitation requires LAN-local mDNS multicast access; PR:N because mDNS is unauthenticated by design; pure availability impact with no confidentiality or integrity exposure.

3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

SUSE

MEDIUM

qualitative

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector

Adjacent

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jun 11, 2026 - 13:59 vuln.today

Analysis Generated

Jun 11, 2026 - 13:59 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

1 pypi packages depend on zeroconf (1 direct, 0 indirect)

Ecosystem-wide dependent count for version 0.149.12.

DescriptionGitHub Advisory

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

Fixed in zeroconf 0.149.12 (PR #1751). Upgrade to >= 0.149.12.

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

AnalysisAI

Memory exhaustion and CPU starvation in python-zeroconf before 0.149.12 allows any unauthenticated LAN-adjacent host to OOM-kill or stall the zeroconf process by flooding TC-flagged mDNS queries over UDP/5353. The AsyncListener.handle_query_or_defer method retained all TC-bit packets in an unbounded _deferred[addr] dictionary - each entry up to 8,966 bytes of raw buffer plus parsed DNS state - with no cap on per-address queue depth or total distinct source addresses, and the per-arrival dedup scan ran O(N) causing quadratic CPU growth as queues expanded. Trivially spoofed source IPs multiply the memory footprint across _deferred/_timers; on Raspberry Pi-class hardware running Home Assistant, sustained flood traffic causes OOM termination; no public exploit identified at time of analysis.

Technical ContextAI

mDNS (Multicast DNS, RFC 6762) operates over UDP port 5353 using multicast groups 224.0.0.251 (IPv4) and ff02::fb (IPv6) for zero-configuration LAN service discovery. RFC 6762 §18.5 specifies that receivers must defer processing of TC-bit (Truncation) queries and wait approximately 500 ms for a follow-up complete query before flushing the reassembled record. The python-zeroconf library (CPE: pkg:pip/zeroconf) implemented this reassembly in AsyncListener.handle_query_or_defer in src/zeroconf/_listener.py, accumulating each TC-flagged DNSIncoming object into self._deferred[addr] and scheduling a per-address flush timer in self._timers[addr]. CWE-400 (Uncontrolled Resource Consumption) is the root cause: neither the per-address list length nor the total count of distinct addr keys in _deferred was bounded. Each DNSIncoming object retains the full raw data buffer (up to _MAX_MSG_ABSOLUTE = 8966 bytes) alongside parsed record state, meaning memory consumption scales linearly with injected packets. Additionally, the deduplication scan (for incoming in reversed(deferred): if incoming.data == msg.data) was O(N) per arrival, producing quadratic CPU consumption as per-address queues grew. The fix in 0.149.12 introduced _MAX_DEFERRED_PER_ADDR = 16 and _MAX_DEFERRED_ADDRS = 512 constants with a FIFO eviction method _evict_oldest_deferred that prevents address-rotation attacks from permanently occupying slots.

RemediationAI

Upgrade the zeroconf package to version 0.149.12 or later using pip install "zeroconf>=0.149.12". This is the vendor-confirmed fix version per GHSA-9663-mqmp-p9mm and PR #1751 (commit b22c8ff19c66c68907d220a4823c0950f4fa93f7). The fix bounds the attack surface by capping per-address reassembly queues at 16 entries and total tracked source addresses at 512, with FIFO eviction to prevent address-rotation attacks. The vendor explicitly states there is no in-process workaround - upgrading is the only complete fix. If immediate upgrade is not possible, restrict UDP/5353 traffic to trusted Layer-2 segments using AP client isolation (prevents untrusted wireless clients from injecting mDNS), guest-network VLAN separation, or host firewall rules (e.g., iptables -A INPUT -p udp --dport 5353 -s <trusted_cidr> -j ACCEPT; iptables -A INPUT -p udp --dport 5353 -j DROP). Note that firewall-based mitigations do not protect against attackers already on the same trusted LAN segment, and AP client isolation trades off legitimate mDNS-based discovery (AirPlay, Chromecast, HomeKit) for attack surface reduction. Full advisory: https://github.com/python-zeroconf/python-zeroconf/security/advisories/GHSA-9663-mqmp-p9mm.