CVE-2026-119552 in Uptime Kuma
Summary
by MITRE • 10/30/2026
Uptime Kuma through 2.5.8 contains a race condition in the Socket.IO first-run setup handler that allows unauthenticated attackers to create an additional administrator account. Attackers can send concurrent setup requests during the bcrypt hashing window to bypass the empty user table check, then modify monitors, API keys, and enable disableAuth.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/30/2026
Uptime Kuma is a popular open-source monitoring tool designed for tracking server uptime and service availability via HTTP, TCP, Ping, and other protocols. The software utilizes Socket.IO for real-time communication between the client interface and the backend server, facilitating immediate updates on status changes and configuration modifications. In versions through 2.5.8, a critical security flaw exists within the initial setup handler responsible for creating the first administrative user account during the application's initialization phase. This vulnerability stems from a race condition that exploits the asynchronous nature of password hashing operations combined with insufficient synchronization mechanisms in the database write process.
The technical root cause lies in how the system handles concurrent requests when no users exist in the database, which is the expected state for a fresh installation or after a reset. The application checks if the user table is empty to determine whether an incoming request should be treated as the privileged first-run setup. However, this check and the subsequent creation of the admin account are not atomic operations protected by proper locking mechanisms. When multiple requests arrive simultaneously during the window required for bcrypt password hashing, both requests can pass the initial emptiness check before either has completed writing to the database. Consequently, the system processes both requests as valid first-run setups, resulting in the creation of two distinct administrator accounts rather than just one.
This race condition allows unauthenticated attackers who have network access to the Uptime Kuma instance to escalate their privileges from zero to full administrative control without knowing any existing credentials. By sending a high volume of concurrent setup requests, an attacker can reliably trigger this flaw and establish a secondary admin account. Once established, this unauthorized administrator possesses the same capabilities as the legitimate first user, including the ability to modify monitoring configurations, manage API keys used for integrations with external services like Slack or Telegram, and alter authentication settings.
The operational impact of this vulnerability is severe because it compromises the integrity and confidentiality of the entire monitoring infrastructure. An attacker gaining administrative access can manipulate monitors to hide outages from legitimate administrators, effectively blinding them to service disruptions. Furthermore, the ability to modify API keys allows attackers to exfiltrate sensitive data or integrate malicious endpoints into their notification pipelines for further exploitation. The most critical aspect is the capability to disable authentication entirely by toggling the disableAuth setting. This action removes all login requirements from the application, granting unrestricted access to any user on the network and exposing internal monitoring data that may contain insights into the organization's infrastructure topology and operational status.
From a classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization leading to race conditions. It also relates to CWE-798, as it involves obtaining default or hard-coded credentials through logical flaws rather than cryptographic breaks. In the context of the MITRE ATT&CK framework, this exploit maps to T1078 Valid Accounts and specifically T1078.003 Default Accounts, where attackers leverage improperly configured initial setup procedures to gain persistent access. The attack vector is classified as Network-based with Low complexity but requires network proximity or internet exposure depending on the deployment configuration.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. For organizations currently running vulnerable versions of Uptime Kuma, the primary recommendation is to upgrade immediately to version 2.5.9 or later where this race condition has been patched by implementing proper database locking or transactional integrity checks during user creation. If upgrading is not immediately feasible, administrators should ensure that the application is not exposed directly to untrusted networks and restrict access via firewall rules to only trusted IP addresses until a patch can be applied. Additionally, enabling multi-factor authentication where supported adds an extra layer of security against credential-based attacks, although it does not fully mitigate this specific race condition if the attacker gains admin rights before MFA enforcement is configured correctly.
Long-term mitigation involves adopting secure coding practices that prioritize atomicity in critical state changes. Developers should ensure that checks for system state and subsequent modifications are performed within a single database transaction or protected by explicit locks to prevent interleaving of operations from different threads. Regular security audits focusing on concurrency handling in authentication flows can help identify similar vulnerabilities before they reach production environments. Monitoring logs for unusual spikes in setup requests during initialization periods may also provide early detection indicators for this type of attack, allowing administrators to respond proactively to potential exploitation attempts.