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

CVE-2026-47183 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-47183?

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

python-zeroconf CVE-2026-47183

MEDIUM

Uncontrolled Resource Consumption (CWE-400)

2026-05-29 https://github.com/python-zeroconf/python-zeroconf

GHSA-phvx-9mgw-67r5

Canonical Python 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

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

May 29, 2026 - 20:37 vuln.today

Analysis Generated

May 29, 2026 - 20:37 vuln.today

CVE Published

May 29, 2026 - 20:13 nvd

MEDIUM 6.5

DescriptionGitHub Advisory

Impact

DNSIncoming._log_exception_debug and the four QuietLogger exception-dedup methods stored an unbounded _seen_logs dict keyed by str(sys.exc_info()[1]). The seven IncomingDecodeError messages raised from _read_name / _decode_labels_at_offset (RFC 6762 §18 name-decoding error paths) all embed self.source - the peer's ephemeral source port, varying per packet - plus byte offset and pointer link, so every attacker-influenced combination produced a fresh dedup key. The stored value was the full sys.exc_info() triple, whose traceback's frame locals retained self.data (the raw inbound packet, up to 8966 bytes per RFC 6762 §17). Each unique malformed packet therefore pinned ~9 KB until process exit.

Any unauthenticated host on the local link (UDP/5353, 224.0.0.251 / ff02::fb) can drive memory growth at line rate; that includes a guest on the same Wi-Fi, a compromised IoT device, or a container on a shared bridge. On memory-constrained deployments (Home Assistant on Raspberry-Pi-class hardware is the canonical victim) sustained traffic trivially OOM-kills the process, and mDNS-dependent features (HomeKit, Chromecast/Matter, AirPlay, printers) degrade or fail.

Patches

Fixed in zeroconf 0.149.6 (PR #1717). Upgrade to >= 0.149.6.

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

AnalysisAI

Memory exhaustion in python-zeroconf's exception deduplication logic allows any unauthenticated LAN-adjacent host to permanently pin approximately 9 KB of heap memory per unique malformed mDNS packet, enabling denial of service against zeroconf-dependent applications. The flaw affects all versions of the pip package zeroconf prior to 0.149.6; the unbounded _seen_logs dict in QuietLogger and DNSIncoming._log_exception_debug retained full Python traceback objects - and thus raw inbound packet buffers - keyed by attacker-influenced exception strings derived from ephemeral source ports, byte offsets, and pointer links. No public exploit or CISA KEV listing exists at time of analysis, but the attack is mechanistically straightforward and particularly severe on memory-constrained deployments such as Home Assistant on Raspberry Pi-class hardware, where sustained flood traffic can OOM-kill the process and disable HomeKit, Chromecast/Matter, and AirPlay discovery.

Technical ContextAI

The vulnerability resides in src/zeroconf/_logger.py and src/zeroconf/_protocol/incoming.py of the python-zeroconf library (PURL: pkg:pip/zeroconf), which implements the mDNS/DNS-SD protocol stack in pure Python. The root cause is CWE-400 (Uncontrolled Resource Consumption): the QuietLogger class stored a ClassVar[dict[str, int | tuple]] named _seen_logs that was never bounded or evicted. The dict values were the full sys.exc_info() triple - including the traceback object - whose frame locals retained self.data, the raw inbound UDP payload of up to 8966 bytes per RFC 6762 §17. The dedup keys were constructed from IncomingDecodeError exception strings raised by _read_name and _decode_labels_at_offset during RFC 6762 §18 label-decoding error paths; these strings embedded self.source (the peer's ephemeral source port), byte offset, and pointer link - all attacker-controllable fields that vary per packet. The mDNS transport (UDP/5353, multicast 224.0.0.251 and ff02::fb) is inherently unauthenticated and reachable from any host on the same Layer-2 segment without prior authorization.

RemediationAI

Upgrade to zeroconf 0.149.6 or later, confirmed fixed via PR #1717 at https://github.com/python-zeroconf/python-zeroconf/pull/1717. The fix replaces the unbounded _seen_logs class-variable dict with a module-level bounded dict capped at _MAX_SEEN_LOGS = 512 entries that stores only None values (not traceback objects), eliminating both the unbounded growth and the packet buffer retention via frame locals. No in-process workaround is available per the vendor advisory at https://github.com/python-zeroconf/python-zeroconf/security/advisories/GHSA-phvx-9mgw-67r5. If immediate upgrade is not possible, apply network-layer compensating controls: (1) Enable AP client isolation on Wi-Fi access points to block guest-to-host multicast - trade-off is that isolated clients lose mDNS-based discovery including AirPlay and printer access from the isolated segment; (2) Implement VLAN-based guest network separation so untrusted devices cannot reach the mDNS multicast group on the trusted LAN - trade-off is infrastructure complexity and loss of cross-VLAN mDNS without a reflector/proxy; (3) Configure host firewall rules to drop inbound UDP/5353 from untrusted source CIDRs (e.g., iptables -A INPUT -p udp --dport 5353 ! -s <trusted-subnet>/24 -j DROP) - trade-off is that this breaks legitimate mDNS discovery from blocked segments and must be maintained as network topology changes.