Dorakemon

**Name of the Vulnerable Software and Affected Versions** Vaultwarden versions prior to 1.35.5 **Description** The WebAuthn authentication flow in the `validate webauthn login()` function updates persistent credential metadata, specifically the `backup eligible` and `backup state` flags, using unverified `authenticatorData` before signature validation occurs. An attacker possessing a user's password can permanently modify these stored backup flags even without a valid WebAuthn signature, as database updates are not rolled back upon signature verification failure. This leads to a persistent denial of service for WebAuthn two-factor authentication for the affected credentials. **Recommendations** Update to version 1.35.5.

**Name of the Vulnerable Software and Affected Versions** web-auth/webauthn-lib versions prior to 5.2.4 **Description** The software’s origin validation process, when using the `allowed origins` configuration, reduces URL-like values to their host component, accepting matches based solely on the host. This prevents the implementation of exact origin policies, as scheme and port differences are ignored. Specifically, the `CheckAllowedOrigins` component uses `parse url()` to extract the host from both the configured allowed origins and the incoming `clientDataJSON.origin`. This reduction allows requests with differing schemes or ports to bypass the intended origin validation. This issue affects deployments utilizing the `allowed origins` setting and bypasses the exact-origin check required by WebAuthn standards. The vulnerable component is `CheckAllowedOrigins.php`. The vulnerable parameter is `clientDataJSON.origin`. **Recommendations** Upgrade to version 5.2.4 or later to resolve this issue.

**Name of the Vulnerable Software and Affected Versions** Pocket ID versions prior to 2.4.0 **Description** Pocket ID is an OIDC provider susceptible to cross-client code exchange and expired code reuse. The OIDC token endpoint incorrectly validates authorization codes, only rejecting them when both the client ID is incorrect and the code is expired. This flaw allows an attacker to exchange authorization codes issued for one client with another client's credentials, potentially obtaining tokens for users who have not authorized the malicious client. Expired authorization codes can also be reused until a cleanup process runs. The issue resides in the `backend/internal/service/oidc service.go` file, specifically at line 407, where a logical `AND` (`&&`) should be a logical `OR` (`||`) in the authorization code validation logic. The vulnerable code is: `if authorizationCodeMetaData.ClientID != input.ClientID && authorizationCodeMetaData.ExpiresAt.ToTime().Before(time.Now())`. An attacker can exploit this by using a valid authorization code intended for one client with the client ID of another client to obtain access tokens. The API endpoint involved is `/api/oidc/token`, utilizing the `grant type` parameter set to `authorization code`, the `code` parameter containing the authorization code, and the `client id` and `client secret` parameters for client authentication. **Recommendations** Versions prior to 2.4.0 should be updated to version 2.4.0 or later.

**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.