Agronholm vulnerabilities
7 vulnerabilities
Known vulnerabilities in Agronholm products, newest first, with CVSS severity, EPSS, KEV listings and ransomware use, across 2 products.
Products
2CVE-2025-68131agronholmcbor2+14
EPSS score0.46%
cbor2 provides encoding and decoding for the Concise Binary Object Representation (CBOR) serialization format. Starting in version 3.0.0 and prior to version 5.8.0, whhen a CBORDecoder instance is reused across multiple decode operations, values marked with the shareable tag (28) persist in memory and can be accessed by subsequent CBOR messages using the sharedref tag (29). This allows an attacker-controlled message to read data from previously decoded messages if the decoder is reused across trust boundaries. Version 5.8.0 patches the issue.CVE-2025-64076agronholmcbor2+3EPSS score0.49%
Multiple vulnerabilities exist in cbor2 through version 5.7.0 in the decode_definite_long_string() function of the C extension decoder (source/decoder.c): (1) Integer Underflow Leading to Out-of-Bounds Read (CWE-191, CWE-125): An incorrect variable reference and missing state reset in the chunk processing loop causes buffer_length to not be reset to zero after UTF-8 character consumption. This results in subsequent chunk_length calculations producing negative values (e.g., chunk_length = 65536 - buffer_length), which are passed as signed integers to the read() method, potentially triggering unlimited read operations and resource exhaustion. (2) Memory Leak via Missing Reference Count Release (CWE-401): The main processing loop fails to release Python object references (Py_DECREF) for chunk objects allocated in each iteration. For CBOR strings longer than 65536 bytes, this causes cumulative memory leaks proportional to the payload size, enabling memory exhaustion attacks through repeated processing of large CBOR payloads. Both vulnerabilities can be exploited remotely without authentication by sending specially-crafted CBOR data containing definite-length text strings with multi-byte UTF-8 characters positioned at 65536-byte chunk boundaries. Successful exploitation results in denial of service through process crashes (CBORDecodeEOF exceptions) or memory exhaustion. The vulnerabilities affect all applications using cbor2's C extension to process untrusted CBOR data, including web APIs, IoT data collectors, and message queue processors. Fixed in commit 851473490281f82d82560b2368284ef33cf6e8f9 pushed with released version 5.7.1.CVE-2024-26134agronholmcbor2+5EPSS score1.18%
cbor2 provides encoding and decoding for the Concise Binary Object Representation (CBOR) (RFC 8949) serialization format. Starting in version 5.5.1 and prior to version 5.6.2, an attacker can crash a service using cbor2 to parse a CBOR binary by sending a long enough object. Version 5.6.2 contains a patch for this issue.CVE-2026-63374agronholmanyio+22EPSS score0.29%
AnyIO is a high level asynchronous concurrency and networking framework that works on top of either Trio or asyncio. Prior to 4.14.2, connect_tcp() and TLSStream.wrap() can validate internationalized host names after the standard library converts them with IDNA 2003 instead of IDNA 2008. When a connection to a non-ASCII domain is hijacked or redirected, an attacker can obtain a legitimate certificate for the different ASCII hostname produced by IDNA 2003 and present it to the client, causing the malicious endpoint's certificate to validate. This issue is fixed in version 4.14.2.CVE-2026-63349agronholmanyio+3EPSS score0.11%
AnyIO is a high level asynchronous concurrency and networking framework that works on top of either Trio or asyncio. In 4.14.0, AnyIO accepts the POSIX extra_groups argument in anyio.run_process() and anyio.open_process(), but open_process() forwards the group argument to the backend instead of extra_groups. A caller that supplies extra_groups=[] to clear inherited supplementary groups can therefore launch a child that retains the parent process groups, undermining a privilege-dropping boundary. If group is also supplied, the integer group value is passed where an iterable of supplementary groups is expected and the launch can fail with TypeError. This issue affects POSIX applications that rely on AnyIO subprocess helpers to launch less-privileged child processes. This issue is fixed in version 4.14.2.CVE-2026-26209agronholmcbor2+16EPSS score0.65%
cbor2 provides encoding and decoding for the Concise Binary Object Representation (CBOR) serialization format. Versions prior to 5.9.0 are vulnerable to a Denial of Service (DoS) attack caused by uncontrolled recursion when decoding deeply nested CBOR structures. This vulnerability affects both the pure Python implementation and the C extension `_cbor2`. The C extension relies on Python's internal recursion limits `Py_EnterRecursiveCall` rather than a data-driven depth limit, meaning it still raises `RecursionError` and crashes the worker process when the limit is hit. While the library handles moderate nesting levels, it lacks a hard depth limit. An attacker can supply a crafted CBOR payload containing approximately 100,000 nested arrays `0x81`. When `cbor2.loads()` attempts to parse this, it hits the Python interpreter's maximum recursion depth or exhausts the stack, causing the process to crash with a `RecursionError`. Because the library does not enforce its own limits, it allows an external attacker to exhaust the host application's stack resource. In many web application servers (e.g., Gunicorn, Uvicorn) or task queues (Celery), an unhandled `RecursionError` terminates the worker process immediately. By sending a stream of these small (<100KB) malicious packets, an attacker can repeatedly crash worker processes, resulting in a complete Denial of Service for the application. Version 5.9.0 patches the issue.CVE-2026-64847agronholmanyio+22EPSS score0.16%
AnyIO is a high level asynchronous concurrency and networking framework that works on top of either Trio or asyncio. Prior to 4.14.2, AnyIO starts process-pool workers with standard error connected to a pipe that the parent never drains, even though the documented behavior redirects all three standard streams. Worker code that writes enough attacker-influenced data to sys.stderr can fill the pipe and block before returning the standard-output protocol response, causing the awaiting process-pool call to remain blocked indefinitely. Applications that run untrusted or faulty worker code capable of producing substantial standard-error output are affected. This issue is fixed in version 4.14.2.