CVE-2026-48075

{
  "id": "CVE-2026-48075",
  "sourceIdentifier": "[email protected]",
  "published": "2026-08-06T22:17:09.977",
  "lastModified": "2026-10-23T21:10:00.157",
  "vulnStatus": "Deferred",
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.5, the `add-to-tunnel` endpoint creates a new appointment row in any client tunnel without any caller authentication. A request that supplies any valid `tunnelId` and any valid `emailHash` (the two need not belong to the same tunnel) results in an inserted appointment with `status = \"CONFIRMED\"`, attacker-controlled ciphertext fields, attacker-controlled date and duration, and an attacker-chosen agent. The endpoint validates only that some tunnel exists with the given `emailHash`, then writes the appointment using the attacker-supplied `tunnelId` directly. The `emailHash` lookup is effectively an existence check on the tenant; it does not authenticate the caller as the owner of the supplied `tunnelId`. Combined with the absence of any session, Authorization header, booking access token, or PoW, this makes the endpoint accept arbitrary appointment writes into arbitrary tunnels. By contrast, the sibling endpoint `create-new-client` (used to bootstrap a brand-new client tunnel) requires a Bearer bootstrap booking access token issued by the bootstrap-challenge / bootstrap-verify flow. The `add-to-tunnel` endpoint, intended for return-clients booking additional appointments, has no equivalent gate. The application's own middleware confirms this is intentional: `add-to-tunnel` is explicitly listed in the apiAuthHandle public-route allowlist alongside the bootstrap and challenge endpoints (which legitimately have no session). Version 1.0.5 fixes the issue."
    },
    {
      "lang": "es",
      "value": "El software de reserva de citas de OpenReception proporciona una plataforma de reserva de citas cifrada de extremo a extremo. Antes de la versión 1.0.5, el endpoint “add-to-tunnel” crea una nueva fila de cita en cualquier túnel de cliente sin ninguna autenticación del llamante. Una solicitud que proporciona cualquier “tunnelId” válido y cualquier “emailHash” válido (los dos no necesitan pertenecer al mismo túnel) resulta en una cita insertada con “status = “CONFIRMED””, campos de texto cifrado controlados por el atacante, fecha y duración controladas por el atacante, y un agente elegido por el atacante. El endpoint valida solo que existe algún túnel con el “emailHash” dado, luego escribe la cita usando directamente el “tunnelId” proporcionado por el atacante. La búsqueda de “emailHash” es efectivamente una verificación de existencia en el inquilino; no autentica al llamante como el propietario del “tunnelId” proporcionado. Combinado con la ausencia de cualquier sesión, encabezado de autorización, token de acceso de reserva o PoW, esto hace que el endpoint acepte escrituras de citas arbitrarias en túneles arbitrarios. Por el contrario, el endpoint hermano “create-new-client” (utilizado para arrancar un túnel de cliente completamente nuevo) requiere un token de acceso de reserva de arranque Bearer emitido por el flujo bootstrap-challenge / bootstrap-verify. El endpoint “add-to-tunnel”, destinado a clientes recurrentes que reservan citas adicionales, no tiene una puerta equivalente. El propio middleware de la aplicación confirma que esto es intencional: “add-to-tunnel” está explícitamente listado en la lista de permitidos de rutas públicas de apiAuthHandle junto con los endpoints de arranque y desafío (los cuales legítimamente no tienen sesión). La versión 1.0.5 corrige el problema."
    }
  ],
  "affected": [
    {
      "source": "[email protected]",
      "affectedData": [
        {
          "vendor": "open-reception",
          "product": "appointment-booking-software",
          "versions": [
            {
              "version": "< 1.0.5",
              "status": "affected"
            }
          ]
        }
      ]
    }
  ],
  "metrics": {
    "cvssMetricV31": [
      {
        "source": "[email protected]",
        "type": "Secondary",
        "cvssData": {
          "version": "3.1",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L",
          "baseScore": 6.5,
          "baseSeverity": "MEDIUM",
          "attackVector": "NETWORK",
          "attackComplexity": "HIGH",
          "privilegesRequired": "NONE",
          "userInteraction": "NONE",
          "scope": "UNCHANGED",
          "confidentialityImpact": "NONE",
          "integrityImpact": "HIGH",
          "availabilityImpact": "LOW"
        },
        "exploitabilityScore": 2.2,
        "impactScore": 4.2
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "timestamp": "2026-08-07T17:14:46.685036Z",
          "id": "CVE-2026-48075",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "version": "2.0.3"
        }
      }
    ]
  },
  "weaknesses": [
    {
      "source": "[email protected]",
      "type": "Secondary",
      "description": [
        {
          "lang": "en",
          "value": "CWE-862"
        }
      ]
    }
  ],
  "references": [
    {
      "url": "https://github.com/open-reception/appointment-booking-software/commit/4522a44c001782848faff5529d7c1e2be7ac9ef5",
      "source": "[email protected]"
    },
    {
      "url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-rhp5-vmcx-4qm8",
      "source": "[email protected]"
    },
    {
      "url": "https://github.com/open-reception/appointment-booking-software/security/advisories/GHSA-rhp5-vmcx-4qm8",
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0"
    }
  ]
}