{"api_version":"1","generated_at":"2026-08-07T23:21:32+00:00","cve":"CVE-2026-48088","urls":{"html":"https://cve.report/CVE-2026-48088","api":"https://cve.report/api/cve/CVE-2026-48088.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-48088","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-48088"},"summary":{"title":"OpenReception vulnerable to unauthenticated staff crypto poisoning that breaks E2E recipient directory","description":"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. 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.","state":"PUBLISHED","assigner":"GitHub_M","published_at":"2026-08-06 22:17:11","updated_at":"2026-08-06 22:17:11"},"problem_types":["CWE-862","CWE-862 CWE-862: Missing Authorization"],"metrics":[{"version":"3.1","source":"security-advisories@github.com","type":"Secondary","score":"9.4","severity":"CRITICAL","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L","baseScore":9.4,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"LOW"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"9.4","severity":"CRITICAL","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L","data":{"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":[{"url":"https://github.com/open-reception/appointment-booking-software/commit/78dfd9317a0be0897e6e4d73afe670c07a75460f","name":"https://github.com/open-reception/appointment-booking-software/commit/78dfd9317a0be0897e6e4d73afe670c07a75460f","refsource":"security-advisories@github.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-pch3-hcmf-cjw4","name":"https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-pch3-hcmf-cjw4","refsource":"security-advisories@github.com","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-48088","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-48088","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"open-reception","product":"appointment-booking-software","version":"affected < 1.0.4","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"product":"appointment-booking-software","vendor":"open-reception","versions":[{"status":"affected","version":"< 1.0.4"}]}],"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 `<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. 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."}],"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"}}],"problemTypes":[{"descriptions":[{"cweId":"CWE-862","description":"CWE-862: Missing Authorization","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-08-06T21:34:32.016Z","orgId":"a0819718-46f1-4df5-94e2-005712e83aaa","shortName":"GitHub_M"},"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"}],"source":{"advisory":"GHSA-pch3-hcmf-cjw4","discovery":"UNKNOWN"},"title":"OpenReception vulnerable to unauthenticated staff crypto poisoning that breaks E2E recipient directory"}},"cveMetadata":{"assignerOrgId":"a0819718-46f1-4df5-94e2-005712e83aaa","assignerShortName":"GitHub_M","cveId":"CVE-2026-48088","datePublished":"2026-08-06T21:34:32.016Z","dateReserved":"2026-05-20T18:40:45.833Z","dateUpdated":"2026-08-06T21:34:32.016Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-08-06 22:17:11","lastModifiedDate":"2026-08-06 22:17:11","problem_types":["CWE-862","CWE-862 CWE-862: Missing Authorization"],"metrics":{"cvssMetricV31":[{"source":"security-advisories@github.com","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L","baseScore":9.4,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"LOW"},"exploitabilityScore":3.9,"impactScore":5.5}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"48088","Ordinal":"1","Title":"OpenReception vulnerable to unauthenticated staff crypto poisoni","CVE":"CVE-2026-48088","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"48088","Ordinal":"1","NoteData":"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. 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.","Type":"Description","Title":"OpenReception vulnerable to unauthenticated staff crypto poisoni"}]}}}