CVE-2026-48076 (GCVE-0-2026-48076)
Vulnerability from cvelistv5 – Published: 2026-08-06 20:43 – Updated: 2026-08-07 14:34- CWE-863 - Incorrect Authorization
| URL | Tags |
|---|---|
| https://github.com/open-reception/appointment-boo… | x_refsource_CONFIRM |
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| open-reception | appointment-booking-software |
Affected:
<= 1.0.1
|
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-48076",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-07T14:34:15.376977Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-07T14:34:21.718Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-3658-3j75-p5j3"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "appointment-booking-software",
"vendor": "open-reception",
"versions": [
{
"status": "affected",
"version": "\u003c= 1.0.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "OpenReception\u0027s appointment booking software provides an end-to-end encrypted appointment booking platform. The new-client booking flow in versions 1.0.1 and prior consists of three calls: `bootstrap-challenge` (returns a 16-bit PoW challenge with `difficulty=4` leading hex zeroes), `bootstrap-verify` (validates the PoW and issues a Bearer booking access token), and `create-new-client` (consumes the token and creates the tunnel and first appointment). The token correctly binds to `tenantId`, `tunnelId`, `clientPublicKey`, and `emailHash`, but never to `channelId`. The `bootstrap-challenge` request schema does not even accept a `channelId`, and the issued token\u0027s payload contains no channel information. Independently, the service function `createNewClientWithAppointment` checks only `channel.archived = false`. The `channel.isPublic` check that protects `addAppointmentToTunnel` is missing in the new-client path. The combination means: an attacker completes the bootstrap flow normally (16-bit PoW, completes in well under one second on commodity hardware, no rate limiting beyond the throttle store), receives a valid booking access token, and then submits the `create-new-client` payload with `channelId` pointing to a private (`isPublic = false`) channel. The booking lands as `CONFIRMED` if the target channel has `requiresConfirmation = false` (the default), otherwise as `NEW`. The patient-facing UI does not list private channels in its picker (`/api/public/channels` correctly filters `isPublic = true`), so the channel ID must be obtained out of band. The companion finding V-10 (schedule endpoint discloses private channels) provides exactly that: a single unauthenticated GET reveals every private channel ID for any tenant. V-10 plus V-11 together make private channels fully reachable to anonymous attackers. As of time of publication, no known patched versions are available."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863: Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-06T20:43:59.953Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-3658-3j75-p5j3",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-3658-3j75-p5j3"
}
],
"source": {
"advisory": "GHSA-3658-3j75-p5j3",
"discovery": "UNKNOWN"
},
"title": "OpenReception\u0027s bootstrap booking flow allows unauthenticated booking on isPublic=false channels"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-48076",
"datePublished": "2026-08-06T20:43:59.953Z",
"dateReserved": "2026-05-20T18:25:25.708Z",
"dateUpdated": "2026-08-07T14:34:21.718Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-48076",
"date": "2026-11-12",
"epss": "0.00332",
"percentile": "0.26794"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"product": "appointment-booking-software",
"vendor": "open-reception",
"versions": [
{
"status": "affected",
"version": "\u003c= 1.0.1"
}
]
}
],
"source": "security-advisories@github.com"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "OpenReception\u0027s appointment booking software provides an end-to-end encrypted appointment booking platform. The new-client booking flow in versions 1.0.1 and prior consists of three calls: `bootstrap-challenge` (returns a 16-bit PoW challenge with `difficulty=4` leading hex zeroes), `bootstrap-verify` (validates the PoW and issues a Bearer booking access token), and `create-new-client` (consumes the token and creates the tunnel and first appointment). The token correctly binds to `tenantId`, `tunnelId`, `clientPublicKey`, and `emailHash`, but never to `channelId`. The `bootstrap-challenge` request schema does not even accept a `channelId`, and the issued token\u0027s payload contains no channel information. Independently, the service function `createNewClientWithAppointment` checks only `channel.archived = false`. The `channel.isPublic` check that protects `addAppointmentToTunnel` is missing in the new-client path. The combination means: an attacker completes the bootstrap flow normally (16-bit PoW, completes in well under one second on commodity hardware, no rate limiting beyond the throttle store), receives a valid booking access token, and then submits the `create-new-client` payload with `channelId` pointing to a private (`isPublic = false`) channel. The booking lands as `CONFIRMED` if the target channel has `requiresConfirmation = false` (the default), otherwise as `NEW`. The patient-facing UI does not list private channels in its picker (`/api/public/channels` correctly filters `isPublic = true`), so the channel ID must be obtained out of band. The companion finding V-10 (schedule endpoint discloses private channels) provides exactly that: a single unauthenticated GET reveals every private channel ID for any tenant. V-10 plus V-11 together make private channels fully reachable to anonymous attackers. As of time of publication, no known patched versions are available."
},
{
"lang": "es",
"value": "El software de reserva de citas de OpenReception proporciona una plataforma de reserva de citas cifrada de extremo a extremo. El flujo de reserva de nuevo cliente en las versiones 1.0.1 y anteriores consta de tres llamadas: \u201cbootstrap-challenge\u201d (devuelve un desaf\u00edo PoW de 16 bits con \u201cdifficulty=4\u201d ceros hexadecimales iniciales), \u201cbootstrap-verify\u201d (valida el PoW y emite un token de acceso de reserva Bearer), y \u201ccreate-new-client\u201d (consume el token y crea el t\u00fanel y la primera cita). El token se vincula correctamente a \u201ctenantId\u201d, \u201ctunnelId\u201d, \u201cclientPublicKey\u201d, y \u201cemailHash\u201d, pero nunca a \u201cchannelId\u201d. El esquema de solicitud de \u201cbootstrap-challenge\u201d ni siquiera acepta un \u201cchannelId\u201d, y la carga \u00fatil del token emitido no contiene informaci\u00f3n de canal. Independientemente, la funci\u00f3n de servicio \u201ccreateNewClientWithAppointment\u201d solo verifica \u201cchannel.archived = false\u201d. La verificaci\u00f3n de \u201cchannel.isPublic\u201d que protege \u201caddAppointmentToTunnel\u201d falta en la ruta de nuevo cliente. La combinaci\u00f3n significa: un atacante completa el flujo de arranque normalmente (PoW de 16 bits, se completa en bastante menos de un segundo en hardware comercial, sin limitaci\u00f3n de velocidad m\u00e1s all\u00e1 del almac\u00e9n de aceleraci\u00f3n), recibe un token de acceso de reserva v\u00e1lido, y luego env\u00eda la carga \u00fatil de \u201ccreate-new-client\u201d con \u201cchannelId\u201d apuntando a un canal privado (\u201cisPublic = false\u201d). La reserva se registra como \u201cCONFIRMED\u201d si el canal de destino tiene \u201crequiresConfirmation = false\u201d (el valor predeterminado), de lo contrario, como \u201cNEW\u201d. La interfaz de usuario orientada al paciente no lista canales privados en su selector (\u201c/api/public/channels\u201d filtra correctamente \u201cisPublic = true\u201d), por lo que el ID del canal debe obtenerse fuera de banda. El hallazgo complementario V-10 (el endpoint de programaci\u00f3n revela canales privados) proporciona exactamente eso: una \u00fanica solicitud GET no autenticada revela cada ID de canal privado para cualquier inquilino. V-10 m\u00e1s V-11 juntos hacen que los canales privados sean totalmente accesibles para atacantes an\u00f3nimos. A partir del momento de la publicaci\u00f3n, no hay versiones parcheadas conocidas disponibles."
}
],
"id": "CVE-2026-48076",
"lastModified": "2026-10-23T21:10:00.157",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"version": "3.1"
},
"exploitabilityScore": 3.9,
"impactScore": 2.5,
"source": "security-advisories@github.com",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-48076",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "yes"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-07T14:34:15.376977Z",
"version": "2.0.3"
}
}
]
},
"published": "2026-08-06T22:17:10.127",
"references": [
{
"source": "security-advisories@github.com",
"url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-3658-3j75-p5j3"
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-3658-3j75-p5j3"
}
],
"sourceIdentifier": "security-advisories@github.com",
"vulnStatus": "Deferred",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-863"
}
],
"source": "security-advisories@github.com",
"type": "Secondary"
}
]
}
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-48076",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-07T14:34:15.376977Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-07T14:33:57.883Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-3658-3j75-p5j3"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "appointment-booking-software",
"vendor": "open-reception",
"versions": [
{
"status": "affected",
"version": "\u003c= 1.0.1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "OpenReception\u0027s appointment booking software provides an end-to-end encrypted appointment booking platform. The new-client booking flow in versions 1.0.1 and prior consists of three calls: `bootstrap-challenge` (returns a 16-bit PoW challenge with `difficulty=4` leading hex zeroes), `bootstrap-verify` (validates the PoW and issues a Bearer booking access token), and `create-new-client` (consumes the token and creates the tunnel and first appointment). The token correctly binds to `tenantId`, `tunnelId`, `clientPublicKey`, and `emailHash`, but never to `channelId`. The `bootstrap-challenge` request schema does not even accept a `channelId`, and the issued token\u0027s payload contains no channel information. Independently, the service function `createNewClientWithAppointment` checks only `channel.archived = false`. The `channel.isPublic` check that protects `addAppointmentToTunnel` is missing in the new-client path. The combination means: an attacker completes the bootstrap flow normally (16-bit PoW, completes in well under one second on commodity hardware, no rate limiting beyond the throttle store), receives a valid booking access token, and then submits the `create-new-client` payload with `channelId` pointing to a private (`isPublic = false`) channel. The booking lands as `CONFIRMED` if the target channel has `requiresConfirmation = false` (the default), otherwise as `NEW`. The patient-facing UI does not list private channels in its picker (`/api/public/channels` correctly filters `isPublic = true`), so the channel ID must be obtained out of band. The companion finding V-10 (schedule endpoint discloses private channels) provides exactly that: a single unauthenticated GET reveals every private channel ID for any tenant. V-10 plus V-11 together make private channels fully reachable to anonymous attackers. As of time of publication, no known patched versions are available."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "LOW",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863: Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-06T20:43:59.953Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-3658-3j75-p5j3",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-3658-3j75-p5j3"
}
],
"source": {
"advisory": "GHSA-3658-3j75-p5j3",
"discovery": "UNKNOWN"
},
"title": "OpenReception\u0027s bootstrap booking flow allows unauthenticated booking on isPublic=false channels"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-48076",
"datePublished": "2026-08-06T20:43:59.953Z",
"dateReserved": "2026-05-20T18:25:25.708Z",
"dateUpdated": "2026-08-07T14:34:21.718Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.