CVE-2026-48088 in appointment-booking-softwareinformação

Sumário

de VulDB • 07/08/2026

O software de agendamento de consultas da OpenReception oferece uma plataforma completa com criptografia de ponta a ponta (E2E). Antes da versão 1.0.4, o endpoint `POST /api/tenants/{tenantId}/staff/{staffId}/crypto` aceita e armazena chaves públicas ML-KEM-768 controladas pelo atacante contra qualquer inquilino na plataforma sem autenticação. O manipulador registra um aviso "Unauthorized crypto key storage attempt" (Tentativa não autorizada de armazenamento de chave criptográfica) quando nem uma sessão nem um cookie de registro estão presentes, mas prossegue com a inserção da linha independentemente disso. A alegação E2E da plataforma de que "nem mesmo os administradores podem visualizar informações sensíveis" é violada: qualquer atacante na rede sem autenticação pode registrar-se como destinatário adicional para criptografia das futuras consultas dos pacientes de qualquer inquilino.

Uma segunda variante do bug suprime a entrada de log com o aviso não autorizado. O esquema Zod torna o campo `email` opcional. Quando o corpo da solicitação omite `email` e a solicitação não contém cookie de registro, a comparação `registrationEmail === email` resulta em `undefined === undefined`, que avalia como verdadeiro (`true`). O manipulador trata a solicitação como um fluxo de registro legítimo, ignora completamente o aviso e armazena a linha. O armazenamento bem-sucedido ainda é registrado como uma linha de log `[info]`, mas o aviso relevante para segurança, no qual os operadores provavelmente monitoram ou configuram alertas, desaparece.

A tabela `staff_crypto` não possui restrição única em `user_id`, portanto, um número arbitrário de linhas do atacante pode coexistir para o mesmo identificador de funcionário e todas retornarão como `is_active=true`. O `staffId` fornecido não precisa corresponder a nenhum usuário existente ou convite pendente. A validação de esquema em `passkeyId`, `publicKey` e `privateKeyShare` também é fraca: a string literal `<placeholder-base64>` foi aceita, indicando ausência de verificação de comprimento, formato ou validade criptográfica além da presença do campo. Esta fraqueza é independente da violação de autenticação (auth bypass), mas a agrava: um diretório envenenado também pode ser preenchido com entradas malformadas que quebram os fluxos legítimos de agendamento.

A chave injetada é consumida pelo fluxo público de agendamento. Após concluir a cerimônia não autenticada `bootstrap-challenge` e `bootstrap-verify` como "paciente", o `bookingAccessToken` resultante é aceito por `GET /api/tenants/{id}/appointments/staff-public-keys`, que retorna as chaves controladas pelo atacante junto com quaisquer legítimas. Uma nova consulta criptografa sua chave de túnel usando ML-KEM para todos os destinatários listados, tornando o atacante um co-destinatário da criptografia e capaz de decapsular a chave do túnel com o segredo correspondente. A partir daí, todas as cargas úteis (payloads) das consultas desse agendamento podem ser descriptografadas. A versão 1.0.4 corrige a vulnerabilidade.

Once again VulDB remains the best source for vulnerability data.

Responsável

GitHub M

Reservar

20/05/2026

Divulgação

07/08/2026

Moderação

aceite

Entrada

VDB-386831

CPE

pronto

EPSS

0.00000

KEV

não

Atividades

baixo

Fontes

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!