GHSA-9663-mqmp-p9mm
MEDIUMpython-zeroconf: Unbounded TC-deferred queue allows LAN-local memory exhaustion via spoofed-source flood
Blast Radius
zeroconfReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Impact
AsyncListener.handle_query_or_defer retained every truncated (TC-bit) incoming query in self._deferred[addr] and armed a per-addr timer in self._timers[addr] that flushed the reassembled query within ~500 ms (RFC 6762 §18.5). Neither the per-addr list nor the number of distinct addr keys was capped, and the dedup check (for incoming in reversed(deferred): if incoming.data == msg.data) ran O(N) over the per-addr list on every arrival.
Any unauthenticated host on the local link (UDP/5353, 224.0.0.251 / ff02::fb) can stream byte-distinct TC-flagged mDNS queries — each up to _MAX_MSG_ABSOLUTE = 8966 bytes, with DNSIncoming retaining the raw data buffer plus parsed-record state. Trivially spoofed source IPs multiply the effect across _deferred / _timers, and the O(N) data compare burns CPU quadratically as each per-addr queue grows. On memory-constrained deployments (Home Assistant on Raspberry-Pi-class hardware is the canonical victim) sustained traffic OOM-kills the process; under lighter load, the per-arrival scan and event-loop scheduler starvation break unrelated zeroconf consumers (discovery, registration, ServiceBrowser callbacks).
Patches
Fixed in zeroconf 0.149.12 (PR #1751). Upgrade to >= 0.149.12.
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 #1751, fix
- RFC 6762 §18.5, CWE-400
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | zeroconf | all versions | 0.149.12 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for zeroconf. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update zeroconf to 0.149.12 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9663-mqmp-p9mm is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-9663-mqmp-p9mm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-9663-mqmp-p9mm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-9663-mqmp-p9mm in your dependencies?
O3 detects GHSA-9663-mqmp-p9mm across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.