Package Instance

HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "url": "http://public2.vulnerablecode.io/api/packages/809354?format=api",
    "purl": "pkg:pypi/pycares@3.2.3",
    "type": "pypi",
    "namespace": "",
    "name": "pycares",
    "version": "3.2.3",
    "qualifiers": {},
    "subpath": "",
    "is_vulnerable": true,
    "next_non_vulnerable_version": "4.9.0",
    "latest_non_vulnerable_version": "4.9.0",
    "affected_by_vulnerabilities": [
        {
            "url": "http://public2.vulnerablecode.io/api/vulnerabilities/360792?format=api",
            "vulnerability_id": "VCID-gk1r-ur2p-mqfn",
            "summary": "pycares has a Use-After-Free Vulnerability\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.",
            "references": [
                {
                    "reference_url": "https://github.com/saghul/pycares",
                    "reference_id": "",
                    "reference_type": "",
                    "scores": [
                        {
                            "value": "MODERATE",
                            "scoring_system": "generic_textual",
                            "scoring_elements": ""
                        }
                    ],
                    "url": "https://github.com/saghul/pycares"
                },
                {
                    "reference_url": "https://github.com/advisories/GHSA-5qpg-rh4j-qp35",
                    "reference_id": "GHSA-5qpg-rh4j-qp35",
                    "reference_type": "",
                    "scores": [],
                    "url": "https://github.com/advisories/GHSA-5qpg-rh4j-qp35"
                },
                {
                    "reference_url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35",
                    "reference_id": "GHSA-5qpg-rh4j-qp35",
                    "reference_type": "",
                    "scores": [
                        {
                            "value": "MODERATE",
                            "scoring_system": "generic_textual",
                            "scoring_elements": ""
                        }
                    ],
                    "url": "https://github.com/saghul/pycares/security/advisories/GHSA-5qpg-rh4j-qp35"
                }
            ],
            "fixed_packages": [
                {
                    "url": "http://public2.vulnerablecode.io/api/packages/378756?format=api",
                    "purl": "pkg:pypi/pycares@4.9.0",
                    "is_vulnerable": false,
                    "affected_by_vulnerabilities": [],
                    "resource_url": "http://public2.vulnerablecode.io/packages/pkg:pypi/pycares@4.9.0"
                }
            ],
            "aliases": [
                "GHSA-5qpg-rh4j-qp35"
            ],
            "risk_score": 3.1,
            "exploitability": "0.5",
            "weighted_severity": "6.2",
            "resource_url": "http://public2.vulnerablecode.io/vulnerabilities/VCID-gk1r-ur2p-mqfn"
        }
    ],
    "fixing_vulnerabilities": [],
    "risk_score": "3.1",
    "resource_url": "http://public2.vulnerablecode.io/packages/pkg:pypi/pycares@3.2.3"
}