CVE-2026-117618 in Jenkins
Summary
by MITRE • 10/28/2026
In Jenkins 2.587 and earlier, LTS 2.580.1 and earlier, the HTTP endpoint for creating the first user account does not check whether the setup wizard has been completed, resulting in a race condition that allows unauthenticated attackers to create an administrator account while the initial user account is being replaced.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified in Jenkins versions 2.587 and earlier, as well as LTS version 2.580.1 and earlier, represents a critical security flaw rooted in improper synchronization of administrative setup procedures. This issue specifically affects the HTTP endpoint responsible for creating the initial administrator account during the first-time installation wizard process. The core technical deficiency lies in the absence of state verification within this endpoint. When Jenkins is installed for the first time, it enters an initialization phase where a setup wizard guides the user through configuring security settings and defining the primary administrative credentials. During this window, if the system detects that no administrator exists or if the existing one is being replaced, it exposes an API endpoint to accept new account creation requests without verifying whether the initial configuration process has officially concluded and locked down access controls.
This lack of state validation creates a race condition that can be exploited by unauthenticated attackers operating within the same network segment as the Jenkins instance. By rapidly sending multiple concurrent HTTP POST requests to the user setup endpoint, an attacker can intercept the brief interval between the initiation of the legitimate administrator creation process and its completion. If the timing is precise enough, one of these malicious requests may succeed in creating a new account with administrative privileges before the system finalizes the original setup or enforces subsequent security restrictions. This effectively bypasses authentication mechanisms because the endpoint does not check if the instance has transitioned from an unsecured initialization state to a secured operational state where such actions should be restricted to authenticated users only.
The operational impact of this vulnerability is severe, as it grants full administrative control over the Jenkins server to any attacker who can reach the service network-wise and execute the race condition successfully. Once an administrator account is created by the attacker, they gain unrestricted access to all jobs, configurations, plugins, and potentially sensitive build artifacts stored on the system. This level of compromise allows for further exploitation vectors such as injecting malicious code into build pipelines, exfiltrating source code or credentials managed within Jenkins secrets, and using the compromised server as a pivot point for lateral movement within the internal network. The attacker can also disable security plugins or alter global configurations to maintain persistent access, turning the CI/CD infrastructure into an active tool for further cyberattacks against the organization.
From a classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with inadequate synchronization, leading to race conditions. It also relates to CWE-284, improper access control, as the system fails to enforce appropriate restrictions on who can perform administrative actions during specific lifecycle phases of the application. In terms of MITRE ATT&CK framework mapping, this exploit technique corresponds to Initial Access via Valid Accounts or potentially Privilege Escalation if the attacker leverages the newly created account to escalate privileges further within the host operating system through Jenkins agent configurations. The attack vector is classified as Network-based with low complexity but requires specific timing conditions, making it a high-risk issue for any publicly accessible or poorly segmented Jenkins installations.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The primary and most effective solution is to upgrade the Jenkins instance to version 2.588 or later, where this race condition has been addressed by implementing proper state checks within the user creation endpoint. Administrators should ensure that automatic updates are enabled for LTS releases to stay protected against known vulnerabilities. In environments where immediate patching is not feasible due to operational constraints, temporary mitigations include restricting network access to the Jenkins management interface using firewall rules or reverse proxy configurations that limit exposure only to trusted IP addresses during the initial setup period. Additionally, enabling security plugins such as Matrix Authorization Strategy immediately after installation can help enforce stricter access controls, although this does not fully mitigate the specific race condition present in older versions before the fix is applied. Regular auditing of user accounts and monitoring for unusual spikes in authentication or account creation requests can also aid in detecting potential exploitation attempts.