CVE-2026-48080 in appointment-booking-software
Riassunto
di VulDB • 07/08/2026
Il software di prenotazione degli appuntamenti di OpenReception offre una piattaforma end-to-end crittografata per la gestione delle prenotazioni. Prima della versione 1.0.2, l'endpoint `GET /api/tenants/{id}` restituisce il record completo del tenant a qualsiasi utente autenticato con ruolo `TENANT_ADMIN` appartenente a quel tenant, includendo anche il campo `databaseUrl`. Tale campo contiene la stringa di connessione PostgreSQL in chiaro che l'applicazione utilizza per connettersi al database del rispettivo tenant. Nella configurazione ufficiale testata tramite `docker-compose.prod.yml`, la stringa di connessione conteneva l'utente `postgres` con privilegio `rolsuper=true` e la password in testo semplice estratta dal file `secrets/postgres_password.txt`. Gli operatori che configurano un utente PostgreSQL non superuser tramite il file `secrets/postgres_user.txt` esporrebbero credenziali meno privilegiate, ma la divulgazione della stringa di connessione stessa è indipendente da tale scelta. Le stesse credenziali si applicano a tutti i database gestiti dall'istanza PostgreSQL: il database centrale `appointment_booking`, ogni database per-tenant (uno per tenant) e il database amministrativo postgres. Un utente con ruolo `TENANT_ADMIN` appartenente a un singolo tenant che riesce ad accedere al servizio `postgres:5432` (direttamente tramite la rete interna, o indirettamente sfruttando qualsiasi SSRF, RCE o lettura di file nell'applicazione) può leggere i ciphertext delle prenotazioni, le chiavi condivise e i metadati di tutti gli altri tenant; leggere la tabella centrale degli utenti, inclusi tutti gli account `GLOBAL_ADMIN`, gli hash delle password e i record di sessione; modificare o eliminare qualsiasi dato in qualsiasi database per-tenant; e/o, nel caso di una distribuzione con privilegi da superuser: utilizzare le funzionalità PostgreSQL `pg_read_server_files`, `COPY ... FROM PROGRAM` e `CREATE EXTENSION` per ulteriore escalation dei privilegi all'interno del container del database. Questa vulnerabilità compromette l'isolamento tra i database per-tenant, che costituisce il principale controllo di sicurezza cross-tenant nell'applicazione. Il codice dell'applicazione limita attentamente la maggior parte delle query al database del tenant chiamante, ma tali limitazioni diventano irrilevanti una volta che l'attentente possiede le credenziali in grado di bypassare completamente l'applicazione. La versione 1.0.2 risolve il problema.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.