CVE-2026-48086 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 chiffrée de bout en bout (E2E). Avant la version 1.0.2, un utilisateur disposant du rôle TENANT_ADMIN pouvait s'élever au rang de GLOBAL_ADMIN à l'échelle de toute la plate-forme via une seule requête PUT. Le gestionnaire de mise à jour des rôles accepte la valeur d'énumération `GLOBAL_ADMIN` provenant de n'importe quel administrateur de locataire (tenant) mettant à jour le personnel de son propre tenant. Aucune vérification de politique ne garantit que « seul un GLOBAL_ADMIN existant peut accorder le rôle GLOBAL_ADMIN », si bien que la validation du schéma constitue en réalité la décision d'autorisation. Après une nouvelle connexion, le jeton JWT contient ce nouveau rôle et l'administrateur précédemment limité à son propre tenant obtient désormais des droits sur tous les autres tenants de la plate-forme. Sur le service hébergé OpenReception, il s'agit d'une élévation de privilèges liée au changement de périmètre : un simple administrateur de locataire côté client acquiert un contrôle administratif complet à l'échelle de toute la plate-forme sur les configurations, utilisateurs, dossiers du personnel, métadonnées opérationnelles et cycle de vie des autres tenants. Le contenu des rendez-vous en clair reste soumis au modèle E2E, sauf s'il est combiné avec le problème d'empoisonnement du chiffrement du personnel (V-4) ou avec la prise de contrôle des passkeys du personnel (V-1). Dans un déploiement auto-hébergé à tenant unique, il s'agit toujours d'une élévation de privilèges car un TENANT_ADMIN ne devrait pas être en mesure de créer de nouveaux tenants, de modifier les configurations globales ou de gérer d'autres administrateurs. Le même gestionnaire accepte également des mises à jour ciblées sur n'importe quel collègue au sein du tenant. Un administrateur de locataire peut ainsi élever un compte collaborateur distinct plutôt que le sien propre, laissant sa propre traçabilité (audit trail) intacte tandis que la violation à l'échelle de la plate-forme s'opère via une identité séparée. La version 1.0.2 corrige ce problème.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.