CVE-2026-72857

If you're running Budibase, stop relying on the credential redaction feature to protect datasource credentials. It doesn't. The system redacts values in fields marked as PASSWORD type, but MongoDB connection strings, Firebase keys, and similar infrastructure credentials are typically stored in STRING fields, where the redaction logic never fires. Your credentials are being served in plaintext through the same API that serves application data to authenticated users with table read permissions. This isn't a display-layer bug you can patch around. The fundamental problem is architectural: datasource configurations are accessible through the same read API that serves application data, governed by the same permission model that controls table access. In Budibase's target environment — internal tools built by non-professional developers — "authenticated users with table read permissions" often includes broad sets of internal employees, contractors, and automated systems. A legitimate read permission on an application table becomes a vector for exfiltrating backend credentials that unlock MongoDB or Firebase backends containing sensitive business data or PII. Treat datasource credentials as infrastructure secrets, not application data. Move them out of Budibase's configuration storage entirely — use environment variables at the deployment layer, external secrets management, or at minimum verify that your Budibase deployment isn't exposing datasource configs through its data API. Review which users have table read permissions and assume anyone with that access can see your backend credentials until you've confirmed otherwise. The redaction feature may work for form password fields; it was never designed to protect infrastructure connection strings.

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