Affected: python-zeroconf

Zeroconf is a pure Python implementation of multicast DNS service discovery. Prior to 0.149.16, _read_character_string and _read_string in src/zeroconf/_protocol/incoming.py advanced self.offset by attacker-declared RDLENGTH without checking it against self._data_len, allowing unauthenticated hosts on the local link over UDP/5353 (224.0.0.251 / ff02::fb) to send a TXT, HINFO, or A/AAAA record with rdlength=65535 and seed DNSCache and ServiceInfo.properties with truncated, attacker-shaped key/value or address records. This issue is fixed in version 0.149.16.

Affected: PyPI: zeroconf

### 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 m…

Affected: PyPI: zeroconf

### 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 m…