cbor2 up to 5.7.0 source/decoder.c decode_definite_long_string resource consumption

Summaryinfo

A vulnerability marked as problematic has been reported in cbor2 up to 5.7.0. This vulnerability affects the function decode_definite_long_string of the file source/decoder.c. The manipulation leads to resource consumption. This vulnerability is traded as CVE-2025-64076. It is possible to initiate the attack remotely. There is no exploit available. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability was found in cbor2 up to 5.7.0. It has been rated as problematic. This issue affects the function decode_definite_long_string of the file source/decoder.c. The manipulation with an unknown input leads to a resource consumption vulnerability. Using CWE to declare the problem leads to CWE-400. The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources. Impacted is availability. The summary by CVE is:

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.

It is possible to read the advisory at github.com. The identification of this vulnerability is CVE-2025-64076 since 10/27/2025. The exploitation is known to be easy. The attack may be initiated remotely. No form of authentication is needed for a successful exploitation. Technical details of the vulnerability are known, but there is no available exploit. The attack technique deployed by this issue is T1499 according to MITRE ATT&CK.

The vulnerability scanner Nessus provides a plugin with the ID 275748 (Linux Distros Unpatched Vulnerability : CVE-2025-64076), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 5.7.1 eliminates this vulnerability. Applying the patch 851473490281f82d82560b2368284ef33cf6e8f9 is able to eliminate this problem. The bugfix is ready for download at github.com. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (275748) and EUVD (EUVD-2025-198054). Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Name

• cbor2

Version

• 5.0
• 5.1
• 5.2
• 5.3
• 5.4
• 5.5
• 5.6
• 5.7.0

License

• open-source

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion