CVE-2025-64076: 
Python vulnerability analysis and mitigation

CVE-2025-64076 describes two related vulnerabilities in the cbor2 Python library's C extension decoder (source/decoder.c) affecting all versions through 5.7.0. The first is an integer underflow (CWE-191) leading to an out-of-bounds read (CWE-125) in the decode_definite_long_string() function, and the second is a memory leak (CWE-401) due to missing Python reference count releases. Both were publicly disclosed on November 18, 2025, with a patch merged on October 22, 2025 and released in version 5.7.1. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (Red Hat Advisory, Feedly).

The root cause lies in two bugs within the decode_definite_long_string() function of cbor2's C extension. First, an incorrect variable reference (buffer_size instead of buffer_length) and a missing state reset cause buffer_length to retain its old value after UTF-8 leftover bytes are consumed at a 65536-byte chunk boundary. In the next loop iteration, chunk_length = 65536 - buffer_length produces a negative value (e.g., -1), which is passed as a signed integer to the read() method, triggering an unlimited read and ultimately a CBORDecodeEOF exception. Second, the loop fails to call Py_DECREF() on chunk objects allocated in each iteration, causing cumulative memory leaks proportional to payload size for CBOR strings exceeding 65536 bytes. Both issues are exploitable remotely without authentication by sending a crafted CBOR definite-length text string containing multi-byte UTF-8 characters (e.g., €, U+20AC, encoded as 3 bytes) positioned at 65536-byte chunk boundaries (GitHub Issue #264, GitHub PR #265, Patch Commit).

Successful exploitation results in denial of service through either process crashes (via CBORDecodeEOF exceptions triggered by the read(-1) call) or memory exhaustion caused by the cumulative reference leak. There is no confidentiality or integrity impact — the vulnerability is purely an availability concern. Applications that process untrusted CBOR data using the cbor2 C extension (the default accelerated backend) are at risk; repeated submission of crafted payloads can exhaust process memory or crash the decoder, potentially taking down dependent services (Red Hat Advisory, GitHub Issue #264).

No in-the-wild exploitation has been reported, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. A public proof-of-concept reproducer was published in the GitHub issue tracker by the reporter (tylzh97) on October 21, 2025, demonstrating the read(-1) behavior with a simple Python script. The EPSS score is 0.086% (very low probability of exploitation in the near term). No threat actor attribution is available (GitHub Issue #264, Feedly).

1. Identify target: Locate a network-accessible service that accepts and decodes untrusted CBOR data using the cbor2 Python library (C extension, version ≤ 5.7.0).
2. Craft the payload: Construct a CBOR definite-length text string (major type 3) whose byte content places a multi-byte UTF-8 character (e.g., € = \xe2\x82\xac) straddling a 65536-byte chunk boundary. A minimal example: 65535 ASCII bytes + € (3 bytes) + additional content, encoded with a 4-byte length prefix (\x7a + struct.pack('>I', total_bytes)).
3. Submit the payload: Send the crafted CBOR bytes to the target service's input endpoint (e.g., HTTP POST body, WebSocket message, or any CBOR-consuming API).
4. Trigger the bug: The C extension decoder processes the first 65536-byte chunk, retains a non-zero buffer_length for the UTF-8 leftover, and on the next iteration computes chunk_length = 65536 - buffer_length < 0, passing a negative value to read().
5. Achieve DoS: The read(-1) call causes a CBORDecodeEOF exception, crashing the decoder. For memory exhaustion, repeatedly send large (>65536-byte) CBOR strings to accumulate unreleased chunk object references until the process runs out of memory (GitHub Issue #264, GitHub PR #265).

• Logs: Application logs showing repeated CBORDecodeEOF: premature end of stream (expected to read -1 bytes, got N instead) exceptions originating from the cbor2 C extension decoder.
• Process: Abnormal memory growth in Python processes that handle CBOR data, particularly when processing large payloads; process crashes or restarts correlated with CBOR input handling.
• Network: Unusual or repeated submissions of large CBOR-encoded payloads (>65535 bytes) containing multi-byte UTF-8 sequences to CBOR-consuming endpoints, especially from a single source IP (GitHub Issue #264).

Upgrade cbor2 to version 5.7.1 or later, which includes the fix applied in commit 8514734 that corrects the buffer_size→buffer_length variable reference, adds the missing buffer_length = 0 reset, and adds Py_DECREF(chunk) to release chunk objects. As a temporary workaround, applications can force use of the pure-Python cbor2 decoder (which is not affected) by importing cbor2.decoder directly rather than the C extension _cbor2, though this reduces performance. Input validation to reject unexpectedly large CBOR payloads can also reduce exposure (Patch Commit, GitHub PR #265).

Red Hat tracked the vulnerability and published a security advisory. The openSUSE and Fedora Linux distributions issued security updates for their python-cbor2 packages in response to this CVE. The cbor2 project maintainer (agronholm) noted upon reviewing the fix PR that the reference leak made the vulnerability "even worse than I thought," highlighting that memory DoS was more easily achievable than initially anticipated (Red Hat Advisory, GitHub PR #265).