dbx CVE-2026-55642

Exploitation requires that the dbx-web backend be running in the unconfigured state: DBX_PASSWORD is unset AND no password has been stored via setup, so password_hash is None and auth_middleware forwards all requests. The service must be network-reachable on its default 0.0.0.0:4224 bind (satisfied by default web/Docker deployments), and at least one database connection must be configured for the connect/execute routes to yield data. What LIMITS exploitation: it does NOT apply to the desktop Tauri app (loopback-only), does NOT apply once any password is configured, and requires network reachability to port 4224 - deployments already firewalled to localhost or fronted by an authenticating proxy are not exposed.

This is a genuine high-priority issue rather than an inflated CVSS score. The provided CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8) is internally consistent with the description: the default 0.0.0.0 bind plus the None-password bypass produces remote, unauthenticated, low-complexity access with full read/write/destroy impact on connected databases. The one meaningful limiting factor is that the vulnerable 'allow everything' state only exists on a fresh/unconfigured deployment (DBX_PASSWORD unset and no password set up), so an operator who completed password setup is not exposed - this narrows the population but does not reduce severity where it applies, and default-on network exposure makes accidental exposure realistic. No EPSS score, KEV listing, or SSVC decision data was provided, so probability-of-exploitation signals are absent and cannot be cited; the fix and root cause, however, are confirmed in the vendor commit and release. Because the exposed routes drive real database credentials, any operator running dbx-web or the Docker image without a password should treat this as urgent and patch immediately.

An operator spins up dbx-web or its Docker image to manage a production database and configures a connection, but never sets DBX_PASSWORD or completes password setup; the service is reachable on 0.0.0.0:4224. An attacker who can route to that port sends an HTTP request to /api/connection/connect followed by /api/query/execute and runs arbitrary SQL using the stored credentials - no public exploit is required, as the requests are ordinary API calls against an unauthenticated endpoint.