PatchSiren cyber security CVE debrief
CVE-2026-48088 open-reception CVE debrief
AI-assisted PatchSiren debrief based on the supplied source corpus. The CVE record was published on 2026-08-06T22:17:11.893Z and has not been modified since then. OpenReception'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 'Unauthorized crypto key storage attempt' warning when neither a session nor a registration cookie is present, then proceeds to insert the row regardless. The platform's E2E claim that 'even administrators cannot view sensitive information' is broken: any unauthenticated network attacker can register themselves as an additional encryption recipient for any tenant'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=true`. The supplied `staffId` does not need to match any existing user or pending invite. Schema validation on `passkeyId`, `publicKey`, and `privateKeyShare` is also weak: the literal string `<placeholder-base64>` was accepted, indicating no length, format, or cryptographic-validity check beyond field presence. This weakness is independent of the auth bypass but compounds it: a poisoned directory can also be filled with malformed entries that break legitimate booking flows. The injected key is consumed by the public booking flow. To
- Vendor
- open-reception
- Product
- appointment-booking-software
- CVSS
- CRITICAL 9.4
- CISA KEV
- Not listed in stored evidence
- Original CVE published
- 2026-08-06
- Original CVE updated
- 2026-08-08
- Advisory published
- 2026-08-06
- Advisory updated
- 2026-08-08
Who should care
Administrators and users of OpenReception's appointment booking software should be aware of this critical vulnerability and take immediate action to patch the affected endpoint. Additionally, security teams and threat hunters should monitor for suspicious activity and implement compensating controls to prevent exploitation.
Technical summary
The vulnerability is caused by the lack of authentication and authorization checks in the 'POST /api/tenants/{tenantId}/staff/{staffId}/crypto' endpoint, which allows an attacker to store their own ML-KEM-768 public keys against any tenant on the platform. The platform's E2E claim is broken, and any unauthenticated network attacker can register themselves as an additional encryption recipient for any tenant's future patient appointments.
Defensive priority
CVE-2026-48088 is a critical vulnerability with a CVSS score of 9.4. The vulnerability allows an unauthenticated attacker to register themselves as an additional encryption recipient for any tenant's future patient appointments, breaking the platform's end-to-end encryption claim. To address this vulnerability, it is recommended to implement authentication and authorization checks for the affected endpoint, validate and sanitize user input, and ensure that the 'staff_crypto' table has a unique constraint on 'user_id'.
Recommended defensive actions
- Implement authentication and authorization checks for the affected endpoint
- Validate and sanitize user input
- Ensure that the 'staff_crypto' table has a unique constraint on 'user_id'
- Monitor for suspicious activity and implement compensating controls
- Perform inventory checks and verify vendor remediation
Evidence notes
The vulnerability is caused by the lack of authentication and authorization checks in the 'POST /api/tenants/{tenantId}/staff/{staffId}/crypto' endpoint, which allows an attacker to store their own ML-KEM-768 public keys against any tenant on the platform. The platform's E2E claim is broken, and any unauthenticated network attacker can register themselves as an additional encryption recipient for any tenant's future patient appointments. The 'staff_crypto' table has no unique constraint on 'user_id', allowing an arbitrary number of attacker rows to coexist for the same staff identifier.
Official resources
AI-assisted PatchSiren debrief based on the supplied source corpus. The CVE record was published on 2026-08-06T22:17:11.893Z and has not been modified since then.