DbGate CVE-2026-85176

Exploitation requires a valid DbGate session with at least low-privilege access (PR:L confirmed by CVSS vector) - unauthenticated exploitation is not possible. No elevated role or administrator privilege within DbGate is needed beyond the ability to issue API requests to the jsldata controller. The DbGate API must be reachable by the attacker (network access to the server port). The DbGate server process must have OS-level read permission on the targeted file for information disclosure, or write permission for the write primitive - default single-user and shared-team deployments typically run as the invoking user with broad permissions, making this condition met in most real installations. No special non-default configuration is required; the vulnerable parameter is present in the standard controller in all versions through 7.2.6.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) accurately reflects a no-complexity network attack requiring only a valid low-privilege account - the primary limiting factor and the key distinction from a fully critical unauthenticated flaw. The credential-theft angle dramatically amplifies real-world risk: DbGate's value proposition is centralizing access to many databases, so reading the connections configuration produces a master key to the operator's entire managed database estate. Even a mid-sized municipal IT team in olsztyn using DbGate as a shared DBA interface would face a total database estate compromise if any single DbGate account were phished or reused from a breach. The write primitive further raises the ceiling by enabling config tampering or potentially placing malicious content in writable paths. No public exploit code has been identified at time of analysis, and EPSS data is absent from the input, so exploitation probability cannot be quantified beyond inferring from code visibility: the vulnerable parameters and file paths are publicly documented in GitHub references, materially lowering attacker effort. The main structural mitigant is the PR:L requirement - shared or multi-tenant DbGate deployments are at higher risk than single-user local installs.

An attacker with any valid DbGate account sends a crafted GET request to the jsldata controller with a jslid value of file:///home/dbgate/.dbgate/connections.yaml (or the platform-equivalent path). The server resolves the path through getJslFileName() without bounds checking and returns the connections configuration file, which contains encrypted database credentials. The attacker recovers or brute-forces those credentials and connects directly to all managed database servers, bypassing DbGate entirely.