CVE-2025-68131
Information Disclosure in cbor2 Decoder via Shared Reference Tag
Publication date: 2025-12-31
Last updated on: 2025-12-31
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| agronholm | cbor2 | 5.8.0 |
| agronholm | cbor2 | 3.0.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-212 | The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in the cbor2 Python package occurs when a CBORDecoder instance is reused across multiple decode operations without properly clearing its internal 'shareables' list. Values tagged as shareable (tag 28) persist in memory and can be accessed by subsequent CBOR messages using the sharedref tag (29). This means an attacker can craft a malicious CBOR message that reads data from previously decoded messages if the decoder is reused across trust boundaries, leading to unintended information disclosure. [2]
How can this vulnerability impact me? :
The vulnerability can lead to information disclosure by allowing attacker-controlled CBOR messages to access sensitive data from previously decoded messages when the same CBORDecoder instance is reused. This can expose confidential information such as credentials or tokens. Additionally, improper reuse of the encoder can cause invalid CBOR data, decoding failures, denial of service, silent data corruption, and memory leaks. [2]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection involves identifying if your system uses the cbor2 Python package versions 3.0.0 up to but not including 5.8.0, and whether CBORDecoder instances are reused across multiple decode operations without proper resetting. There are no specific network detection commands provided. However, you can check the installed cbor2 version with the command `pip show cbor2` or `pip list | grep cbor2`. To detect potential exploitation, monitor for unexpected access to sensitive data during CBOR decoding or unusual CBOR messages containing shareable (tag 28) and sharedref (tag 29) tags. Since the vulnerability is in the decoding logic, static code analysis or runtime instrumentation to check reuse of CBORDecoder instances without resetting shareables may help. No explicit commands for detection are provided in the resources. [2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading the cbor2 package to version 5.8.0 or later, where the issue is fixed. If upgrading is not immediately possible, avoid reusing CBORDecoder instances across multiple decode operations without resetting their internal state, specifically the shareables list. Implement proper resetting of the decoder state between decode calls or create a new CBORDecoder instance for each decode operation. Additionally, ensure that decode operations are not performed across trust boundaries using the same decoder instance. These steps prevent attacker-controlled messages from accessing data from previous decode operations. [2]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability can lead to information disclosure by allowing attacker-controlled CBOR messages to access sensitive data from previously decoded messages if the same CBORDecoder instance is reused across trust boundaries. Such unauthorized data exposure could result in non-compliance with data protection regulations like GDPR and HIPAA, which mandate strict controls on the confidentiality and integrity of personal and sensitive information. [2]