<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-18T08:36:15.590163+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2025-48945</id>
    <title>CVE-2025-48945 — pycares has a Use-After-Free Vulnerability</title>
    <updated>2026-10-18T08:36:15.592604+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> aio-libs aiodns</p>
<p>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.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2025-48945"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-5qpg-rh4j-qp35</id>
    <title>GHSA-5qpg-rh4j-qp35 — pycares has a Use-After-Free Vulnerability</title>
    <updated>2026-10-18T08:36:15.592656+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: pycares</p>
<p>## Summary</p>
<p>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.</p>
<p>## Details</p>
<p>### Root Cause</p>
<p>The vulnerability stems from improper handling of callback references when the Channel object is destroyed:</p>
<p>1. When a DNS query is initiated, pycares stores a callback reference using `ffi.new_handle()`
2. If the Channel object is garbage collected while queries are pending, the callback references become invalid
3. When c-ares attempts to invoke the callback, it accesses freed memory, causing a fatal error</p>
<p>This issue was much more likely to occur when using `event_thread=True` but could happen without it under the right circumstances.</p>
<p>### Technical Details</p>
<p>The core issue is a race condition between Python's garbage collector and c-ares's callback execution:</p>
<p>1. 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
2. c-ares needs to execute cleanup code after our Python callback returns (specifically at lines 1422-1429 in ares_process.c)
3. If we destroy the channel too quickly, c-ares accesses freed memory</p>
<p>### Impact</p>
<p>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 i…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-5qpg-rh4j-qp35"/>
  </entry>
</feed>
