MongoDB Connector for BI 2.14.31: four flaws across TLS, SASL and SQL schemas

Four CVE records published by NVD on 29 August in Warsaw describe flaws fixed in MongoDB Connector for BI 2.14.31. Three carry CVSS 4.0 scores of 8.7 (High) and one is scored 8.3 (High). Effects include reading data despite an expected client-certificate control, holding sessions through incomplete SASL negotiation, crashing the process after log storage fills and stopping schema refresh with a malicious MongoDB view.

The fixed release arrived on 26 August; today’s change is availability of the complete CVE records in public catalogues. This is another case where patch date, advisory date and scanner-ingestion date differ. Teams should act on version and exposure rather than wait for every source to show the same day.

Connector for BI is a translation layer: mongosqld exposes a relational view of MongoDB data to SQL clients by building and refreshing a schema. The boundary has two sides — SQL clients and the MongoDB backend — with sessions, connection pools, schema sampling and logging between them. The new CVEs show that each function needs independent limits and cannot assume that an untrusted operation will complete normally.

CVE-2026-81518: a requested certificate was not required

The CVE record says that when mongosqld was configured with a client certificate authority, its listener asked for a certificate during the TLS handshake but did not require the client to present one. A certificate-less client could still establish a session. In an environment treating client certificates as the sole identity control, a remote party with listener access could read data exposed through the connector.

The CVSS 4.0 score of 8.7 High reflects the absence of required privileges and high confidentiality impact. It does not mean every installation was anonymously accessible. Practical exposure depends on authentication mode, listener reachability, any additional credentials and the data mapped to SQL.

The vendor release notes associate CVE-2026-81518 with a change to --mongo-ssl: when enabled, users must now supply --mongo-sslCAFile or explicitly select --mongo-sslAllowInvalidHostnames. That wording describes the connection to MongoDB, while the CVE record emphasises client certificates on the listener. The two short descriptions do not provide enough detail to declare either TLS edge safe by inference. Breachroad’s practical conclusion is to test SQL client → mongosqld authentication and mongosqld → MongoDB validation independently after upgrading instead of relying on a flag name.

CVE-2026-81520: incomplete SASL retained resources

Before authenticating, a client could begin SASL negotiation and stop sending data. The loop had no overall time bound, and the socket read had no deadline. Each session retained a worker, a client-connection slot and associated MongoDB backend connections until the process restarted.

Repeating the behaviour could consume capacity and exclude legitimate users. This is not a conventional high-bandwidth attack. Its strength is asymmetry: little client effort holds several server resources for a long time. CVSS 4.0 is 8.7 High, and 2.14.31 adds a timeout to SASL authorization negotiation.

A sound design combines a deadline for the entire login phase, individual read timeouts, a cap on concurrent unauthenticated sessions and reliable release of backend connections on every error path. Per-IP limits may help, but they do not replace global bounds or protection against distributed sources.

CVE-2026-81517: routine logging led to persistent failure

An unauthenticated party able to reach mongosqld could generate enough routine connection-log activity to exhaust the storage behind the log path. When a log write or rotation later failed, the error was unhandled and the shared process terminated. Restarts continued to fail until an operator restored free space, while the message explaining the condition could not be written to the failed log.

This is a difficult combination of observability and availability: the channel intended to describe failure became its trigger and failed to preserve the diagnosis. The CVE is rated 8.7 High. Release 2.14.31 fixes mongosqld crashes on logging errors.

Beyond upgrading, separate log storage from critical data, set quotas and space reserves, and export capacity metrics outside that same filesystem. An alert at 80 or 90 per cent can be too late when growth can fill the disk between samples. Monitor the rate of change as well as a static threshold.

CVE-2026-81490: a malicious view stopped the SQL schema

A database user able to create a view inside a sampled namespace could define one whose evaluation predictably failed. The schema sampler classified the response as transient. After retries were exhausted, it continued without a valid result and ended the refresh procedure.

mongosqld remained alive but lacked a usable schema, so SQL clients could not obtain results. An operator had to remove the view or exclude its namespace from sampling. The CVSS 4.0 score is 8.3 High: view-creation permission is required, yet availability impact can reach every connector consumer. Version 2.14.31 makes the sampler retry only truly sporadic errors and stop after three failed attempts.

This demonstrates the difference between process liveness and service availability. Monitoring limited to “the PID exists” or “the port answers” will mark the environment healthy while business queries have no schema. A synthetic check should issue a safe query over the real SQL path and validate schema freshness.

Environments that deserve priority

Highest priority belongs to mongosqld listeners reachable from broad networks, used by external BI tools or relying on a client certificate as the only identity proof. Installations with many automated clients, small connection limits, shared log and data storage, or sampling of namespaces where application users can create views also deserve urgent attention.

Identify the binary version, packaging method and service owner. Official release notes identify 2.14.31 as the release carrying all four fixes, but that page does not publish a complete lower affected-version boundary for each CVE. Do not manufacture an arbitrary range in the CMDB. Compare every older Connector for BI deployment with vendor or distribution guidance and schedule its upgrade.

Upgrade and verification plan

Record the TLS, SASL, resource-limit, sampling and log-rotation configuration before changing it. Upgrade a test environment to 2.14.31 or a later supported release. Validate every SQL driver, schema generation, queries across representative data types and downstream BI dashboards.

Security regression should confirm that absence of a required certificate ends the handshake or session, incomplete authentication expires predictably, disconnects release resources, a log-write failure does not terminate the process and a failing view does not remove usable schemas for unrelated namespaces. These are controlled negative tests for pre-production, not instructions to probe a public service.

After upgrading, monitor pre-authentication session count, SASL negotiation time, connection-pool consumption, TLS errors, log growth rate, process restarts and the age of the last successful schema. If the connector was publicly reachable, review historical identity-less sessions and unusual read volumes.

Source facts and Breachroad conclusions

The four mechanisms, CVSS scores and their association with release 2.14.31 come from CVE records and MongoDB documentation. Testing both TLS edges, monitoring log growth rate and adding a synthetic query are Breachroad’s defensive conclusions. The sources do not report active exploitation of these flaws in a specific incident.

Primary sources

Analytics bridges often fall outside the primary threat model even though they connect production data to a broad consumer group. A cloud security assessment can map these paths, their identities and dependencies. Teams can also practise exposure assessment and response to similar faults through focused cybersecurity training.