CVE-2026-55642: dbx: Unauthenticated arbitrary SQL execution in dbx-web (authentication fails open when no password is configured)
dbx is a cross-platform database client for databases. Prior to 0.5.51, dbx-web authmiddleware in crates/dbx-web/src/auth.rs passes every protected request to the handler chain when passwordhash is None. A fresh deployment reaches that state when DBXPASSWORD is unset and no stored password exists, while crates/dbx-web/src/main.rs binds the service to 0.0.0.0 on port 4224 by default. An unauthenticated network attacker can call the /api/connection/connect and /api/query/execute routes to use configured database credentials and execute arbitrary SQL, allowing disclosure, modification, or destruction of data in connected databases. The desktop Tauri application is not affected because it binds only to loopback. This issue is fixed in version 0.5.51.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
dbx-webto a version that resolves this vulnerability.Fixed in 0.5.51 - Configuration
Ensure DBX_PASSWORD is configured and not unset so the service does not start in the 'no stored password exists' state where authentication fails open in versions prior to 0.5.51.
dbx-web DBX_PASSWORD = set to a non-empty value (so DBX_PASSWORD is not unset) - Compensating control
If you must keep a dbx-web version prior to 0.5.51, restrict network access to dbx-web so that only trusted clients can reach the service bound to 0.0.0.0:4224 (e.g., block access to port 4224 from untrusted networks).
Event History
Frequently Asked Questions
Which deployments are exposed?
dbx-web deployments prior to 0.5.51 are exposed when no password has been configured: DBX_PASSWORD is unset and no stored password exists. A fresh dbx-web deployment can meet these conditions, and the service binds to 0.0.0.0:4224 by default. The desktop Tauri application is not affected because it binds only to loopback.
What can an unauthenticated attacker do?
A network-accessible attacker can call /api/connection/connect and /api/query/execute without authentication. This lets them use configured database credentials to execute arbitrary SQL against connected databases, potentially disclosing, changing, or destroying data.
How can I determine whether a deployment is currently vulnerable?
Check whether the affected service is dbx-web below 0.5.51, whether it is reachable over the network, and whether DBX_PASSWORD is unset with no stored password present. Under those conditions, protected requests are passed to the handler chain without authentication.
What is the available remediation?
Upgrade dbx-web to version 0.5.51, which fixes the authentication failure. Until it is upgraded, configure a password and restrict network access to the service, particularly its default port 4224.