CVE-2025-68131: Cbor2 Information Disclosure Vulnerability

CVE-2025-68131 Overview

CVE-2025-68131 is an information disclosure vulnerability in cbor2, a Python library that 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, 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.

Critical Impact

An attacker can craft malicious CBOR messages to extract sensitive data from previously decoded messages when decoder instances are shared across trust boundaries, leading to cross-message information leakage.

Affected Products

• agronholm cbor2 versions 3.0.0 through 5.7.x
• Python applications using cbor2 with shared decoder instances
• Systems processing CBOR data from multiple untrusted sources with a single decoder

Discovery Timeline

• December 31, 2025 - CVE-2025-68131 published to NVD
• January 2, 2026 - Last updated in NVD database

Technical Details for CVE-2025-68131

Vulnerability Analysis

This vulnerability falls under CWE-212 (Improper Removal of Sensitive Information Before Storage or Transfer). The core issue lies in how the cbor2 library handles CBOR's built-in reference mechanism across multiple decode operations. CBOR supports a shareable tag (28) that allows values to be marked for later reference, and a sharedref tag (29) that references previously shared values by index.

When a CBORDecoder instance processes a CBOR message containing shareable-tagged values, these values are stored in an internal reference table. The vulnerability occurs because this reference table is not cleared between decode operations when the same decoder instance is reused. Consequently, a subsequent CBOR message containing sharedref tags can reference values from previously decoded messages, even if those messages originated from different trust contexts.

The attack requires network access and can be exploited without authentication or user interaction. The vulnerability results in limited confidentiality and availability impact, as attackers can only access data that was previously marked as shareable in earlier decode operations.

Root Cause

The root cause is insufficient state isolation in the CBORDecoder class. When the decoder is instantiated and used for multiple decode operations, the internal reference table that tracks shareable values persists across invocations. This design assumes that all decoded messages share the same trust context, which is not always the case in real-world applications where a single decoder instance might process data from multiple sources.

Attack Vector

The attack vector requires an adversary to send a specially crafted CBOR message to a system that reuses CBORDecoder instances across trust boundaries. The attacker's message would contain sharedref tags (29) with indices pointing to values that were marked as shareable in previously decoded legitimate messages. When the victim's application decodes the malicious message using the same decoder instance, the attacker gains access to data from the earlier messages.

The exploitation scenario typically involves:

1. A legitimate user sends CBOR data containing shareable-tagged sensitive values
2. The application decodes this data using a shared CBORDecoder instance
3. An attacker sends a crafted CBOR message with sharedref tags referencing the previous message's indices
4. The decoder resolves these references using the stale reference table, exposing the legitimate user's data

Detection Methods for CVE-2025-68131

Indicators of Compromise

• Unexpected sharedref tag (29) usage in incoming CBOR messages with high index values
• CBOR decode errors or unexpected data in applications that don't intentionally use shareable/sharedref tags
• Anomalous patterns of CBOR message sequences where smaller messages follow larger ones
• Application logs showing unexpected value types being returned from CBOR decode operations

Detection Strategies

• Audit application code for CBORDecoder instances that are reused across multiple decode calls, especially those processing data from different sources
• Monitor for CBOR messages containing tag 29 (sharedref) when the application doesn't explicitly use the shareable reference feature
• Implement input validation to reject CBOR messages with sharedref tags if the feature is not required by the application
• Review Python dependency manifests for cbor2 versions between 3.0.0 and 5.7.x

Monitoring Recommendations

• Enable verbose logging for CBOR decode operations to track tag usage patterns
• Implement application-level monitoring to detect when sharedref tags reference indices beyond expected bounds
• Set up dependency scanning in CI/CD pipelines to flag vulnerable cbor2 versions
• Monitor for security advisories related to cbor2 via the GitHub Security Advisory

How to Mitigate CVE-2025-68131

Immediate Actions Required

• Upgrade cbor2 to version 5.8.0 or later immediately
• Audit existing code for patterns where CBORDecoder instances are shared across trust boundaries
• As a temporary measure, create new CBORDecoder instances for each decode operation rather than reusing instances
• Review application architecture to ensure CBOR decoding isolates data from different trust contexts

Patch Information

The vulnerability has been patched in cbor2 version 5.8.0. The fix ensures that the internal reference table used for shareable/sharedref tag resolution is properly cleared between decode operations, preventing cross-message information leakage.

For detailed patch information, refer to the GitHub Pull Request #268 and the GitHub Security Advisory GHSA-wcj4-jw5j-44wh.

Workarounds

• Create a new CBORDecoder instance for each decode operation instead of reusing decoder objects
• Implement trust boundary isolation by using separate decoder instances for data from different sources
• If shareable/sharedref tags are not required, consider implementing input validation to reject messages containing these tags
• Apply defense-in-depth by sanitizing or encrypting sensitive data before CBOR encoding

# Upgrade cbor2 to the patched version
pip install --upgrade cbor2>=5.8.0

# Verify the installed version
pip show cbor2 | grep Version