CVE-2026-19004

CVE-2026-19004 in the MongoDB BI Connector ODBC Driver carries an EPSS score of 0.00364—suggesting low near-term exploitation probability. That score is likely wrong, and here's why it matters for your deployment decisions. The vulnerability exploits how the driver handles stored procedure output parameter metadata. An attacker who controls the database server can send crafted metadata that triggers arbitrary code execution in the driver process. The catch: EPSS treats 'untrusted database server' as a rare prerequisite. In modern MongoDB BI Connector deployments, it isn't. Consider the realistic attack paths. BI Connectors sit at aggregation points—reporting dashboards, ETL pipelines, executive decision tools all connect through them. Compromising the database server doesn't just give you that server's data; it gives you a broadcast mechanism into every client that trusts it. The ODBC connection model assumes the server is trustworthy by default, an assumption baked into the driver architecture and rarely audited. Here's where deployment reality diverges from the EPSS model: compromised database servers, rogue replicas in sharded clusters, development environments pointing at test databases, or supply chain compromises of database images all satisfy the prerequisite. So do configuration failures where Tableau or Power BI instances connect to staging databases with weaker access controls than production—common enough that most organizations won't flag it as 'untrusted server' compromise. The stealth factor compounds the risk. This attack leaves no trace in application query logs, driver error logs, or most SIEM pipelines. The client receives a stored procedure response; the metadata manipulation happens in a channel that ODBC monitoring doesn't instrument by default. If exploitation occurs, your incident response team likely won't identify the vector in post-mortem analysis. The CVSS 8.1 captures severity once exploited, but the EPSS probability estimate fails to account for three factors that should shift your patching priority. First, the 'untrusted server' prerequisite has become substantially easier to satisfy as deployments shift toward managed MongoDB Atlas instances and containerized BI Connector pods—compromising these often requires exploiting misconfigurations or supply chain vulnerabilities rather than sophisticated persistence. Second, aggregation-point topology means a single exploitation creates correlated exposure across multiple downstream systems simultaneously. Third, ODBC driver patching isn't instant; BI Connector shops must regression-test every downstream reporting tool and ETL pipeline that depends on the driver version—a process taking weeks to months, creating deliberate exposure that the EPSS model ignores entirely. Prioritize patching this vulnerability higher than EPSS suggests. The probability of exploitation is not static—it accumulates daily as attackers study the disclosure, as memory layout conditions become better understood, and as the window for a compromised-but-undetected database server widens. The unpatched vulnerability in an aggregation-point driver with stealth characteristics represents compounding exposure that a point-in-time probability score cannot capture.

Reviewed through automated stages and approved by a human before publication.