Vulnerability-Lookup

Search criteria

Vendor

Product

Assigner

Sources

Sort by

Order

CVSS min

CVSS max

Apply ordering (override relevance)

GHSA-RFG2-PJW2-56X2

Vulnerability from github – Published: 2026-05-29 20:18 – Updated: 2026-05-29 20:18

Summary

zeroconf has unbounded DNS record cache that allows LAN-local memory exhaustion via multicast flood

Details

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

PR #1718, fix
Issue #1715, public tracking issue
RFC 6762 §10, RFC 6762 §11, CWE-400

Severity

6.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "zeroconf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.149.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47184"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T20:18:53Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n`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 \u00a710), 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.\n\nAny unauthenticated host on the local link (UDP/5353, `224.0.0.251` / `ff02::fb`) can multicast valid mDNS responses with unique names (RFC 6762 \u00a711 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 \u2014 re-multicasting cached records with shifting TTLs \u2014 grows `_expire_heap` unbounded between cleanup runs without touching `cache` or `_total_records`.\n\n### Patches\n\nFixed in `zeroconf` 0.149.6 ([PR #1718](https://github.com/python-zeroconf/python-zeroconf/pull/1718)). Upgrade to `\u003e= 0.149.6`.\n\n### Workarounds\n\nThere 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.\n\n### Resources\n\n- [PR #1718](https://github.com/python-zeroconf/python-zeroconf/pull/1718), fix\n- [Issue #1715](https://github.com/python-zeroconf/python-zeroconf/issues/1715), public tracking issue\n- [RFC 6762 \u00a710](https://www.rfc-editor.org/rfc/rfc6762#section-10), [RFC 6762 \u00a711](https://www.rfc-editor.org/rfc/rfc6762#section-11), [CWE-400](https://cwe.mitre.org/data/definitions/400.html)",
  "id": "GHSA-rfg2-pjw2-56x2",
  "modified": "2026-05-29T20:18:53Z",
  "published": "2026-05-29T20:18:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-zeroconf/python-zeroconf/security/advisories/GHSA-rfg2-pjw2-56x2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-zeroconf/python-zeroconf/issues/1715"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-zeroconf/python-zeroconf/pull/1718"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-zeroconf/python-zeroconf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "zeroconf has unbounded DNS record cache that allows LAN-local memory exhaustion via multicast flood"
}

PYSEC-2026-3439

Vulnerability from pysec - Published: 2026-07-13 15:19 - Updated: 2026-07-13 16:07

Details

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

PR #1718, fix
Issue #1715, public tracking issue
RFC 6762 §10, RFC 6762 §11, CWE-400

Severity

6.5 (Medium)


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

Impacted products

Name	purl
zeroconf	pkg:pypi/zeroconf

Aliases

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "zeroconf",
        "purl": "pkg:pypi/zeroconf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.149.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.100.0",
        "0.101.0",
        "0.102.0",
        "0.103.0",
        "0.104.0",
        "0.105.0",
        "0.106.0",
        "0.107.0",
        "0.108.0",
        "0.109.0",
        "0.110.0",
        "0.111.0",
        "0.112.0",
        "0.114.0",
        "0.115.0",
        "0.115.1",
        "0.115.2",
        "0.116.0",
        "0.117.0",
        "0.118.0",
        "0.118.1",
        "0.119.0",
        "0.120.0",
        "0.121.0",
        "0.122.0",
        "0.122.1",
        "0.122.2",
        "0.122.3",
        "0.123.0",
        "0.124.0",
        "0.125.0",
        "0.126.0",
        "0.127.0",
        "0.128.0",
        "0.128.1",
        "0.128.2",
        "0.128.3",
        "0.128.4",
        "0.128.5",
        "0.129.0",
        "0.130.0",
        "0.131.0",
        "0.132.0",
        "0.132.1",
        "0.132.2",
        "0.133.0",
        "0.134.0",
        "0.135.0",
        "0.136.0",
        "0.136.1",
        "0.136.2",
        "0.137.0",
        "0.137.1",
        "0.137.2",
        "0.138.0",
        "0.138.1",
        "0.139.0",
        "0.14",
        "0.140.0",
        "0.140.1",
        "0.141.0",
        "0.142.0",
        "0.143.0",
        "0.143.1",
        "0.144.0",
        "0.144.1",
        "0.144.2",
        "0.144.3",
        "0.145.0",
        "0.145.1",
        "0.146.0",
        "0.146.1",
        "0.146.2",
        "0.146.3",
        "0.146.4",
        "0.146.5",
        "0.147.0",
        "0.147.1",
        "0.147.2",
        "0.147.3",
        "0.147.4",
        "0.148.0",
        "0.149.0",
        "0.149.1",
        "0.149.2",
        "0.149.3",
        "0.149.4",
        "0.149.5",
        "0.149.6",
        "0.15",
        "0.15.1",
        "0.16.0",
        "0.17.0",
        "0.17.1",
        "0.17.2",
        "0.17.3",
        "0.17.4",
        "0.17.5",
        "0.17.6",
        "0.17.7",
        "0.18.0",
        "0.19.0",
        "0.19.1",
        "0.20.0",
        "0.21.0",
        "0.21.1",
        "0.21.2",
        "0.21.3",
        "0.22.0",
        "0.23.0",
        "0.24.0",
        "0.24.1",
        "0.24.2",
        "0.24.3",
        "0.24.4",
        "0.24.5",
        "0.25.0",
        "0.25.1",
        "0.26.0",
        "0.26.1",
        "0.26.2",
        "0.26.3",
        "0.27.0",
        "0.27.1",
        "0.28.0",
        "0.28.1",
        "0.28.2",
        "0.28.3",
        "0.28.4",
        "0.28.5",
        "0.28.6",
        "0.28.7",
        "0.28.8",
        "0.29.0",
        "0.30.0",
        "0.31.0",
        "0.32.0",
        "0.32.1",
        "0.33.0",
        "0.33.1",
        "0.33.2",
        "0.33.3",
        "0.33.4",
        "0.34.0",
        "0.34.1",
        "0.34.2",
        "0.34.3",
        "0.35.0",
        "0.35.1",
        "0.36.0",
        "0.36.1",
        "0.36.11",
        "0.36.12",
        "0.36.13",
        "0.36.2",
        "0.36.3",
        "0.36.4",
        "0.36.5",
        "0.36.6",
        "0.36.7",
        "0.36.8",
        "0.36.9",
        "0.37.0",
        "0.38.0",
        "0.38.1",
        "0.38.3",
        "0.38.4",
        "0.38.5",
        "0.38.6",
        "0.38.7",
        "0.39.0",
        "0.39.1",
        "0.39.2",
        "0.39.3",
        "0.39.4",
        "0.43.0",
        "0.44.0",
        "0.45.0",
        "0.46.0",
        "0.47.0",
        "0.47.1",
        "0.47.2",
        "0.47.3",
        "0.47.4",
        "0.48.0",
        "0.49.0",
        "0.50.0",
        "0.51.0",
        "0.52.0",
        "0.53.0",
        "0.53.1",
        "0.54.0",
        "0.55.0",
        "0.56.0",
        "0.57.0",
        "0.58.0",
        "0.58.1",
        "0.58.2",
        "0.59.0",
        "0.60.0",
        "0.61.0",
        "0.62.0",
        "0.63.0",
        "0.64.0",
        "0.64.1",
        "0.65.0",
        "0.66.0",
        "0.67.0",
        "0.68.0",
        "0.68.1",
        "0.69.0",
        "0.70.0",
        "0.71.0",
        "0.71.1",
        "0.71.2",
        "0.71.3",
        "0.71.4",
        "0.71.5",
        "0.72.0",
        "0.72.1",
        "0.72.2",
        "0.72.3",
        "0.73.0",
        "0.74.0",
        "0.75.0",
        "0.76.0",
        "0.77.0",
        "0.78.0",
        "0.79.0",
        "0.80.0",
        "0.81.0",
        "0.82.0",
        "0.82.1",
        "0.83.0",
        "0.83.1",
        "0.84.0",
        "0.85.0",
        "0.86.0",
        "0.87.0",
        "0.88.0",
        "0.89.0",
        "0.90.0",
        "0.91.0",
        "0.91.1",
        "0.92.0",
        "0.93.0",
        "0.93.1",
        "0.94.0",
        "0.95.0",
        "0.96.0",
        "0.97.0",
        "0.98.0",
        "0.99.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47184",
    "GHSA-rfg2-pjw2-56x2"
  ],
  "details": "### Impact\n\n`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 \u00a710), 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.\n\nAny unauthenticated host on the local link (UDP/5353, `224.0.0.251` / `ff02::fb`) can multicast valid mDNS responses with unique names (RFC 6762 \u00a711 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 \u2014 re-multicasting cached records with shifting TTLs \u2014 grows `_expire_heap` unbounded between cleanup runs without touching `cache` or `_total_records`.\n\n### Patches\n\nFixed in `zeroconf` 0.149.6 ([PR #1718](https://github.com/python-zeroconf/python-zeroconf/pull/1718)). Upgrade to `\u003e= 0.149.6`.\n\n### Workarounds\n\nThere 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.\n\n### Resources\n\n- [PR #1718](https://github.com/python-zeroconf/python-zeroconf/pull/1718), fix\n- [Issue #1715](https://github.com/python-zeroconf/python-zeroconf/issues/1715), public tracking issue\n- [RFC 6762 \u00a710](https://www.rfc-editor.org/rfc/rfc6762#section-10), [RFC 6762 \u00a711](https://www.rfc-editor.org/rfc/rfc6762#section-11), [CWE-400](https://cwe.mitre.org/data/definitions/400.html)",
  "id": "PYSEC-2026-3439",
  "modified": "2026-07-13T16:07:37.186351Z",
  "published": "2026-07-13T15:19:14.814605Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-zeroconf/python-zeroconf/security/advisories/GHSA-rfg2-pjw2-56x2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-zeroconf/python-zeroconf/issues/1715"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-zeroconf/python-zeroconf/pull/1718"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-zeroconf/python-zeroconf"
    },
    {
      "type": "PACKAGE",
      "url": "https://pypi.org/project/zeroconf"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-rfg2-pjw2-56x2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47184"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "zeroconf has unbounded DNS record cache that allows LAN-local memory exhaustion via multicast flood"
}

Find a vulnerability

Search criteria

Related vulnerabilities

GHSA-RFG2-PJW2-56X2

Impact

Patches

Workarounds

Resources

PYSEC-2026-3439

Impact

Patches

Workarounds

Resources