Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
- The cbor2 library is 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 correctly uses Python's C-API for recursion protection (PyEnterRecursiveCall), but this mechanism is designed to prevent a stack overflow by raising a RecursionError. In some environments, this exception is not caught, thus causing the service process to terminate. - While the library handles moderate nesting, it lacks a configurable, data-driven depth limit independent of Python's global recursion setting. An attacker can supply a crafted CBOR payload containing thousands of nested arrays (e.g., 0x81). When cbor2.loads() attempts to parse this, it hits the interpreter's recursion limit, causing the call to raise a RecursionError. - By sending a stream of small (<100KB) malicious packets, an attacker can repeatedly crash…
Recommended action: Upgrade to 5.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When 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. Details The issue is in the decoder's handling of the shareables list, which stores values tagged with CBOR tag 28 (shareable) for later reference by tag 29 (sharedref). When decodefrombytes() is called or when .fp is set to a new stream, the shareables list is not cleared. This allows references to persist across separate decode operations. The issue exists in both the C extension and the pure Python decoder. In the C extension (source/decoder.c), the CBORDecodersetfp function (line ~202) updates the file pointer but does not reset the shareables state: In the pure Python decoder (cbor2/decoder.py), the fp setter similarly fails to…
Recommended action: Upgrade to 5.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Multiple vulnerabilities exist in cbor2 through version 5.7.0 in the decodedefinitelongstring() 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 bufferlength to not be reset to zero after UTF-8 character consumption. This results in subsequent chunklength calculations producing negative values (e.g., chunklength = 65536 - bufferlength), 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 (PyDECREF) 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…
Recommended action: Upgrade to 5.7.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ever since https://github.com/agronholm/cbor2/pull/204 (or specifically https://github.com/agronholm/cbor2/commit/387755eacf0be35591a478d3c67fe10618a6d542) was merged, I can create a reproducible crash when running the snippet under PoC on a current Debian bullseye aarm64 on a Raspberry Pi 3 (I was not able to reproduce this on my x8664 Laptop with Python 3.11; I suspect because there is enough memory to allocate still) Details PoC If one calls it without the indirection via the pool executor, a SystemError is shown that hides the buffer overflow. Impact An attacker can crash a service using cbor2 to parse a CBOR binary by sending a long enough object.
Recommended action: Upgrade to 5.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.