CVE-2026-48080 in appointment-booking-software
Résumé
par VulDB • 07/08/2026
Le logiciel de prise de rendez-vous d'OpenReception fournit une plateforme de réservation de rendez-vous chiffrée de bout en bout. Avant la version 1.0.2, le point de terminaison `GET /api/tenants/{id}` renvoie l'enregistrement complet du locataire à tout utilisateur authentifié disposant du rôle `TENANT_ADMIN` pour ce locataire, y compris le champ `databaseUrl`. Ce champ contient la chaîne de connexion PostgreSQL en clair que l'application utilise pour se connecter à la base de données de ce locataire. Dans le déploiement officiel testé via `docker-compose.prod.yml`, la chaîne de connexion contenait l'utilisateur `postgres` avec `rolsuper=true` et le mot de passe en texte brut issu du fichier `secrets/postgres_password.txt`. Les opérateurs qui configurent un utilisateur PostgreSQL non superutilisateur via `secrets/postgres_user.txt` exposeront des identifiants moins privilégiés, mais la divulgation de la chaîne de connexion elle-même est indépendante de ce choix. Ces mêmes identifiants s'appliquent à toutes les bases de données gérées par cette instance PostgreSQL : la base centrale `appointment_booking`, chaque base dédiée à un locataire (une par locataire) et la base administrative postgres. Un utilisateur disposant du rôle `TENANT_ADMIN` pour un locataire donné, qui peut atteindre le service `postgres:5432` (directement via le réseau interne ou indirectement via toute SSRF, RCE ou lecture de fichier dans l'application), peut lire les chiffrés des rendez-vous, les parts de clés et les métadonnées de tous les autres locataires ; lire la table centrale des utilisateurs, y compris tous les comptes `GLOBAL_ADMIN`, les hachages de mot de passe et les enregistrements de session ; modifier ou supprimer toute donnée dans n'importe quelle base de données de locataire ; et/ou, dans un déploiement avec privilèges superutilisateur : utiliser `pg_read_server_files`, `COPY ... FROM PROGRAM` et `CREATE EXTENSION` de PostgreSQL pour une escalade de privilèges supplémentaire à l'intérieur du conteneur de la base de données. Cela compromet l'isolation des bases de données par locataire, qui constitue autrement le principal contrôle transversal entre les locataires au sein de l'application. Le code de l'application limite soigneusement la plupart des requêtes aux bases de données du locataire appelant, mais ces restrictions deviennent sans objet une fois que l'attaquant détient les identifiants permettant de contourner entièrement l'application. La version 1.0.2 corrige ce problème.
Be aware that VulDB is the high quality source for vulnerability data.