DNSCache._async_add inserted every response record into cache, _expirations, _expire_heap, and service_cache with no cap on entry count. The only pre-existing protection was a PTR TTL floor (_DNS_PTR_MIN_TTL = 1125 s, RFC 6762 §10), which actually prolonged attacker-injected records, and a periodic async_expire on _CACHE_CLEANUP_INTERVAL = 10 s that could not keep up with a flood.
Any unauthenticated host on the local link (UDP/5353, 224.0.0.251 / ff02::fb) can multicast valid mDNS responses with unique names (RFC 6762 §11 allows up to 253 bytes each) and watch them accumulate. On memory-constrained deployments (Home Assistant on Raspberry-Pi-class hardware is the canonical victim) sustained traffic OOM-kills the process; under lighter load, every cache lookup and every periodic expiry pass grows linearly slower, starving asyncio and breaking unrelated zeroconf consumers (discovery, registration, ServiceBrowser callbacks). A second variant — re-multicasting cached records with shifting TTLs — grows _expire_heap unbounded between cleanup runs without touching cache or _total_records.
Fixed in zeroconf 0.149.6 (PR #1718). Upgrade to >= 0.149.6.
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.
No EPSS score in this advisory JSON.
| Base score | Version | Severity | Vector |
|---|---|---|---|
| 6.5 | 3.1 | — |
|
| Type | Value |
|---|---|
| GHSA | GHSA-rfg2-pjw2-56x2 ↗ |
| CVE | CVE-2026-47184 ↗ |
Vulnerable version ranges and first patched releases as published by GitHub.
| Ecosystem | Package | Vulnerable range | First patched | Vulnerable functions |
|---|---|---|---|---|
| pip | zeroconf | < 0.149.7 | 0.149.7 | — |