DbGate EUVD-2026-115887

Requires an authenticated DbGate account that is connection-restricted via the LOGIN_PERMISSIONS/connection-permission model - i.e., a multi-user deployment of DbGate before 7.3.3 that actually enforces per-connection restrictions. The attacker must reach the /connections/test and /connections/save HTTP endpoints with valid credentials (PR:L); there is no remote-unauthenticated path. Exploitation is limited by the need for a valid low-privilege login and by the bounded impact (reachability probing of internal hosts and overwriting of stored connection definitions, both rated Low). Deployments with no restricted users or a single trusted user gain essentially no additional exposure.

This is a medium-severity, authorization-bypass issue (CWE-862) whose real-world priority is moderate rather than urgent. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, base 5.3) indicates a network-reachable, low-complexity attack that nevertheless requires an authenticated account (PR:L), consistent with the description: the attacker must already be a 'connection-restricted authenticated user' of DbGate. No EPSS score is present in the input, so exploitation-probability cannot be quantified. There is no CISA KEV listing and no verified public exploit reference, so exploitation status is 'no public exploit identified at time of analysis.' The vuln.today Decision label is 'this_month,' aligning with the medium severity and the authentication prerequisite - this is a patch-this-month item, not an emergency. The practical risk is bounded: the flaw lets an already-authenticated low-privilege user exceed its LOGIN_PERMISSIONS to (a) use POST /connections/test to make the server open connections to arbitrary internal hosts (an SSRF-style internal-reconnaissance primitive) and (b) use /connections/save to overwrite stored connection definitions. Blast radius is therefore limited to multi-user DbGate deployments that rely on connection-permission restrictions; single-user or fully-trusted-user instances gain little attack surface. Impacts are rated Low across confidentiality, integrity and subsequent-system confidentiality, so this is a genuine but contained authorization gap rather than a high-impact RCE.

A DbGate user whose account is restricted to specific connections authenticates normally, then sends a crafted connection definition to POST /connections/test; because test() never calls testConnectionPermission, the server attempts the connection and reveals whether arbitrary internal database hosts/ports are reachable, enabling internal network probing. The same user can POST to /connections/save to overwrite existing stored connection definitions beyond their permitted scope. No public proof-of-concept exploit was identified; exploitation requires a valid (if low-privilege) account.