What is the CVSS score of CVE-2026-47184?

CVE-2026-47184 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-47184?

Yes, a patch is available for CVE-2026-47184. Update the affected software to the latest version immediately.

python-zeroconf CVE-2026-47184

MEDIUM

Uncontrolled Resource Consumption (CWE-400)

2026-05-29 https://github.com/python-zeroconf/python-zeroconf

GHSA-rfg2-pjw2-56x2

Canonical Python Denial Of Service Suse

6.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

6.5 MEDIUM

AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

SUSE

MEDIUM

qualitative

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector

Adjacent

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 29, 2026 - 20:51 vuln.today

Analysis Generated

May 29, 2026 - 20:51 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

1 pypi packages depend on zeroconf (1 direct, 0 indirect)

Ecosystem-wide dependent count for version 0.149.7.

DescriptionGitHub Advisory

Impact

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.

Patches

Fixed in zeroconf 0.149.6 (PR #1718). Upgrade to >= 0.149.6.

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

AnalysisAI

Memory exhaustion in python-zeroconf's DNSCache component allows any unauthenticated host on the same Layer-2 segment to OOM-kill or severely degrade processes that consume mDNS/DNS-SD services (CVSS 6.5, AV:A/PR:N). The DNSCache._async_add method imposed no upper bound on cache entries, permitting a local-link attacker to multicast valid mDNS responses with unique names that accumulate across all four internal data structures faster than the 10-second cleanup interval can purge them. A second distinct variant exploits TTL re-advertisement to bloat the internal _expire_heap independently of the cache entry counter, providing a second unbounded growth path that bypasses any entry-count monitoring. No public exploit is identified at time of analysis; a vendor-released patch is available as of zeroconf 0.149.6 or 0.149.7 (minor version discrepancy between sources - see confidence notes).

Technical ContextAI

The affected component is the Python zeroconf package (pip/zeroconf), a pure-Python implementation of Multicast DNS per RFC 6762 and DNS-SD per RFC 6763, used extensively in home automation stacks such as Home Assistant. The root cause is CWE-400 (Uncontrolled Resource Consumption): DNSCache._async_add in src/zeroconf/_cache.py unconditionally inserts every incoming mDNS record into four internal structures - cache (keyed dict), _expirations (record-to-deadline map), _expire_heap (min-heap for expiry scheduling), and service_cache - with no entry cap. The PTR TTL floor of 1125 seconds mandated by RFC 6762 §10 paradoxically extended attacker-injected records' residency rather than constraining them. The periodic async_expire coroutine running every 10 seconds was architecturally insufficient to drain a sustained flood. A secondary variant exploits RFC 6762 §11's allowance for TTL re-advertisement: replaying records with shifting TTLs appends duplicate stale tuples to _expire_heap without incrementing the cache key counter, causing heap bloat that is invisible to entry-count logic. The fix in PR #1718 introduces a _MAX_CACHE_RECORDS constant hard cap, an LRU-style _async_evict_oldest method that pops the closest-to-expiring entry when the cap is reached, and a _maybe_rebuild_heap method that compacts the heap when stale entries dominate live ones - addressing both attack variants.

RemediationAI

Upgrade to zeroconf >= 0.149.7 via pip install "zeroconf>=0.149.7" - this is the conservative guidance given the discrepancy between the advisory (0.149.6) and package metadata (0.149.7); verify against the PyPI release history and the merged fix at https://github.com/python-zeroconf/python-zeroconf/pull/1718. The vendor advisory at https://github.com/python-zeroconf/python-zeroconf/security/advisories/GHSA-rfg2-pjw2-56x2 explicitly confirms there is no viable in-process workaround; upgrading is the only software-level fix. As a network-level compensating control where immediate patching is not possible, restrict UDP/5353 (mDNS multicast to 224.0.0.251 / ff02::fb) to trusted Layer-2 segments using AP client isolation between IoT and untrusted devices, VLAN segmentation with guest-network separation, or host-level firewall rules blocking inbound mDNS from untrusted interfaces. Note that AP client isolation prevents device-to-device mDNS traffic entirely, which will break legitimate service discovery between devices on the same segment - evaluate this operational trade-off before deployment. Host firewall rules scoped to specific source MAC ranges are more surgical but operationally complex to maintain at scale.