Jenkins attacks expose CI pipeline risk

Attackers are probing vulnerable Jenkins servers after disclosure of a high-severity deserialisation flaw that can let a low-privileged user impersonate others, reach sensitive controller files and, in some cases, execute code through the Script Console.

The bug, tracked as CVE-2026-53435, affects Jenkins 2.567 and earlier and Jenkins LTS 2.555.2 and earlier. Fixed versions, Jenkins 2.568 and LTS 2.555.3, were issued on 10 June as part of a wider security update covering several core vulnerabilities. The flaw has been scored 8.8 on the CVSS 3.1 scale, placing it in the high-severity range.

The issue centres on how Jenkins processes attacker-controlled config. xml submissions. Jenkins uses XStream serialisation to load and save configuration and build data, guarded by a custom class filter intended to block unsafe deserialisation. The weakness allows an attacker to make Jenkins deserialise types from Jenkins core or installed plugins in a context that can later be reached through the Stapler web framework used for HTTP request handling.

That distinction matters for defenders. This is not a simple unauthenticated internet worm scenario based on the public advisory. The attacker needs Overall/Read permission and must either have a user account or hold permissions that allow a POST to config. xml, such as Item/Configure, View/Configure or Agent/Configure. Many development environments, however, grant broad read or configuration rights to engineering teams, contractors, service accounts and automation tools, widening the practical exposure.

Threat-intelligence accounts and security monitoring reports began flagging exploitation attempts against exposed Jenkins instances around 15 June. Honeypot activity described by researchers showed automated probing for Jenkins endpoints and attempts to plant malicious configuration data. Public proof-of-concept code also appeared after the advisory, accelerating the window in which defenders had to identify and patch affected controllers.

Successful exploitation could have consequences beyond a single build server. Jenkins often holds credentials, deployment keys, source-code access tokens and links to container registries, cloud environments and production release systems. A compromised controller can therefore become a staging point for supply-chain attacks, secret theft or tampering with build and deployment workflows, particularly in organisations that rely on automated release gates and shared administrative accounts.

The most serious path identified in the advisory involves user impersonation. Once an attacker can send HTTP requests as another user, the Script Console becomes a critical risk if the impersonated identity has administrative-level access. Jenkins’ Script Console can run Groovy code on the controller, making it a powerful administrative tool and a dangerous post-exploitation target.

A second impact is file access on the controller. Research examining the flaw showed exploit chains aimed first at predictable Unix files such as /etc/passwd, then at SSH keys, Jenkins credentials files and other secrets stored under the Jenkins home directory. Even when code execution is not achieved, file disclosure can give attackers enough material to move into source repositories, cloud accounts or internal services.

The June 10 update also addressed open-redirect flaws, a queue-item permission issue, limited user-profile information disclosure, stored cross-site scripting affecting node offline descriptions and a separate weakness involving plaintext secrets in configuration submissions. Although CVE-2026-53435 drew the strongest attention, defenders are being urged to treat the full advisory as a core platform update rather than a single-bug patch.

Security teams running Jenkins should prioritise version checks across all controllers, including development, staging and legacy build systems. Internet-facing instances carry the highest risk, but internal Jenkins servers are also attractive because attackers who already have a foothold often search for CI/CD platforms to obtain credentials and expand access.

Immediate containment steps include upgrading to Jenkins 2.568 or LTS 2.555.3, restricting access to controllers through VPNs or allow-listed networks, reviewing accounts with Overall/Read and configuration rights, and auditing Script Console use. Administrators should also review view, item and agent configuration changes made since 10 June, especially unexpected config. xml updates, newly created views, unusual HTTP POST activity and requests for sensitive files under the Jenkins home path.