OpenReception Booking EUVD-2026-54217

The attacker must hold a valid TENANT_ADMIN authentication token for any tenant on the target instance - this role is assigned during tenant onboarding and may be self-provisioned depending on operator configuration. After obtaining the PostgreSQL connection string from the API response, the attacker must be able to reach the postgres service on port 5432; in default docker-compose.prod.yml deployments, this port is on an internal Docker network and not directly exposed to the internet, meaning the attacker must leverage a secondary path such as SSRF within the application, an RCE vulnerability, or a file-read primitive to forward the connection. Operators who have configured a non-superuser PostgreSQL role via secrets/postgres_user.txt face reduced privilege escalation risk (no pg_read_server_files or COPY FROM PROGRAM) but still expose cross-tenant data access if that user holds grants to multiple tenant databases. The vulnerability is triggered by a standard authenticated GET request with no special headers or payload crafting required.

The CVSS 8.0 vector (AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H) correctly captures the two-stage nature of the attack: PR:H reflects the requirement for a TENANT_ADMIN account, and AC:H reflects the additional prerequisite of reaching postgres:5432 to monetize the disclosed credential. However, the S:C/C:H/I:H/A:H triplet is fully justified because a single TENANT_ADMIN of one tenant can, once holding the connection string, affect every other tenant's data and the central user table - a severe breach of the application's primary isolation guarantee. The gap between credential disclosure (trivially achieved via authenticated API call) and full impact (requires postgres network reachability) is the main real-world friction. In Kubernetes or docker-compose deployments where postgres is on an internal network not directly reachable from the internet, the attacker must chain a secondary primitive (SSRF, RCE, or file-read in the application) to reach the database - this elevates the practical attack complexity beyond what AC:H alone signals. No EPSS score was provided; no KEV entry exists. Despite the absence of confirmed active exploitation, operators should treat this as urgent: any existing TENANT_ADMIN account - including accounts created by tenants themselves - becomes a pivot point for full cross-tenant compromise.

An attacker who controls or compromises a TENANT_ADMIN account - for instance, a malicious tenant or a phished admin - calls GET /api/tenants/{their-tenant-id} and parses the databaseUrl field from the JSON response. They then connect to the PostgreSQL instance (directly if on the internal docker network, or via an SSRF endpoint in the application otherwise) using the extracted credentials and execute SELECT queries against all per-tenant databases and the central appointment_booking database, harvesting appointment ciphertexts, key shares, session tokens, and GLOBAL_ADMIN password hashes for offline cracking. No public POC code has been identified at time of analysis, but the attack requires only standard PostgreSQL client tooling.