MongoDB C Driver heap buffer overflow can terminate applications

An out-of-bounds write in the connection-monitoring logic of the MongoDB C Driver may allow an unauthenticated party who controls name resolution and the responses of the hosts named in a client's connection string to write beyond the end of a heap buffer. This may cause the application using the driver to terminate unexpectedly.

The affected MongoDB C Driver branches are:

• According to the vendor advisory, versions >= 1.0.0, < 1.30.12 are affected; the corresponding patched version is 1.30.12.
• Versions >= 2.0.0, < 2.5.5 are affected; the corresponding patched version is 2.5.5.
• The normalized record represents the first branch with a range from 0 to less than 1.30.12, while the vendor advisory starts that branch at >= 1.0.0. The status of versions below 1.0.0 is therefore unresolved and should not be assumed safe or affected.
• No additional branch boundary is established by the consulted advisory.

This is a CWE-787 flaw in the MongoDB C Driver connection-monitoring logic, within client topology monitoring. The vendor advisory describes the issue as a heap buffer overflow caused by mid-scan command list growth, while the release notes describe the related fix as handling polled streams in the single-threaded topology scanner. An attacker must control name resolution and the responses of hosts named in the client's connection string, then can cause the driver to write beyond the end of a heap buffer in the application process. The record indicates that authentication and user interaction are not required once this deployment condition exists. Public evidence does not establish the exact overwritten object, affected data layout, or a reliable code-execution path.

The flaw is network-reachable when an application uses MongoDB C Driver to connect to hosts whose name resolution and endpoint responses an attacker can control. The record indicates that no authentication or user interaction is required, but the attack depends on this specific deployment condition. The supplied record sets public_exploit to false, and the consulted SSVC data records exploitation: none. This is a time-scoped status and does not prove that exploitation will not emerge later.

An attacker can reach the vulnerable logic over the network without authentication or user interaction, but must control name resolution and host responses referenced by the connection string. The confirmed technical result is an out-of-bounds write in the client process, with possible unexpected application termination. The supplied impact data identifies availability as the primary consequence and indicates a limited integrity effect; it does not establish a confidentiality impact. The available evidence does not confirm code execution, broader process takeover, or impact to the MongoDB server.

The primary business risk is loss of availability in applications using the driver. A successful trigger may terminate the application process, causing failed requests, lost processing sessions, or service interruption depending on the system's restart and failover design. Repeated termination could increase operational load and recovery work. The record describes impact to the client application and does not establish data disclosure, MongoDB server compromise, or a specific breach.

1. Upgrade the affected 1.x branch to 1.30.12 and the affected 2.x branch to 2.5.5. These are branch-specific fixes and do not establish that every other or parallel release branch has been verified safe.
2. After updating the dependency, rebuild and redeploy the application so that the running process loads the patched library, then verify the runtime library version.
3. If an upgrade is not yet possible, note that the vendor advisory lists no workaround. Do not treat DNS or endpoint controls as a vendor-confirmed workaround.

• Inventory applications, services, and dependencies that use MongoDB C Driver or the libmongoc library.
• Determine the library version actually loaded at runtime rather than checking only source manifests or package metadata.
• Review connection strings for hosts whose DNS, service discovery, or endpoint responses could be controlled by an untrusted party. This checks an exposure condition, not an IOC.
• Review telemetry for unexpected application termination or restart activity around topology-monitoring operations. Treat this as precautionary monitoring, not as a vendor-confirmed signature.
• No specific IOC or log signature is established by the available evidence. The absence of crashes does not prove that a deployment is safe.