https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 07:51:04 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-349500 EUVD-2026-349500 https://cve.radiocsirt.org/vuln/euvd-2026-349500 https://cve.radiocsirt.org/vuln/fkie_cve-2026-48071 <p>OpenReception&#39;s appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.4, the PIN-type challenge throttle uses `emailHash` as the only key. The throttle rows live in the central `challenge_throttle` table, which is shared across all tenants. Every tenant&#39;s `/api/tenants/{id}/appointments/verify-challenge` endpoint increments the same row when a PIN response fails, and every tenant&#39;s `/api/tenants/{id}/appointments/challenge` endpoint reads the same row when deciding whether to issue a new challenge. When the same `emailHash` exists in multiple tenants on the same OpenReception instance (the same patient holding tunnels in two different clinics that share the platform), an attacker who knows the patient&#39;s email can lock out that patient on tenant B by issuing failed challenge responses against tenant A. The attacker needs no relationship to tenant B; the lockout propagates through the shared throttle row. The lockout escalates with repeated failures. The first lockout triggers at 4 failed attempts and lasts approximately 60 seconds. Subsequent failures escalate the lockout duration to 5 minutes, 30 minutes, and 60 minutes per the throttle service&#39;s escalation logic. Repeated bursts produce sustained denial of service against the targeted email. Version 1.0.4 patches the issue.</p> <p>OpenReception&#39;s appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.4, the PIN-type challenge throttle uses `emailHash` as the only key. The throttle rows live in the central `challenge_throttle` table, which is shared across all tenants. Every tenant&#39;s `/api/tenants/{id}/appointments/verify-challenge` endpoint increments the same row when a PIN response fails, and every tenant&#39;s `/api/tenants/{id}/appointments/challenge` endpoint reads the same row when deciding whether to issue a new challenge. When the same `emailHash` exists in multiple tenants on the same OpenReception instance (the same patient holding tunnels in two different clinics that share the platform), an attacker who knows the patient&#39;s email can lock out that patient on tenant B by issuing failed challenge responses against tenant A. The attacker needs no relationship to tenant B; the lockout propagates through the shared throttle row. The lockout escalates with repeated failures. The first lockout triggers at 4 failed attempts and lasts approximately 60 seconds. Subsequent failures escalate the lockout duration to 5 minutes, 30 minutes, and 60 minutes per the throttle service&#39;s escalation logic. Repeated bursts produce sustained denial of service against the targeted email. Version 1.0.4 patches the issue.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-48071