Dorakemon

**Nome do Software Vulnerável e Versões Afetadas** Vaultwarden versões anteriores a 1.35.5 **Descrição** O fluxo de autenticação WebAuthn na função `validate webauthn login()` atualiza metadados persistentes de credenciais, especificamente as flags `backup eligible` e `backup state`, usando `authenticatorData` não verificado antes que a validação da assinatura seja realizada. Um invasor que possua a senha de um usuário pode modificar permanentemente essas flags de backup armazenadas, mesmo sem uma assinatura WebAuthn válida, pois as atualizações do banco de dados não são revertidas caso a verificação da assinatura falhe. Isso resulta em uma negação de serviço persistente da autenticação de dois fatores WebAuthn para as credenciais afetadas. **Recomendações** Atualize para a versão 1.35.5.

**Nome do Software Vulnerável e Versões Afetadas** versões anteriores à 5.2.4 do web-auth/webauthn-lib **Descrição** O processo de validação de origem do software, ao utilizar a configuração `allowed origins`, reduz valores semelhantes a URL ao seu componente de host, aceitando correspondências com base apenas no host. Isso impede a implementação de políticas de origem exatas, já que diferenças de esquema e porta são ignoradas. Especificamente, o componente `CheckAllowedOrigins` utiliza `parse url()` para extrair o host tanto das origens permitidas configuradas quanto da `clientDataJSON.origin` recebida. Essa redução permite que solicitações com esquemas ou portas diferentes contornem a validação de origem pretendida. Esse problema afeta implantações que utilizam a configuração `allowed origins` e contorna a verificação de origem exata exigida pelos padrões WebAuthn. O componente vulnerável é o `CheckAllowedOrigins.php`. O parâmetro vulnerável é o `clientDataJSON.origin`. **Recomendações** Atualize para a versão 5.2.4 ou posterior para resolver este problema.

**Nome do Software Vulnerável e Versões Afetadas** Versões do Pocket ID anteriores à 2.4.0 **Descrição** O Pocket ID é um provedor OIDC suscetível à troca de código entre clientes e à reutilização de código expirado. O endpoint de token OIDC valida incorretamente os códigos de autorização, rejeitando-os apenas quando tanto o ID do cliente está incorreto quanto o código está expirado. Essa falha permite que um atacante troque códigos de autorização emitidos para um cliente pelas credenciais de outro cliente, potencialmente obtendo tokens para usuários que não autorizaram o cliente malicioso. Códigos de autorização expirados também podem ser reutilizados até que um processo de limpeza seja executado. O problema reside no arquivo `backend/internal/service/oidc service.go`, especificamente na linha 407, onde um `E` lógico (`&&`) deveria ser um `OU` lógico (`||`) na lógica de validação do código de autorização. O código vulnerável é: `if authorizationCodeMetaData.ClientID != input.ClientID && authorizationCodeMetaData.ExpiresAt.ToTime().Before(time.Now())`. Um atacante pode explorar isso usando um código de autorização válido destinado a um cliente com o ID do cliente de outro cliente para obter tokens de acesso. O endpoint da API envolvido é `/api/oidc/token`, utilizando o parâmetro `grant type` definido como `authorization code`, o parâmetro `code` contendo o código de autorização e os parâmetros `client id` e `client secret` para autenticação do cliente. **Recomendações** Versões anteriores à 2.4.0 devem ser atualizadas para a versão 2.4.0 ou posterior.

**Name of the Vulnerable Software and Affected Versions** OneUptime versions 10.0.11 and prior **Description** The WebAuthn authentication implementation does not store the challenge on the server side. Instead, the challenge is returned to the client and accepted back from the client request body during verification, violating the WebAuthn specification. This allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, bypassing the second-factor authentication. The server generates a challenge using the `generateAuthenticationOptions()` function in `Common/Server/Services/UserWebAuthnService.ts`. The server reads the `expectedChallenge` directly from the request body at `/api/identity/authentication/login`. The `verifyAuthentication()` method then passes this client-provided challenge to `@simplewebauthn/server`’s `verifyAuthenticationResponse()`. This allows an attacker to replay a captured assertion by sending a request containing the victim’s email, password, and the captured challenge and credential. **Recommendations** Versions prior to 10.0.11 should be updated when a fix is available. As a temporary workaround, consider disabling WebAuthn authentication until a patch is available.