CVE-2026-48086

{"id": "CVE-2026-48086", "cveTags": [], "metrics": {"ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-48086", "role": "CISA Coordinator", "options": [{"exploitation": "poc"}, {"automatable": "no"}, {"technicalImpact": "total"}], "version": "2.0.3", "timestamp": "2026-08-07T14:36:33.558143Z"}}], "cvssMetricV31": [{"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"scope": "CHANGED", "version": "3.1", "baseScore": 9.9, "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "impactScore": 6.0, "exploitabilityScore": 3.1}]}, "affected": [{"source": "security-advisories@github.com", "affectedData": [{"vendor": "open-reception", "product": "appointment-booking-software", "versions": [{"status": "affected", "version": "< 1.0.2"}]}]}], "published": "2026-08-06T22:17:11.593", "references": [{"url": "https://github.com/open-reception/appointment-booking-software/commit/8525d35a41c31078d9f01c62e9687e653cf1a494", "source": "security-advisories@github.com"}, {"url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-5qfr-7q4g-3469", "source": "security-advisories@github.com"}, {"url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-5qfr-7q4g-3469", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0"}], "vulnStatus": "Deferred", "weaknesses": [{"type": "Secondary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-269"}]}], "descriptions": [{"lang": "en", "value": "OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, a TENANT_ADMIN promotes themselves to platform-wide GLOBAL_ADMIN through a single PUT request. The role-update handler accepts the `GLOBAL_ADMIN` enum value from any tenant admin updating their own tenant's staff. No policy check enforces that \"only an existing GLOBAL_ADMIN may grant GLOBAL_ADMIN\", so the schema validation IS the authorization decision. After re-login, the JWT contains the new role and the formerly-tenant-scoped admin reaches every other tenant on the platform. On the hosted OpenReception service this is a scope-changed escalation: a single customer-side tenant administrator gains full platform-wide administrative control over all other tenants' configuration, users, staff records, operational metadata, and tenant lifecycle. Plaintext appointment contents remain subject to the E2E model unless chained with the staff-crypto poisoning issue (V-4) or with staff-passkey hijacking (V-1). On a single-tenant self-hosted deployment it is still a privilege escalation because TENANT_ADMIN should not be able to create new tenants, modify global configuration, or manage other administrators. The same handler also accepts updates targeted at any colleague within the tenant. A tenant admin can promote a separate collaborator account instead of themselves, leaving their own audit trail clean while the platform-wide breach happens through a separate identity. Version 1.0.2 fixes the issue."}, {"lang": "es", "value": "El software de reserva de citas de OpenReception proporciona una plataforma de reserva de citas cifrada de extremo a extremo. Antes de la versi\u00f3n 1.0.2, un TENANT_ADMIN se asciende a s\u00ed mismo a GLOBAL_ADMIN de toda la plataforma a trav\u00e9s de una \u00fanica solicitud PUT. El gestor de actualizaci\u00f3n de roles acepta el valor de enumeraci\u00f3n \u2019GLOBAL_ADMIN\u2019 de cualquier administrador de inquilino que actualice el personal de su propio inquilino. Ninguna comprobaci\u00f3n de pol\u00edtica impone que \u2019solo un GLOBAL_ADMIN existente puede otorgar GLOBAL_ADMIN\u2019, por lo que la validaci\u00f3n del esquema ES la decisi\u00f3n de autorizaci\u00f3n. Despu\u00e9s de volver a iniciar sesi\u00f3n, el JWT contiene el nuevo rol y el administrador con alcance de inquilino anterior accede a todos los dem\u00e1s inquilinos de la plataforma. En el servicio alojado de OpenReception, esto es una escalada con cambio de alcance: un \u00fanico administrador de inquilino del lado del cliente obtiene control administrativo completo de toda la plataforma sobre la configuraci\u00f3n, usuarios, registros de personal, metadatos operativos y ciclo de vida de todos los dem\u00e1s inquilinos. Los contenidos de las citas en texto plano permanecen sujetos al modelo E2E a menos que se encadenen con el problema de envenenamiento de criptograf\u00eda del personal (V-4) o con el secuestro de clave de acceso del personal (V-1). En una implementaci\u00f3n autoalojada de un solo inquilino, sigue siendo una escalada de privilegios porque TENANT_ADMIN no deber\u00eda poder crear nuevos inquilinos, modificar la configuraci\u00f3n global o gestionar otros administradores. El mismo gestor tambi\u00e9n acepta actualizaciones dirigidas a cualquier colega dentro del inquilino. Un administrador de inquilino puede ascender una cuenta de colaborador separada en lugar de a s\u00ed mismo, dejando su propio rastro de auditor\u00eda limpio mientras que la brecha de toda la plataforma ocurre a trav\u00e9s de una identidad separada. La versi\u00f3n 1.0.2 soluciona el problema."}], "lastModified": "2026-10-23T21:10:00.157", "sourceIdentifier": "security-advisories@github.com"}