https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 23:21:18 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-349354 EUVD-2026-349354 https://cve.radiocsirt.org/vuln/euvd-2026-349354 https://cve.radiocsirt.org/vuln/fkie_cve-2026-48087 <p>OpenReception&#39;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&#39;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&#39;s URL. The challenge-vs-cookie email match passes, the WebAuthn ceremony validates, and `addPasskey` writes the attacker&#39;s credential into the victim&#39;s `user_passkey` rows. The next victim-email login accepts a passkey assertion from the attacker&#39;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&#39;s email and userId, the analysis below becomes account takeover. Version 1.0.2 fixes the issue.</p> <p>OpenReception&#39;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&#39;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&#39;s URL. The challenge-vs-cookie email match passes, the WebAuthn ceremony validates, and `addPasskey` writes the attacker&#39;s credential into the victim&#39;s `user_passkey` rows. The next victim-email login accepts a passkey assertion from the attacker&#39;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&#39;s email and userId, the analysis below becomes account takeover. Version 1.0.2 fixes the issue.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-48087