https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 16:40:03 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-349511 EUVD-2026-349511 https://cve.radiocsirt.org/vuln/euvd-2026-349511 https://cve.radiocsirt.org/vuln/fkie_cve-2026-48088 <p>OpenReception&#39;s appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.4, the route `POST /api/tenants/{tenantId}/staff/{staffId}/crypto` accepts and stores attacker-controlled ML-KEM-768 public keys against any tenant on the platform without authentication. The handler logs an &#34;Unauthorized crypto key storage attempt&#34; warning when neither a session nor a registration cookie is present, then proceeds to insert the row regardless. The platform&#39;s E2E claim that &#34;even administrators cannot view sensitive information&#34; is broken: any unauthenticated network attacker can register themselves as an additional encryption recipient for any tenant&#39;s future patient appointments. A second variant of the bug suppresses the unauthorized-warning log entry. The Zod schema makes the `email` field optional. When the request body omits `email` and the request carries no registration cookie, the comparison `registrationEmail === email` becomes `undefined === undefined`, which evaluates to `true`. The handler treats the request as a legitimate registration flow, skips the warning entirely, and stores the row. Successful storage is still recorded as an `[info]` log line, but the security-relevant warning that operators are most likely to monitor or alert on is gone. The `staff_crypto` table has no unique constraint on `user_id`, so an arbitrary number of attacker rows can coexist for the same staff identifier and all return as `is_active=tr…</p> <p>OpenReception&#39;s appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.4, the route `POST /api/tenants/{tenantId}/staff/{staffId}/crypto` accepts and stores attacker-controlled ML-KEM-768 public keys against any tenant on the platform without authentication. The handler logs an &#34;Unauthorized crypto key storage attempt&#34; warning when neither a session nor a registration cookie is present, then proceeds to insert the row regardless. The platform&#39;s E2E claim that &#34;even administrators cannot view sensitive information&#34; is broken: any unauthenticated network attacker can register themselves as an additional encryption recipient for any tenant&#39;s future patient appointments. A second variant of the bug suppresses the unauthorized-warning log entry. The Zod schema makes the `email` field optional. When the request body omits `email` and the request carries no registration cookie, the comparison `registrationEmail === email` becomes `undefined === undefined`, which evaluates to `true`. The handler treats the request as a legitimate registration flow, skips the warning entirely, and stores the row. Successful storage is still recorded as an `[info]` log line, but the security-relevant warning that operators are most likely to monitor or alert on is gone. The `staff_crypto` table has no unique constraint on `user_id`, so an arbitrary number of attacker rows can coexist for the same staff identifier and all return as `is_active=tr…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-48088