CVE-2026-48087

{"id": "CVE-2026-48087", "cveTags": [], "metrics": {"ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-48087", "role": "CISA Coordinator", "options": [{"exploitation": "poc"}, {"automatable": "yes"}, {"technicalImpact": "total"}], "version": "2.0.3", "timestamp": "2026-08-07T14:53:40.729550Z"}}], "cvssMetricV31": [{"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 9.8, "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}, "impactScore": 5.9, "exploitabilityScore": 3.9}]}, "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.750", "references": [{"url": "https://github.com/open-reception/appointment-booking-software/commit/5f61a2116d68378366edd712c343a9de7b205a74", "source": "security-advisories@github.com"}, {"url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-j9rw-x2wv-h5rj", "source": "security-advisories@github.com"}], "vulnStatus": "Deferred", "weaknesses": [{"type": "Secondary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-287"}]}], "descriptions": [{"lang": "en", "value": "OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, the registration handler at `POST /api/auth/register/{userId}` validates the relationship between the WebAuthn challenge and the registration cookie's email but never validates that the `userId` in the URL belongs to that email. An unauthenticated attacker requests a challenge for their own email, generates a registration response with their own authenticator, and submits it against any victim user's URL. The challenge-vs-cookie email match passes, the WebAuthn ceremony validates, and `addPasskey` writes the attacker's credential into the victim's `user_passkey` rows. The next victim-email login accepts a passkey assertion from the attacker's authenticator and issues a session as the victim. User IDs are not strictly secret on this platform, but the exact set of exposure surfaces should be assessed by the maintainers. Staff-list endpoints return user IDs to authenticated tenant members per the route signature; live verification of all exposure surfaces (whether user IDs leak through any unauthenticated route, through invite-confirmation URLs, or through other administrative views) is part of the pending live PoC. Where the attacker knows the victim's email and userId, the analysis below becomes account takeover. 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, el gestor de registro en \u201cPOST /api/auth/register/{userId}\u201d valida la relaci\u00f3n entre el desaf\u00edo WebAuthn y el correo electr\u00f3nico de la cookie de registro, pero nunca valida que el \u201cuserId\u201d en la URL pertenezca a ese correo electr\u00f3nico. Un atacante no autenticado solicita un desaf\u00edo para su propio correo electr\u00f3nico, genera una respuesta de registro con su propio autenticador y lo env\u00eda contra la URL de cualquier usuario v\u00edctima. La coincidencia de correo electr\u00f3nico entre el desaf\u00edo y la cookie pasa, la ceremonia WebAuthn se valida y \u201caddPasskey\u201d escribe la credencial del atacante en las filas \u201cuser_passkey\u201d de la v\u00edctima. El siguiente inicio de sesi\u00f3n con el correo electr\u00f3nico de la v\u00edctima acepta una aserci\u00f3n de clave de acceso del autenticador del atacante y emite una sesi\u00f3n como la v\u00edctima. Los ID de usuario no son estrictamente secretos en esta plataforma, pero el conjunto exacto de superficies de exposici\u00f3n debe ser evaluado por los mantenedores. Los endpoints de lista de personal devuelven ID de usuario a los miembros de inquilinos autenticados seg\u00fan la firma de la ruta; la verificaci\u00f3n en vivo de todas las superficies de exposici\u00f3n (ya sea que los ID de usuario se filtren a trav\u00e9s de cualquier ruta no autenticada, a trav\u00e9s de URL de confirmaci\u00f3n de invitaci\u00f3n o a trav\u00e9s de otras vistas administrativas) es parte de la PoC en vivo pendiente. Cuando el atacante conoce el correo electr\u00f3nico y el userId de la v\u00edctima, el an\u00e1lisis a continuaci\u00f3n se convierte en una toma de control de cuenta. La versi\u00f3n 1.0.2 corrige el problema."}], "lastModified": "2026-10-23T21:10:00.157", "sourceIdentifier": "security-advisories@github.com"}