CVE-2026-28787 is a high severity (CVSS 8.2) flaw in OneUptime version 10.0.11 and earlier. The server takes the WebAuthn challenge from the client instead of storing its own, so a captured assertion can be replayed forever, defeating the second factor. No patched version is listed.
What's affected
The GitHub advisory lists the npm package @oneuptime/common at 10.0.11 and earlier, with no first patched version. The NVD text agrees: no known patches are available.
Check the OneUptime repository for a later release before you assume the issue is open or closed.
How to check if you're exposed
Check the version of the package in your deployment:
npm ls @oneuptime/common
For Docker or Helm installs, check the image tag of the OneUptime release you run. Then look in the project's advisories and releases for a fix.
What to do now
- Check the OneUptime releases and advisory for a fixed version, and upgrade when one is available.
- Do not rely on WebAuthn alone for administrator accounts until fixed. Add network restrictions such as a VPN or IP allowlist for the login page.
- Reduce the chance an assertion is captured: review logging so request bodies and credentials are not written to logs, and keep dependencies free of cross-site scripting issues.
- Review authentication logs for repeated or unusual second-factor completions.
Why it matters
The record lists CWE-287 (improper authentication) and CWE-294 (authentication bypass by capture-replay). WebAuthn works because each login includes a fresh random challenge that the server remembers and checks. If the server accepts whatever challenge the client sends back, a recorded response is valid again and again.
The advisory notes that an attacker first needs a valid assertion, for example through cross-site scripting, a man-in-the-middle position or log exposure. That is why the attack complexity is high. Even so, it defeats the purpose of a second factor, which is to hold up when something else leaks.
The record does not mark this CVE as exploited in the wild.
Quick check
What should the server do instead?
Generate the challenge, store it server side for that login attempt, compare against the stored value when verifying, and discard it after one use.
Sources
Last reviewed: 19 October 2026.
