Summary
pycares has a Use-After-Free Vulnerability
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.
Details
Root Cause
The vulnerability stems from improper handling of callback references when the Channel object is destroyed:
- When a DNS query is initiated, pycares stores a callback reference using
ffi.new_handle() - If the Channel object is garbage collected while queries are pending, the callback references become invalid
- When c-ares attempts to invoke the callback, it accesses freed memory, causing a fatal error
This issue was much more likely to occur when using event_thread=True but could happen without it under the right circumstances.
Technical Details
The core issue is a race condition between Python's garbage collector and c-ares's callback execution:
- When
__del__is called from within a c-ares callback context, we cannot immediately callares_destroy()because c-ares is still executing code after the callback returns - c-ares needs to execute cleanup code after our Python callback returns (specifically at lines 1422-1429 in ares_process.c)
- If we destroy the channel too quickly, c-ares accesses freed memory
Mitigation
For Application Developers
- Upgrade to pycares >= 4.9.0 - This version includes the fix and requires no code changes
- Best practices (optional but recommended):
# Explicit cleanup channel.close() # Or use context manager with pycares.Channel() as channel: # ... use channel ... # Automatically closed - Avoid creating Channel objects per-request - Prefer long-lived instances for better performance and safety
The fix is completely transparent - no API changes or code modifications are required.
Credit
This vulnerability was reported by @vEpiphyte through the aio-libs security program.
Impact
Applications 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:
- Channel objects are created per-request
- Multiple failed DNS queries are processed rapidly
- The application doesn't properly manage Channel lifecycle
The error manifests as:
Fatal Python error: b_from_handle: ffi.from_handle() detected that the address passed points to garbage
Memory is accessed after it has been freed, leading to undefined behavior in native code. Typical impact: memory corruption, crash, or potential code execution.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
The vulnerability has been fixed in pycares 4.9.0 by implementing a safe channel destruction mechanism
Frequently Asked Questions
- What is GHSA-5QPG-RH4J-QP35? GHSA-5QPG-RH4J-QP35 is a medium-severity use after free vulnerability in pycares (pip), affecting versions <= 4.8.0. It is fixed in 4.9.0. Memory is accessed after it has been freed, leading to undefined behavior in native code.
- Which versions of pycares are affected by GHSA-5QPG-RH4J-QP35? pycares (pip) versions <= 4.8.0 is affected.
- Is there a fix for GHSA-5QPG-RH4J-QP35? Yes. GHSA-5QPG-RH4J-QP35 is fixed in 4.9.0. Upgrade to this version or later.
- Is GHSA-5QPG-RH4J-QP35 exploitable, and should I be worried? Whether GHSA-5QPG-RH4J-QP35 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-5QPG-RH4J-QP35 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-5QPG-RH4J-QP35? Upgrade
pycaresto 4.9.0 or later.