CVE-2026-93395 in C Driver
Summary
by MITRE • 09/18/2026
A missing lower-bound validation in the bson_new_from_buffer() function of libbson allows an integer underflow when processing BSON data with a zero-length prefix. The function reads a 32-bit document length from the input buffer but does not verify that the value is at least 5 (the minimum valid BSON document size) before using it in an array index calculation. When the length field is zero, the expression used to check the document's null terminator wraps to UINT32_MAX, causing a heap out-of-bounds read that crashes the process. An unauthorized party who can supply crafted BSON input to an application using this API can cause a denial of service.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in libbson centers on a critical missing lower-bound validation within the bson_new_from_buffer() function, which serves as a primary entry point for parsing Binary JSON data into internal structures. This flaw allows for integer underflow conditions when processing BSON documents that contain a zero-length prefix or otherwise invalid length fields. The core technical issue arises because the function retrieves a 32-bit unsigned integer representing the document size from the input buffer but fails to verify that this value meets the minimum structural requirements of a valid BSON object, which is five bytes comprising four bytes for the length and one byte for the null terminator. By omitting this essential boundary check, the application proceeds with arithmetic operations on an insufficiently validated variable, leading directly to memory safety violations.
When the length field in the crafted input is set to zero or a value smaller than the minimum valid BSON document size, subsequent calculations involving array indexing and buffer bounds checking become compromised. Specifically, the expression used to verify the presence of the null terminator at the end of the document performs an arithmetic operation that wraps around due to unsigned integer underflow rules. Instead of detecting an invalid structure, the calculation results in a value equivalent to UINT32_MAX, which is significantly larger than any reasonable buffer size allocated for the BSON object. This erroneous result causes the application to attempt reading memory far beyond the bounds of the allocated heap region, resulting in a heap out-of-bounds read operation.
The operational impact of this vulnerability is primarily a denial of service condition affecting applications that rely on libbson for parsing untrusted or semi-trusted data sources. An unauthorized attacker who can supply crafted BSON input to an application utilizing this API can trigger the integer underflow and subsequent memory access violation, causing the process to crash immediately upon processing the malformed document. This stability issue disrupts availability and can be leveraged in distributed denial-of-service attacks if the vulnerable component is exposed via a network service or message queue that accepts arbitrary BSON payloads without prior validation.
From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound, as the root cause is the failure to handle arithmetic operations on unsigned integers correctly when input values are outside expected ranges. It also relates closely to CWE-20 Improper Input Validation, specifically the lack of boundary checks for minimum valid sizes before processing. In terms of attack vectors and techniques, this scenario corresponds to ATT&CK technique T1496 Resource Hijacking under Denial of Service, where an attacker consumes system resources or causes service disruption through malformed input that exploits logic errors in data parsing routines rather than exploiting complex memory corruption chains for code execution.
Mitigation strategies must focus on enforcing strict validation at the earliest possible stage of data ingestion. Developers should implement explicit checks to ensure that any BSON document length field is greater than or equal to five bytes before proceeding with further processing steps such as array indexing or null terminator verification. Additionally, integrating fuzzing tools into the continuous integration pipeline can help identify similar boundary condition flaws across other parsing functions within libbson. For end-users and application developers, applying patches provided by the library maintainers that address this specific validation gap is essential to restore secure operation and prevent potential denial-of-service incidents caused by malformed BSON inputs.