{ "dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": { "cveId": "CVE-2026-48088", "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "state": "PUBLISHED", "assignerShortName": "GitHub_M", "dateReserved": "2026-05-20T18:40:45.833Z", "datePublished": "2026-08-06T21:34:32.016Z", "dateUpdated": "2026-08-08T02:47:46.506Z" }, "containers": { "cna": { "title": "OpenReception vulnerable to unauthenticated staff crypto poisoning that breaks E2E recipient directory", "problemTypes": [ { "descriptions": [ { "cweId": "CWE-862", "lang": "en", "description": "CWE-862: Missing Authorization", "type": "CWE" } ] } ], "metrics": [ { "cvssV3_1": { "attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "LOW", "baseScore": 9.4, "baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L", "version": "3.1" } } ], "references": [ { "name": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-pch3-hcmf-cjw4", "tags": [ "x_refsource_CONFIRM" ], "url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-pch3-hcmf-cjw4" }, { "name": "https://github.com/open-reception/appointment-booking-software/commit/78dfd9317a0be0897e6e4d73afe670c07a75460f", "tags": [ "x_refsource_MISC" ], "url": "https://github.com/open-reception/appointment-booking-software/commit/78dfd9317a0be0897e6e4d73afe670c07a75460f" } ], "affected": [ { "vendor": "open-reception", "product": "appointment-booking-software", "versions": [ { "version": "< 1.0.4", "status": "affected" } ] } ], "providerMetadata": { "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa", "shortName": "GitHub_M", "dateUpdated": "2026-08-06T21:34:32.016Z" }, "descriptions": [ { "lang": "en", "value": "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 `` 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. After completing the unauthenticated `bootstrap-challenge` and `bootstrap-verify` ceremony as a \"patient\", the resulting `bookingAccessToken` is accepted by `GET /api/tenants/{id}/appointments/staff-public-keys`, which returns the attacker-controlled keys alongside any legitimate ones. A new appointment encrypts its tunnel key with ML-KEM to all listed recipients, so the attacker becomes a co-recipient of the encryption and can decapsulate the tunnel key with the matching secret. From there, all appointment payloads for that booking are decryptable. Version 1.0.4 patches the issue." } ], "source": { "advisory": "GHSA-pch3-hcmf-cjw4", "discovery": "UNKNOWN" } }, "adp": [ { "references": [ { "url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-pch3-hcmf-cjw4", "tags": [ "exploit" ] } ], "metrics": [ { "other": { "type": "ssvc", "content": { "timestamp": "2026-08-08T02:47:21.298201Z", "id": "CVE-2026-48088", "options": [ { "Exploitation": "poc" }, { "Automatable": "yes" }, { "Technical Impact": "total" } ], "role": "CISA Coordinator", "version": "2.0.3" } } } ], "title": "CISA ADP Vulnrichment", "providerMetadata": { "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-08-08T02:47:46.506Z" } } ] } }