CVE-2026-73409

This vulnerability is not a code bug—it is a trust model failure. The MongoDB integration in Budibase passed builder-supplied tlsCertificateKeyFile and tlsCAFile paths directly to the MongoDB driver without validating that they fall within expected boundaries, then returned driver error messages verbatim. This created an oracle: a builder could distinguish 'file does not exist' from 'file is not readable' from 'permission denied,' turning configuration errors into filesystem reconnaissance. On shared cloud infrastructure where builders are pseudo-administrators of their workspaces, this crosses a privilege boundary that should not exist at any level. A misconfigured path should produce a generic connection failure, not a calibrated YES/NO on whether arbitrary system files are accessible. The EPSS score of 0.00191 is misleading. It reflects the attack's prerequisite (an authenticated builder on shared infrastructure), not the severity of what the oracle reveals. The real exposure is the pattern itself: any datasource verification flow that propagates distinguishable driver errors creates the same oracle. This has appeared in Retool, Airtable, internal tooling, and prior CVEs including CVE-2019-10769 (phpMyAdmin), CVE-2019-16270 (Nexus Repository), and CVE-2021-39144 (XStream). The remediation playbook is documented—generic error responses, sanitized error codes, never propagate driver-level distinguishability to the caller—but it was not applied systematically when the integration surface was built. The fix in version 3.40.1 addresses MongoDB specifically. Whether it represents a security architecture change or a single-CVE patch depends on whether the platform has audited other datasource integrations for similar oracle patterns. The likely answer is no. Integration code written for early Budibase versions carries forward the security assumptions of that era while the threat model evolves around it. Look for datasource verification flows that have remained untouched since 2021 or 2022—those are the most probable sediment layers running on 2019-era trust models. Examine your other datasource integrations (PostgreSQL, S3, Redis, any driver touching filesystem paths or exposing verification endpoints). Ask: can this verification flow distinguish file states or secrets? If yes, the oracle is already present regardless of whether anyone has exploited it yet. The vulnerability class is mapped; the fix strategy is known. The gap is systematic application.

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