Jenkins is under attack. CVE-2026-53435, a critical unsafe-deserialization flaw in how the automation server processes config.xml submissions, is being exploited in the wild as of today — five days after its June 10 disclosure and on the heels of a public proof-of-concept. If you run an internet-facing Jenkins controller, treat this as an active incident, not a patch-next-sprint item.

What happened

On June 10 the Jenkins project disclosed CVE-2026-53435, an insecure deserialization vulnerability in the controller’s handling of config.xml job-configuration submissions. By submitting a crafted serialized payload, an attacker can manipulate HTTP request handling and hijack the server’s execution flow, leading to remote code execution on the controller. The flaw carries a CVSS score of 9.0 (Critical) and affects Jenkins weekly releases 2.567 and earlier and Jenkins LTS 2.555.2 and earlier — a very large slice of the installed base for one of the most widely deployed CI/CD servers in production.

A public PoC dropped shortly after disclosure, and exploitation followed almost immediately. Deception/honeypot telemetry recorded probing within hours, and threat intel shared by DefusedCyber confirmed live exploitation attempts by June 15. The same advisory also fixes two lower-severity open-redirect issues, CVE-2026-53436 and CVE-2026-53437, but neither approaches the severity of the deserialization bug.

Technical details

The vulnerability lives in how Jenkins deserializes objects from config.xml. Jenkins exposes per-job configuration at /job/<name>/config.xml, and submitting unsafe serialized data there triggers deserialization without adequate validation. Successful exploitation yields more than code execution: reported impact includes arbitrary RCE on the host, user impersonation, the ability to issue unauthorized HTTP requests, access to the Jenkins Script Console, and reads of sensitive files including stored credentials.

Observed attacks have been opportunistic. One documented campaign originated from 194.247.182.44 (AS57043, HOSTKEY B.V., a Netherlands hosting provider frequently abused by threat actors), hit port 443 to blend with normal HTTPS, and paired the exploit with a path-traversal attempt to read /etc/passwd using default admin:admin credentials. Attackers are scanning for exposed endpoints, attempting to upload or modify configuration, and then executing system-level commands to drop backdoors, cryptominers, or RATs.

Impact assessment

Jenkins sits at the center of the software build pipeline, which is exactly what makes a controller compromise so damaging. An attacker with code execution on the controller can tamper with build processes, inject malicious code into the artifacts you ship, and harvest the credentials, signing keys, and cloud tokens that CI systems hoard. In other words, a single exploited Jenkins box is a launch point for a downstream supply-chain attack against everything that server builds. Internet-exposed instances and those with weak or default authentication are the immediate casualties, but any reachable unpatched controller is in scope.

Mitigation — what to do right now

Patch immediately. The fixed versions are:

BranchAffectedFixed
Jenkins weekly2.567 and earlier2.568
Jenkins LTS2.555.2 and earlier2.555.3

If you cannot patch this minute: pull Jenkins off the public internet and put it behind a VPN or allowlist; restrict access to the /job/*/config.xml endpoint; disable anonymous access; and enforce strong, non-default credentials (the observed attacks lean on admin:admin).

Then assume probing has already reached you and hunt. IOCs to grep for include unusual HTTP POST requests to config.xml endpoints, anomalous modifications to job configuration files, and unexpected outbound connections from Jenkins hosts. Given the platform’s role in the build chain, a compromise assessment should also cover artifact integrity and the credentials stored on or reachable from the controller — rotate anything that box could touch.

References