{"id":"CVE-2025-48945","aliases":["GHSA-5qpg-rh4j-qp35"],"title":"pycares has a Use-After-Free Vulnerability","summary":"pycares has a Use-After-Free Vulnerability","severity":"medium","vendor":"pycares","product":"pycares","ecosystem":"pip","affected":["pycares < 4.9.0"],"patched":["pycares 4.9.0"],"published":"2025-06-16","updated":"2026-09-10","sourceUpdated":"2026-09-10T03:50:24.913361759Z","source":"OSV","sourceUrl":"https://osv.dev/vulnerability/GHSA-5qpg-rh4j-qp35","references":[{"url":"https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"},{"url":"https://github.com/saghul/pycares/commit/ebfd7d71eb8e74bc1057a361ea79a5906db510d4"},{"url":"https://github.com/saghul/pycares"}],"tags":["osv","pip"],"epss":0.00484,"epssPercentile":0.40716,"ingestedAt":"2026-09-12T03:13:01.661Z","slug":"CVE-2025-48945","body":"## Overview\n\n## 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's garbage collector and c-ares's 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't 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 >= 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.\n\n## Affected packages\n\n- `pycares < 4.9.0`\n\n## Remediation\n\nUpgrade to a patched release:\n\n- `pycares 4.9.0`","depth":"sunlit","depthScore":28,"depthScoreParts":{"impact":27.5,"likelihood":0.1,"exploitation":0,"ransomware":0},"changes":[]}