{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pycares",
        "resource_purl": "pkg:pypi/pycares@4.11.0",
        "upstream_fixed_in": "4.9.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "checkov",
        "purl": "pkg:brew/checkov"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.615"
            },
            {
              "fixed": "3.2.440_1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pycares@4.11.0",
        "name": "pycares",
        "resource": "pycares",
        "strategy": "registry",
        "subject_version": "4.11.0"
      }
    ]
  },
  "details": "## Summary\n\npycares is vulnerable to a use-after-free condition that occurs when a Channel object is garbage collected while DNS queries are still pending. This results in a fatal Python error and interpreter crash.\n\n## Details\n\n### Root Cause\n\nThe vulnerability stems from improper handling of callback references when the Channel object is destroyed:\n\n1. When a DNS query is initiated, pycares stores a callback reference using `ffi.new_handle()`\n2. If the Channel object is garbage collected while queries are pending, the callback references become invalid\n3. When c-ares attempts to invoke the callback, it accesses freed memory, causing a fatal error\n\nThis issue was much more likely to occur when using `event_thread=True` but could happen without it under the right circumstances.\n\n### Technical Details\n\nThe core issue is a race condition between Python\u0027s garbage collector and c-ares\u0027s callback execution:\n\n1. When `__del__` is called from within a c-ares callback context, we cannot immediately call `ares_destroy()` because c-ares is still executing code after the callback returns\n2. c-ares needs to execute cleanup code after our Python callback returns (specifically at lines 1422-1429 in ares_process.c)\n3. If we destroy the channel too quickly, c-ares accesses freed memory\n\n### Impact\n\nApplications using `pycares` can be crashed remotely by triggering DNS queries that result in `Channel` objects being garbage collected before query completion. This is particularly problematic in scenarios where:\n\n- Channel objects are created per-request\n- Multiple failed DNS queries are processed rapidly\n- The application doesn\u0027t properly manage Channel lifecycle\n\nThe error manifests as:\n```\nFatal Python error: b_from_handle: ffi.from_handle() detected that the address passed points to garbage\n```\n\n## Fix\n\nThe vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism\n\n## Mitigation\n\n### For Application Developers\n\n1. **Upgrade to pycares \u003e= 4.9.0** - This version includes the fix and requires no code changes\n2. **Best practices** (optional but recommended):\n   ```python\n   # Explicit cleanup\n   channel.close()\n   \n   # Or use context manager\n   with pycares.Channel() as channel:\n       # ... use channel ...\n   # Automatically closed\n   ```\n3. **Avoid creating Channel objects per-request** - Prefer long-lived instances for better performance and safety\n\nThe fix is completely transparent - no API changes or code modifications are required.\n\n## Credit\n\nThis vulnerability was reported by @vEpiphyte through the aio-libs security program.",
  "id": "BREW-checkov-CVE-2025-48945",
  "modified": "2026-09-17T19:53:36Z",
  "published": "2026-08-13T16:39:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/commit/ebfd7d71eb8e74bc1057a361ea79a5906db510d4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/saghul/pycares"
    }
  ],
  "schema_version": "1.7.3",
  "summary": "pycares has a Use-After-Free Vulnerability",
  "upstream": [
    "GHSA-5qpg-rh4j-qp35",
    "CVE-2025-48945"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pycares",
        "resource_purl": "pkg:pypi/pycares@5.0.1",
        "upstream_fixed_in": "4.9.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "cve-bin-tool",
        "purl": "pkg:brew/cve-bin-tool"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4_2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pycares@5.0.1",
        "name": "pycares",
        "resource": "pycares",
        "strategy": "registry",
        "subject_version": "5.0.1"
      }
    ]
  },
  "details": "## Summary\n\npycares is vulnerable to a use-after-free condition that occurs when a Channel object is garbage collected while DNS queries are still pending. This results in a fatal Python error and interpreter crash.\n\n## Details\n\n### Root Cause\n\nThe vulnerability stems from improper handling of callback references when the Channel object is destroyed:\n\n1. When a DNS query is initiated, pycares stores a callback reference using `ffi.new_handle()`\n2. If the Channel object is garbage collected while queries are pending, the callback references become invalid\n3. When c-ares attempts to invoke the callback, it accesses freed memory, causing a fatal error\n\nThis issue was much more likely to occur when using `event_thread=True` but could happen without it under the right circumstances.\n\n### Technical Details\n\nThe core issue is a race condition between Python\u0027s garbage collector and c-ares\u0027s callback execution:\n\n1. When `__del__` is called from within a c-ares callback context, we cannot immediately call `ares_destroy()` because c-ares is still executing code after the callback returns\n2. c-ares needs to execute cleanup code after our Python callback returns (specifically at lines 1422-1429 in ares_process.c)\n3. If we destroy the channel too quickly, c-ares accesses freed memory\n\n### Impact\n\nApplications using `pycares` can be crashed remotely by triggering DNS queries that result in `Channel` objects being garbage collected before query completion. This is particularly problematic in scenarios where:\n\n- Channel objects are created per-request\n- Multiple failed DNS queries are processed rapidly\n- The application doesn\u0027t properly manage Channel lifecycle\n\nThe error manifests as:\n```\nFatal Python error: b_from_handle: ffi.from_handle() detected that the address passed points to garbage\n```\n\n## Fix\n\nThe vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism\n\n## Mitigation\n\n### For Application Developers\n\n1. **Upgrade to pycares \u003e= 4.9.0** - This version includes the fix and requires no code changes\n2. **Best practices** (optional but recommended):\n   ```python\n   # Explicit cleanup\n   channel.close()\n   \n   # Or use context manager\n   with pycares.Channel() as channel:\n       # ... use channel ...\n   # Automatically closed\n   ```\n3. **Avoid creating Channel objects per-request** - Prefer long-lived instances for better performance and safety\n\nThe fix is completely transparent - no API changes or code modifications are required.\n\n## Credit\n\nThis vulnerability was reported by @vEpiphyte through the aio-libs security program.",
  "id": "BREW-cve-bin-tool-CVE-2025-48945",
  "modified": "2026-08-13T16:42:04Z",
  "published": "2026-08-13T16:42:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/commit/ebfd7d71eb8e74bc1057a361ea79a5906db510d4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/saghul/pycares"
    }
  ],
  "schema_version": "1.7.3",
  "summary": "pycares has a Use-After-Free Vulnerability",
  "upstream": [
    "GHSA-5qpg-rh4j-qp35",
    "CVE-2025-48945"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pycares",
        "resource_purl": "pkg:pypi/pycares@5.0.1",
        "upstream_fixed_in": "4.9.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "maigret",
        "purl": "pkg:brew/maigret"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pycares@5.0.1",
        "name": "pycares",
        "resource": "pycares",
        "strategy": "registry",
        "subject_version": "5.0.1"
      }
    ]
  },
  "details": "## Summary\n\npycares is vulnerable to a use-after-free condition that occurs when a Channel object is garbage collected while DNS queries are still pending. This results in a fatal Python error and interpreter crash.\n\n## Details\n\n### Root Cause\n\nThe vulnerability stems from improper handling of callback references when the Channel object is destroyed:\n\n1. When a DNS query is initiated, pycares stores a callback reference using `ffi.new_handle()`\n2. If the Channel object is garbage collected while queries are pending, the callback references become invalid\n3. When c-ares attempts to invoke the callback, it accesses freed memory, causing a fatal error\n\nThis issue was much more likely to occur when using `event_thread=True` but could happen without it under the right circumstances.\n\n### Technical Details\n\nThe core issue is a race condition between Python\u0027s garbage collector and c-ares\u0027s callback execution:\n\n1. When `__del__` is called from within a c-ares callback context, we cannot immediately call `ares_destroy()` because c-ares is still executing code after the callback returns\n2. c-ares needs to execute cleanup code after our Python callback returns (specifically at lines 1422-1429 in ares_process.c)\n3. If we destroy the channel too quickly, c-ares accesses freed memory\n\n### Impact\n\nApplications using `pycares` can be crashed remotely by triggering DNS queries that result in `Channel` objects being garbage collected before query completion. This is particularly problematic in scenarios where:\n\n- Channel objects are created per-request\n- Multiple failed DNS queries are processed rapidly\n- The application doesn\u0027t properly manage Channel lifecycle\n\nThe error manifests as:\n```\nFatal Python error: b_from_handle: ffi.from_handle() detected that the address passed points to garbage\n```\n\n## Fix\n\nThe vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism\n\n## Mitigation\n\n### For Application Developers\n\n1. **Upgrade to pycares \u003e= 4.9.0** - This version includes the fix and requires no code changes\n2. **Best practices** (optional but recommended):\n   ```python\n   # Explicit cleanup\n   channel.close()\n   \n   # Or use context manager\n   with pycares.Channel() as channel:\n       # ... use channel ...\n   # Automatically closed\n   ```\n3. **Avoid creating Channel objects per-request** - Prefer long-lived instances for better performance and safety\n\nThe fix is completely transparent - no API changes or code modifications are required.\n\n## Credit\n\nThis vulnerability was reported by @vEpiphyte through the aio-libs security program.",
  "id": "BREW-maigret-CVE-2025-48945",
  "modified": "2026-08-13T17:11:30Z",
  "published": "2026-08-13T17:11:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/commit/ebfd7d71eb8e74bc1057a361ea79a5906db510d4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/saghul/pycares"
    }
  ],
  "schema_version": "1.7.3",
  "summary": "pycares has a Use-After-Free Vulnerability",
  "upstream": [
    "GHSA-5qpg-rh4j-qp35",
    "CVE-2025-48945"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pycares",
        "resource_purl": "pkg:pypi/pycares@5.0.1",
        "upstream_fixed_in": "4.9.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "moodle-dl",
        "purl": "pkg:brew/moodle-dl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.13_12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pycares@5.0.1",
        "name": "pycares",
        "resource": "pycares",
        "strategy": "registry",
        "subject_version": "5.0.1"
      }
    ]
  },
  "details": "## Summary\n\npycares is vulnerable to a use-after-free condition that occurs when a Channel object is garbage collected while DNS queries are still pending. This results in a fatal Python error and interpreter crash.\n\n## Details\n\n### Root Cause\n\nThe vulnerability stems from improper handling of callback references when the Channel object is destroyed:\n\n1. When a DNS query is initiated, pycares stores a callback reference using `ffi.new_handle()`\n2. If the Channel object is garbage collected while queries are pending, the callback references become invalid\n3. When c-ares attempts to invoke the callback, it accesses freed memory, causing a fatal error\n\nThis issue was much more likely to occur when using `event_thread=True` but could happen without it under the right circumstances.\n\n### Technical Details\n\nThe core issue is a race condition between Python\u0027s garbage collector and c-ares\u0027s callback execution:\n\n1. When `__del__` is called from within a c-ares callback context, we cannot immediately call `ares_destroy()` because c-ares is still executing code after the callback returns\n2. c-ares needs to execute cleanup code after our Python callback returns (specifically at lines 1422-1429 in ares_process.c)\n3. If we destroy the channel too quickly, c-ares accesses freed memory\n\n### Impact\n\nApplications using `pycares` can be crashed remotely by triggering DNS queries that result in `Channel` objects being garbage collected before query completion. This is particularly problematic in scenarios where:\n\n- Channel objects are created per-request\n- Multiple failed DNS queries are processed rapidly\n- The application doesn\u0027t properly manage Channel lifecycle\n\nThe error manifests as:\n```\nFatal Python error: b_from_handle: ffi.from_handle() detected that the address passed points to garbage\n```\n\n## Fix\n\nThe vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism\n\n## Mitigation\n\n### For Application Developers\n\n1. **Upgrade to pycares \u003e= 4.9.0** - This version includes the fix and requires no code changes\n2. **Best practices** (optional but recommended):\n   ```python\n   # Explicit cleanup\n   channel.close()\n   \n   # Or use context manager\n   with pycares.Channel() as channel:\n       # ... use channel ...\n   # Automatically closed\n   ```\n3. **Avoid creating Channel objects per-request** - Prefer long-lived instances for better performance and safety\n\nThe fix is completely transparent - no API changes or code modifications are required.\n\n## Credit\n\nThis vulnerability was reported by @vEpiphyte through the aio-libs security program.",
  "id": "BREW-moodle-dl-CVE-2025-48945",
  "modified": "2026-08-13T17:14:32Z",
  "published": "2026-08-13T17:14:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/commit/ebfd7d71eb8e74bc1057a361ea79a5906db510d4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/saghul/pycares"
    }
  ],
  "schema_version": "1.7.3",
  "summary": "pycares has a Use-After-Free Vulnerability",
  "upstream": [
    "GHSA-5qpg-rh4j-qp35",
    "CVE-2025-48945"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pycares",
        "resource_purl": "pkg:pypi/pycares@4.11.0",
        "upstream_fixed_in": "4.9.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "streamrip",
        "purl": "pkg:brew/streamrip"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.5"
            },
            {
              "fixed": "2.1.0_2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pycares@4.11.0",
        "name": "pycares",
        "resource": "pycares",
        "strategy": "registry",
        "subject_version": "4.11.0"
      }
    ]
  },
  "details": "## Summary\n\npycares is vulnerable to a use-after-free condition that occurs when a Channel object is garbage collected while DNS queries are still pending. This results in a fatal Python error and interpreter crash.\n\n## Details\n\n### Root Cause\n\nThe vulnerability stems from improper handling of callback references when the Channel object is destroyed:\n\n1. When a DNS query is initiated, pycares stores a callback reference using `ffi.new_handle()`\n2. If the Channel object is garbage collected while queries are pending, the callback references become invalid\n3. When c-ares attempts to invoke the callback, it accesses freed memory, causing a fatal error\n\nThis issue was much more likely to occur when using `event_thread=True` but could happen without it under the right circumstances.\n\n### Technical Details\n\nThe core issue is a race condition between Python\u0027s garbage collector and c-ares\u0027s callback execution:\n\n1. When `__del__` is called from within a c-ares callback context, we cannot immediately call `ares_destroy()` because c-ares is still executing code after the callback returns\n2. c-ares needs to execute cleanup code after our Python callback returns (specifically at lines 1422-1429 in ares_process.c)\n3. If we destroy the channel too quickly, c-ares accesses freed memory\n\n### Impact\n\nApplications using `pycares` can be crashed remotely by triggering DNS queries that result in `Channel` objects being garbage collected before query completion. This is particularly problematic in scenarios where:\n\n- Channel objects are created per-request\n- Multiple failed DNS queries are processed rapidly\n- The application doesn\u0027t properly manage Channel lifecycle\n\nThe error manifests as:\n```\nFatal Python error: b_from_handle: ffi.from_handle() detected that the address passed points to garbage\n```\n\n## Fix\n\nThe vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism\n\n## Mitigation\n\n### For Application Developers\n\n1. **Upgrade to pycares \u003e= 4.9.0** - This version includes the fix and requires no code changes\n2. **Best practices** (optional but recommended):\n   ```python\n   # Explicit cleanup\n   channel.close()\n   \n   # Or use context manager\n   with pycares.Channel() as channel:\n       # ... use channel ...\n   # Automatically closed\n   ```\n3. **Avoid creating Channel objects per-request** - Prefer long-lived instances for better performance and safety\n\nThe fix is completely transparent - no API changes or code modifications are required.\n\n## Credit\n\nThis vulnerability was reported by @vEpiphyte through the aio-libs security program.",
  "id": "BREW-streamrip-CVE-2025-48945",
  "modified": "2026-09-17T18:13:36Z",
  "published": "2026-08-13T17:41:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/commit/ebfd7d71eb8e74bc1057a361ea79a5906db510d4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/saghul/pycares"
    }
  ],
  "schema_version": "1.7.3",
  "summary": "pycares has a Use-After-Free Vulnerability",
  "upstream": [
    "GHSA-5qpg-rh4j-qp35",
    "CVE-2025-48945"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pycares",
        "resource_purl": "pkg:pypi/pycares@5.0.1",
        "upstream_fixed_in": "4.9.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "theharvester",
        "purl": "pkg:brew/theharvester"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1"
            },
            {
              "fixed": "4.8.0_1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pycares@5.0.1",
        "name": "pycares",
        "resource": "pycares",
        "strategy": "registry",
        "subject_version": "5.0.1"
      }
    ]
  },
  "details": "## Summary\n\npycares is vulnerable to a use-after-free condition that occurs when a Channel object is garbage collected while DNS queries are still pending. This results in a fatal Python error and interpreter crash.\n\n## Details\n\n### Root Cause\n\nThe vulnerability stems from improper handling of callback references when the Channel object is destroyed:\n\n1. When a DNS query is initiated, pycares stores a callback reference using `ffi.new_handle()`\n2. If the Channel object is garbage collected while queries are pending, the callback references become invalid\n3. When c-ares attempts to invoke the callback, it accesses freed memory, causing a fatal error\n\nThis issue was much more likely to occur when using `event_thread=True` but could happen without it under the right circumstances.\n\n### Technical Details\n\nThe core issue is a race condition between Python\u0027s garbage collector and c-ares\u0027s callback execution:\n\n1. When `__del__` is called from within a c-ares callback context, we cannot immediately call `ares_destroy()` because c-ares is still executing code after the callback returns\n2. c-ares needs to execute cleanup code after our Python callback returns (specifically at lines 1422-1429 in ares_process.c)\n3. If we destroy the channel too quickly, c-ares accesses freed memory\n\n### Impact\n\nApplications using `pycares` can be crashed remotely by triggering DNS queries that result in `Channel` objects being garbage collected before query completion. This is particularly problematic in scenarios where:\n\n- Channel objects are created per-request\n- Multiple failed DNS queries are processed rapidly\n- The application doesn\u0027t properly manage Channel lifecycle\n\nThe error manifests as:\n```\nFatal Python error: b_from_handle: ffi.from_handle() detected that the address passed points to garbage\n```\n\n## Fix\n\nThe vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism\n\n## Mitigation\n\n### For Application Developers\n\n1. **Upgrade to pycares \u003e= 4.9.0** - This version includes the fix and requires no code changes\n2. **Best practices** (optional but recommended):\n   ```python\n   # Explicit cleanup\n   channel.close()\n   \n   # Or use context manager\n   with pycares.Channel() as channel:\n       # ... use channel ...\n   # Automatically closed\n   ```\n3. **Avoid creating Channel objects per-request** - Prefer long-lived instances for better performance and safety\n\nThe fix is completely transparent - no API changes or code modifications are required.\n\n## Credit\n\nThis vulnerability was reported by @vEpiphyte through the aio-libs security program.",
  "id": "BREW-theharvester-CVE-2025-48945",
  "modified": "2026-10-07T23:06:45Z",
  "published": "2026-08-13T17:43:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/commit/ebfd7d71eb8e74bc1057a361ea79a5906db510d4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/saghul/pycares"
    }
  ],
  "schema_version": "1.7.3",
  "summary": "pycares has a Use-After-Free Vulnerability",
  "upstream": [
    "GHSA-5qpg-rh4j-qp35",
    "CVE-2025-48945"
  ]
}

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "aiodns",
          "vendor": "aio-libs",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 4.9.0"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "pycares is a Python module which provides an interface to c-ares. c-ares is a C library that performs DNS requests and name resolutions asynchronously. Prior to version 4.9.0, pycares is vulnerable to a use-after-free condition that occurs when a Channel object is garbage collected while DNS queries are still pending. This results in a fatal Python error and interpreter crash. The vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism."
    },
    {
      "lang": "es",
      "value": "Pycares es un m\u00f3dulo de Python que proporciona una interfaz para c-ares. C-ares es una librer\u00eda de C que realiza solicitudes DNS y resoluciones de nombres de forma as\u00edncrona. En versiones anteriores a la 4.9.0, Pycares era vulnerable a una condici\u00f3n de use-after-free que se produce cuando un objeto de canal se recolecta como basura mientras las consultas DNS a\u00fan est\u00e1n pendientes. Esto provoca un error fatal de Python y un fallo del int\u00e9rprete. Esta vulnerabilidad se ha corregido en Pycares 4.9.0 mediante la implementaci\u00f3n de un mecanismo seguro de destrucci\u00f3n de canales."
    }
  ],
  "id": "CVE-2025-48945",
  "lastModified": "2026-06-17T09:30:31.813",
  "metrics": {
    "cvssMetricV40": [
      {
        "cvssData": {
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "attackComplexity": "LOW",
          "attackRequirements": "PRESENT",
          "attackVector": "NETWORK",
          "availabilityRequirement": "NOT_DEFINED",
          "baseScore": 8.2,
          "baseSeverity": "HIGH",
          "confidentialityRequirement": "NOT_DEFINED",
          "exploitMaturity": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "privilegesRequired": "NONE",
          "providerUrgency": "NOT_DEFINED",
          "subAvailabilityImpact": "NONE",
          "subConfidentialityImpact": "NONE",
          "subIntegrityImpact": "NONE",
          "userInteraction": "NONE",
          "valueDensity": "NOT_DEFINED",
          "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
          "version": "4.0",
          "vulnAvailabilityImpact": "HIGH",
          "vulnConfidentialityImpact": "NONE",
          "vulnIntegrityImpact": "NONE",
          "vulnerabilityResponseEffort": "NOT_DEFINED"
        },
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2025-48945",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2025-06-20T20:05:50.595661Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2025-06-20T20:15:33.570",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/aio-libs/aiodns/commit/f259a6e3650555157af53ac2b39f2ff545321d55"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/aio-libs/aiodns/releases/tag/v3.5.0"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/saghul/pycares/commit/ebfd7d71eb8e74bc1057a361ea79a5906db510d4"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/saghul/pycares/releases/tag/v4.9.0"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-416"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.8.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "pycares"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-16T16:09:47Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\npycares is vulnerable to a use-after-free condition that occurs when a Channel object is garbage collected while DNS queries are still pending. This results in a fatal Python error and interpreter crash.\n\n## Details\n\n### Root Cause\n\nThe vulnerability stems from improper handling of callback references when the Channel object is destroyed:\n\n1. When a DNS query is initiated, pycares stores a callback reference using `ffi.new_handle()`\n2. If the Channel object is garbage collected while queries are pending, the callback references become invalid\n3. When c-ares attempts to invoke the callback, it accesses freed memory, causing a fatal error\n\nThis issue was much more likely to occur when using `event_thread=True` but could happen without it under the right circumstances.\n\n### Technical Details\n\nThe core issue is a race condition between Python\u0027s garbage collector and c-ares\u0027s callback execution:\n\n1. When `__del__` is called from within a c-ares callback context, we cannot immediately call `ares_destroy()` because c-ares is still executing code after the callback returns\n2. c-ares needs to execute cleanup code after our Python callback returns (specifically at lines 1422-1429 in ares_process.c)\n3. If we destroy the channel too quickly, c-ares accesses freed memory\n\n### Impact\n\nApplications using `pycares` can be crashed remotely by triggering DNS queries that result in `Channel` objects being garbage collected before query completion. This is particularly problematic in scenarios where:\n\n- Channel objects are created per-request\n- Multiple failed DNS queries are processed rapidly\n- The application doesn\u0027t properly manage Channel lifecycle\n\nThe error manifests as:\n```\nFatal Python error: b_from_handle: ffi.from_handle() detected that the address passed points to garbage\n```\n\n## Fix\n\nThe vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism\n\n## Mitigation\n\n### For Application Developers\n\n1. **Upgrade to pycares \u003e= 4.9.0** - This version includes the fix and requires no code changes\n2. **Best practices** (optional but recommended):\n   ```python\n   # Explicit cleanup\n   channel.close()\n   \n   # Or use context manager\n   with pycares.Channel() as channel:\n       # ... use channel ...\n   # Automatically closed\n   ```\n3. **Avoid creating Channel objects per-request** - Prefer long-lived instances for better performance and safety\n\nThe fix is completely transparent - no API changes or code modifications are required.\n\n## Credit\n\nThis vulnerability was reported by @vEpiphyte through the aio-libs security program.",
  "id": "GHSA-5qpg-rh4j-qp35",
  "modified": "2025-06-16T16:09:47Z",
  "published": "2025-06-16T16:09:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/saghul/pycares/commit/ebfd7d71eb8e74bc1057a361ea79a5906db510d4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/saghul/pycares"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "pycares has a Use-After-Free Vulnerability"
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "python-pycares-debuginfo-4.9.0-1.oe2403sp1.aarch64.rpm",
          "python-pycares-debugsource-4.9.0-1.oe2403sp1.aarch64.rpm",
          "python-pycares-help-4.9.0-1.oe2403sp1.aarch64.rpm",
          "python3-pycares-4.9.0-1.oe2403sp1.aarch64.rpm"
        ],
        "src": [
          "python-pycares-4.9.0-1.oe2403sp1.src.rpm"
        ],
        "x86_64": [
          "python-pycares-debuginfo-4.9.0-1.oe2403sp1.x86_64.rpm",
          "python-pycares-debugsource-4.9.0-1.oe2403sp1.x86_64.rpm",
          "python-pycares-help-4.9.0-1.oe2403sp1.x86_64.rpm",
          "python3-pycares-4.9.0-1.oe2403sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP1",
        "name": "python-pycares",
        "purl": "pkg:rpm/openEuler/python-pycares\u0026distro=openEuler-24.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.9.0-1.oe2403sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Medium"
  },
  "details": "pycares is a Python module which provides an interface to c-ares.c-ares is a C library that performs DNS requests and name resolutions asynchronously.\r\n\r\nSecurity Fix(es):\n\npycares is a Python module which provides an interface to c-ares. c-ares is a C library that performs DNS requests and name resolutions asynchronously. Prior to version 4.9.0, pycares is vulnerable to a use-after-free condition that occurs when a Channel object is garbage collected while DNS queries are still pending. This results in a fatal Python error and interpreter crash. The vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism.(CVE-2025-48945)",
  "id": "OESA-2025-1810",
  "modified": "2026-08-06T11:08:53Z",
  "published": "2025-07-11T11:08:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1810"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48945"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "python-pycares security update",
  "upstream": [
    "CVE-2025-48945"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "python-pycares-debuginfo-4.9.0-1.oe2203sp3.aarch64.rpm",
          "python-pycares-debugsource-4.9.0-1.oe2203sp3.aarch64.rpm",
          "python-pycares-help-4.9.0-1.oe2203sp3.aarch64.rpm",
          "python3-pycares-4.9.0-1.oe2203sp3.aarch64.rpm"
        ],
        "src": [
          "python-pycares-4.9.0-1.oe2203sp3.src.rpm"
        ],
        "x86_64": [
          "python-pycares-debuginfo-4.9.0-1.oe2203sp3.x86_64.rpm",
          "python-pycares-debugsource-4.9.0-1.oe2203sp3.x86_64.rpm",
          "python-pycares-help-4.9.0-1.oe2203sp3.x86_64.rpm",
          "python3-pycares-4.9.0-1.oe2203sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "python-pycares",
        "purl": "pkg:rpm/openEuler/python-pycares\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.9.0-1.oe2203sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Medium"
  },
  "details": "pycares is a Python module which provides an interface to c-ares.c-ares is a C library that performs DNS requests and name resolutions asynchronously.\r\n\r\nSecurity Fix(es):\n\npycares is a Python module which provides an interface to c-ares. c-ares is a C library that performs DNS requests and name resolutions asynchronously. Prior to version 4.9.0, pycares is vulnerable to a use-after-free condition that occurs when a Channel object is garbage collected while DNS queries are still pending. This results in a fatal Python error and interpreter crash. The vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism.(CVE-2025-48945)",
  "id": "OESA-2025-1811",
  "modified": "2026-08-06T11:08:53Z",
  "published": "2025-07-11T11:08:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1811"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48945"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "python-pycares security update",
  "upstream": [
    "CVE-2025-48945"
  ]
}