Uptime Kuma EUVD-2026-113817

The target Uptime Kuma instance (≤2.5.8) must be in its first-run/initial-setup state with an empty user table - deployed but not yet configured with a legitimate administrator. The attacker must reach the Socket.IO setup handler and issue multiple concurrent setup requests timed to the brief bcrypt password-hashing window so the empty-user-table check is evaluated before the first account is committed (the TOCTOU race). No authentication or user interaction is required (PR:N/UI:N), but exploitation is strongly limited by this narrow first-run window and the timing-dependent race (AC:H/AT:P): once a legitimate admin has been created the vulnerable path is closed, so long-running or already-configured deployments are not exploitable.

Signals point to a genuine but bounded risk rather than a drop-everything emergency. The vector is favourable to an attacker where it counts for reach - AV:N (network) and PR:N/UI:N (no authentication, no user interaction) - which is why an unauthenticated admin-account creation is scored as high as 6.3. However, AC:H and AT:P pull the practical likelihood down sharply: this is a timing-dependent TOCTOU race (CWE-367) that only works inside the bcrypt-hashing window of the first-run setup handler, and only against an instance still in its unconfigured, empty-user-table state. The vuln.today decision label is 'this_month', consistent with moderate urgency, not 'act_now' or 'emergency'. There is no CISA KEV listing, so there is no confirmation of active exploitation, and no EPSS score was supplied, so widespread-exploitation probability cannot be quantified from the input - this gap should be noted rather than assumed low. A detailed third-party technical write-up of the race (abraxaslabs) and a VulnCheck advisory exist and describe the mechanism precisely, but the input does not mark a working proof-of-concept as confirmed. Net: a real, vendor/researcher-corroborated authentication-bypass flaw whose impact (secondary admin, monitor/API-key tampering, disableAuth) is serious for a monitoring app, but whose exploitation window is narrow enough that it is best treated as a planned-remediation (this-month) item rather than an actively-exploited priority.

An attacker who can reach a freshly deployed Uptime Kuma instance (≤2.5.8) that has not yet completed first-run setup sends many concurrent Socket.IO setup requests, racing within the bcrypt password-hashing window to slip a second administrator registration past the empty-user-table check. With that admin account the attacker can alter monitors, read or rotate API keys, and toggle disableAuth to weaken the whole instance. A public technical write-up of the TOCTOU (abraxaslabs) and a VulnCheck advisory describe the technique, but the input does not confirm working exploit code; the network-reachable, no-auth vector is offset by high attack complexity and a strict timing requirement.