MongoDB C Driver CVE-2026-106431

Exploitation requires that the embedding application use the BSON bulk-writer API of the MongoDB C Driver (libmongoc) AND that an attacker be able to influence the sizes of the documents it serializes. The off-by-one write triggers only when a document ends at a specific internal buffer boundary - the attacker must drive the cumulative serialized document size to that exact value, a precise and largely non-deterministic precondition (reflected as AT:P in the CVSS 4.0 vector). Limiting factors: applications that do not use the bulk-writer code path are not affected; the attacker cannot reach the flaw directly over the network but only indirectly through application-controlled serialization; and the defect writes only a single zero byte, so the realistic outcome is heap corruption leading to process termination rather than reliable arbitrary code execution.

This is a medium-severity (CVSS 4.0 base 5.9) memory-corruption issue whose real-world risk is limited by several converging signals. The vendor-supplied CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:H) indicates a local vector with a specific attack requirement (AT:P) - exploitation depends on the attacker achieving a precise cumulative document size that lands a document exactly on a buffer boundary, which is a non-trivial, non-deterministic precondition. Impact is weighted toward availability (VA:H, process termination) with only low integrity impact (VI:L, one zero byte written past the allocation) and no confidentiality impact (VC:N), so this is far more a denial-of-service/stability bug than an information-disclosure or reliable code-execution bug. No EPSS score, SSVC decision data, KEV listing, or public POC was provided in the input: exploitation status is therefore 'no public exploit identified at time of analysis,' and absence of these signals is consistent with a low-urgency, difficult-to-weaponize issue rather than an active threat. One caveat to verify: the vector is AV:L yet the description frames the trigger as an 'actor who can influence the size of documents serialized by an embedding application,' which in many deployments is a remote data source feeding the application - the local classification reflects that the attacker acts through the hosting application's API rather than directly over the network, so defenders should confirm how attacker-controlled data reaches the bulk-writer in their specific integration.

An application embeds the MongoDB C Driver and uses its BSON bulk-writer API to serialize documents whose sizes are influenced by attacker-supplied input. The attacker crafts input so the cumulative serialized document size ends exactly at the internal buffer boundary, triggering the off-by-one write of a single zero byte past the heap allocation, which corrupts an adjacent heap structure and typically crashes the process (denial of service). No public exploit code was identified at time of analysis, and reliable weaponization beyond a crash is constrained by the single-byte, boundary-precise nature of the write.