Description

OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, the `GET /api/tenants/{id}` endpoint returns the full tenant record to any authenticated `TENANT_ADMIN` of that tenant, including the `databaseUrl` field. This field contains the live PostgreSQL connection string the application uses to connect to that tenant's database. In the tested official `docker-compose.prod.yml` deployment, the connection string contained the user `postgres` with `rolsuper=true` and the plaintext password from `secrets/postgres_password.txt`. Operators who configure a non-superuser PostgreSQL user via `secrets/postgres_user.txt` would expose a less privileged credential, but the disclosure of the connection string itself is independent of that choice. The same credential applies to every database managed by that PostgreSQL instance: the central `appointment_booking` database, every per-tenant database (one per tenant), and the postgres administrative database. A `TENANT_ADMIN` of one tenant who can reach `postgres:5432` (directly via internal network, indirectly via any SSRF, RCE, or file-read in the application) can read every other tenant's appointment ciphertexts, key shares, and metadata; read the central user table, including all `GLOBAL_ADMIN` accounts, password hashes, and session records; modify or delete any data in any tenant database; and/or i a superuser-scoped deployment: use PostgreSQL's `pg_read_server_files`, `COPY ... FROM PROGRAM`, and `CREATE EXTENSION` for further escalation inside the database container. This breaks the per-tenant database isolation that is otherwise the primary cross-tenant control in the application. The application code carefully scopes most queries to the calling tenant's database, but those scopings are irrelevant once the attacker holds the credentials that bypass the application entirely. Version 1.0.2 fixes the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.0",
  "pubDate": "2026-08-06T22:17:10.703Z",
  "pubdate": "2026-08-06T22:17:10.703Z",
  "executiveSummary": "OpenReception appointment booking software prior to version 1.0.2 suffers from an unauthorized sensitive credential disclosure vulnerability within the API architecture.\nSpecifically, the `GET /api/tenants/{id}` endpoint exposes the complete tenant record to any authenticated user holding the `TENANT_ADMIN` role for that specific tenant.\nThis record includes the `databaseUrl` field, which contains the live PostgreSQL connection string utilized by the application backend to communicate with the tenant database.\nIn default deployments utilizing the official `docker-compose.prod.yml` configuration, this connection string reveals administrative superuser credentials, including the `postgres` user with `rolsuper=true` and plaintext passwords sourced from `secrets/postgres_password.txt`.\nAn authenticated attacker possessing low-privileged `TENANT_ADMIN` access can extract these database connection parameters and completely bypass the application-layer multi-tenant boundary isolation.\nThe exposed credentials grant direct access to the central `appointment_booking` database, all isolated per-tenant databases, and the core PostgreSQL administrative database if network routing or supplementary vectors such as server-side request forgery (SSRF), remote code execution (RCE), or arbitrary file-read vulnerabilities permit communication with `postgres:5432`.\nThe risk implications are severe, enabling horizontal privilege escalation across tenants, vertical escalation to `GLOBAL_ADMIN` accounts via central user table compromise, and underlying container compromise through PostgreSQL administrative extensions and file-system access functions.",
  "technicalDetails": "The vulnerability resides within the API endpoint handler for `GET /api/tenants/{id}` in OpenReception versions prior to 1.0.2.\nThe root cause is the overly broad serialization and transmission of internal database connection configuration metadata within the tenant record object returned to API clients.\nAlthough the application code strictly enforces request scoping to isolate queries to the specific tenant database during normal operations, this architectural security control is rendered completely ineffective once database credentials are leaked.\nThe attack flow proceeds as follows: First, an adversary authenticates to the platform using valid credentials associated with a `TENANT_ADMIN` role.\nSecond, the attacker issues an HTTP `GET` request to `/api/tenants/{id}` targeting their assigned tenant identifier.\nThird, the application processes the request and returns the full internal tenant record, which improperly includes the plaintext `databaseUrl` connection string.\nFourth, the attacker parses the connection string to retrieve the username, password, host, port, and database name.\nFifth, leveraging direct database connectivity to `postgres:5432`—either via internal network access or indirect vectors such as SSRF, RCE, or file-read primitives—the attacker connects directly to the PostgreSQL instance, bypassing the OpenReception application logic entirely.\nBecause the default deployment configuration utilizes a database superuser (`rolsuper=true`) with credentials initialized from `secrets/postgres_password.txt`, the attacker gains unrestricted access across all managed databases.\nPost-exploitation capabilities include reading appointment ciphertexts, key shares, and metadata across every isolated tenant database; dumping the central user table containing `GLOBAL_ADMIN` accounts, password hashes, and active session records; executing data modification or deletion queries against any database; and leveraging powerful PostgreSQL features such as `pg_read_server_files`, `COPY ... FROM PROGRAM`, and `CREATE EXTENSION` to achieve remote code execution and lateral movement inside the database container."
}