CVE-2026-48487: 
Python vulnerability analysis and mitigation

CVE-2026-48487 is an improper handling of length parameter inconsistency (CWE-130) in the python-zeroconf library, a pure Python implementation of multicast DNS (mDNS) service discovery. The vulnerability exists in _read_character_string and _read_string functions within src/zeroconf/_protocol/incoming.py, which advance the internal offset by an attacker-declared RDLENGTH without validating it against the actual buffer size. All versions of python-zeroconf prior to 0.149.16 are affected. The issue was reported on May 20, 2026, patched the same day via PR #1756, and publicly disclosed via GitHub Advisory GHSA-qc2x-6f54-m6h9 on June 22, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory).

The root cause is that _read_string(length) and _read_character_string() in src/zeroconf/_protocol/incoming.py slice self.data[self.offset : self.offset + length] and then unconditionally advance self.offset += length without first checking whether self.offset + length exceeds self._data_len. Python's slice operator silently returns fewer bytes when the end index runs past the buffer, so the constructed DNS record (DNSText, DNSHinfo, or DNSAddress) is built from a truncated payload and appended to DNSIncoming._answers before any parse failure surfaces. The subsequent _read_name() call for the next record then fails because the offset is now past the buffer end, but the malformed record has already been committed to DNSCache and ServiceInfo.properties. An unauthenticated attacker on the local link can exploit this by multicasting a single crafted mDNS response over UDP/5353 (224.0.0.251 / ff02::fb) containing a TXT, HINFO, or A/AAAA record with rdlength=65535 and only a few real payload bytes (GitHub Advisory, GitHub Issue #1752).

Successful exploitation allows an unauthenticated attacker on the same Layer-2 network segment to poison the DNSCache and ServiceInfo.properties of any host running a vulnerable version of python-zeroconf. Downstream consumers that rely on mDNS-based service discovery — such as Home Assistant and other zeroconf-driven applications — will trust the attacker-shaped key/value pairs and address records for the duration of the record's TTL window. While this is not remote code execution, it enables service discovery spoofing and is classified as a parser-state desync bug that could serve as a building block for higher-impact attack chains (GitHub Advisory, GitHub Issue #1752).

1. Reconnaissance: Identify hosts on the local network segment running python-zeroconf < 0.149.16 by passively monitoring mDNS traffic on UDP/5353 (multicast 224.0.0.251 or ff02::fb) using tools such as tcpdump or Wireshark.
2. Craft malicious mDNS packet: Construct a crafted mDNS response packet containing a TXT, HINFO, or A/AAAA record where the 16-bit RDLENGTH field (per RFC 1035 §3.2.1) is set to 65535 but only a small number of actual payload bytes (e.g., 5–10 bytes) follow.
3. Multicast the packet: Send the crafted UDP packet to the mDNS multicast address (224.0.0.251 for IPv4 or ff02::fb for IPv6) on port 5353 from any host on the same Layer-2 segment — no authentication or prior session is required.
4. Cache poisoning: The vulnerable _read_string or _read_character_string function silently truncates the payload to the available bytes but advances the internal offset by the declared 65535, causing the malformed record to be committed to DNSCache and ServiceInfo.properties.
5. Exploit downstream consumers: Applications querying ServiceInfo.properties (e.g., Home Assistant) will receive the attacker-shaped key/value or address records, enabling service spoofing or redirection for the duration of the record's TTL (GitHub Advisory, GitHub Issue #1752).

• Network: Unexpected mDNS response packets on UDP/5353 (224.0.0.251 or ff02::fb) from unfamiliar hosts; mDNS TXT, HINFO, or A/AAAA records with anomalously large RDLENGTH values (e.g., 65535) but very short actual payloads detectable via packet capture.
• Logs: Python application logs showing IncomingDecodeError exceptions referencing _read_string or _read_character_string with overrun messages (only on patched versions); unexpected changes in resolved service properties or addresses logged by zeroconf-dependent applications such as Home Assistant.
• Application Behavior: Service discovery consumers (e.g., Home Assistant) suddenly resolving known services to unexpected IP addresses or reporting unexpected TXT property values; intermittent parse failures for subsequent mDNS records in the same packet.

Upgrade python-zeroconf to version 0.149.16 or later, which adds explicit bounds checks in _read_string and _read_character_string to raise IncomingDecodeError when the declared length would overrun the packet buffer, and adds a per-record post-check in _read_others to drop and resync on boundary violations (GitHub Release, GitHub PR #1756). There is no in-process workaround; upgrading is the only code-level fix. 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 the attacker's ability to reach vulnerable hosts (GitHub Advisory).

The maintainer (bdraco) acknowledged the issue promptly and merged the fix on the same day it was reported (May 20, 2026), noting the severity was manually set to Low to override the CVSS score of 6.5 Medium, as the CVSS metric does not fully account for the mDNS threat model where unauthenticated local-link access is the norm. The advisory notes the impact is likely lower than other recently released advisories for the same library due to the absence of OOM risk. openSUSE issued security announcements covering the fix for their python-zeroconf packages (GitHub Advisory).