zeroconf: Unvalidated rdlength in record payload readers allows LAN-local cache corruption via crafted mDNS packet
Description
Impact
_read_character_string and _read_string in src/zeroconf/_protocol/incoming.py sliced self.data[self.offset : self.offset + length] and advanced self.offset by the declared length without checking it against self._data_len. Python's slice silently returns fewer bytes when the end index runs past the buffer, so a record whose 16-bit RDLENGTH (RFC 1035 §3.2.1) over-advertised by tens of kilobytes was constructed from a truncated payload, appended to DNSIncoming._answers, and committed to the cache before any later parse failure surfaced. The follow-up _read_name for the next record then failed, but the corrupt record had already entered the answer list and propagated to DNSCache and ServiceInfo.
Any unauthenticated host on the local link (UDP/5353, 224.0.0.251 / ff02::fb) can multicast a single mDNS response carrying a TXT, HINFO, or A/AAAA record that advertises rdlength=65535 and only a handful of real payload bytes; consumers calling ServiceInfo.properties then parse the truncated bytes as if they matched the wire, and downstream integrations (Home Assistant and other zeroconf-driven discovery) trust the decoded record. The bug is parser-state desync rather than RCE, but it seeds the cache with attacker-shaped key/value and address records for a TTL window and is a building block for higher-impact chains.
The impact is likely lower than the other recently released advisories as there is no additional risk of OOM so the severity was manually set to low to override the score CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N (6.5, Medium) since that doesn't fully consider the mDNS threat model.
Patches
Fixed in zeroconf 0.149.16 (PR #1756). Note that this change originally intended to ship in 0.149.13 but we ran out of space on PyPI: see https://github.com/python-zeroconf/python-zeroconf/issues/1769
Upgrade to >= 0.149.16.
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 #1756, fix
- Issue #1752, public tracking issue
- RFC 1035 §3.2.1, RFC 1035 §3.3, CWE-130
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected packages
Versions sourced from the GitHub Security Advisory.
| Package | Affected versions | Patched versions |
|---|---|---|
zeroconfPyPI | < 0.149.16 | 0.149.16 |
Affected products
1- Range: <0.149.16
Patches
Vulnerability mechanics
Root cause
"Missing bounds check on rdlength in `_read_string` and `_read_character_string` allows Python's slice to silently truncate payload data, causing parser-state desync and cache corruption."
Attack vector
Any unauthenticated host on the local link (UDP/5353, `224.0.0.251` / `ff02::fb`) can multicast a single mDNS response carrying a TXT, HINFO, or A/AAAA record that advertises `rdlength=65535` and only a handful of real payload bytes [ref_id=3]. Consumers calling `ServiceInfo.properties` then parse the truncated bytes as if they matched the wire, and downstream integrations (Home Assistant and other zeroconf-driven discovery) trust the decoded record [ref_id=3]. The bug is parser-state desync rather than RCE, but it seeds the cache with attacker-shaped key/value and address records for a TTL window [CWE-130][ref_id=3].
Affected code
`_read_character_string` and `_read_string` in `src/zeroconf/_protocol/incoming.py` slice `self.data[self.offset : self.offset + length]` and advance `self.offset` by the declared length without checking it against `self._data_len`. Python's slice silently returns fewer bytes when the end index runs past the buffer, so a record whose 16-bit RDLENGTH over-advertises by tens of kilobytes is constructed from a truncated payload, appended to `DNSIncoming._answers`, and committed to the cache before any later parse failure surfaces [ref_id=3].
What the fix does
The fix in PR #1756 adds a bounds check in `_read_string` and `_read_character_string` that rejects the record when `self.offset + length` exceeds `self._data_len`, raising `IncomingDecodeError` instead of silently truncating [ref_id=1][ref_id=2]. A per-record post-check in `_read_others` verifies `self.offset != end` to catch record-boundary overruns and restore the offset for the next record [ref_id=1]. The existing `try/except` in `_read_others` already skips malformed records, so the only effect is that truncated/over-advertised payloads are dropped instead of being silently retained in the cache [ref_id=2].
Preconditions
- networkAttacker must be on the same local link (Layer-2 segment) as the target
- inputAttacker sends a single mDNS response packet to UDP/5353 multicast address 224.0.0.251 or ff02::fb
- authNo authentication required; mDNS has no source authentication
Generated on Jun 23, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4News mentions
0No linked articles in our index yet.