The vulnerability in Airshare's zeroconf implementation arises from the DNSCache._async_add method inserting every multicast DNS response record into multiple internal caches without any cap on the number of entries. The only prior protection was a minimum PTR TTL that inadvertently prolonged attacker-injected records, and a periodic cleanup interval that could not keep pace with a flood of multicast DNS responses. An unauthenticated attacker on the local link can multicast valid mDNS responses with unique names, causing the cache to grow unbounded and eventually exhaust memory, especially on constrained devices like Raspberry Pi running Home Assistant. This leads to process OOM kills and degraded performance of zeroconf consumers. A second variant involves re-multicasting cached records with shifting TTLs, causing unbounded growth in the expiration heap. The issue is fixed in zeroconf 0.149.6.

An unauthenticated attacker on the local network can cause a denial of service by exhausting memory on devices running vulnerable versions of zeroconf through multicast DNS flooding. This results in process crashes (OOM kills) and degraded performance of zeroconf-dependent services such as discovery and registration. There is no impact on confidentiality or integrity, but availability is significantly affected.

Upgrade zeroconf to version 0.149.6 or later to apply the official fix. There is no in-process workaround. Until upgrading, restrict multicast DNS (UDP/5353) traffic to trusted Layer-2 network segments using AP client isolation, guest network separation, or host firewall rules to prevent untrusted hosts from sending multicast DNS responses.