Jenkins represents almost every configurable thing — jobs (items), views, agents (nodes), and their nested properties — as Java objects. It persists those objects to disk as XML using the XStream library. Each job has a config.xml; each view and agent has its own configuration document as well. When Jenkins boots or reads configuration, XStream deserializes that XML back into live Java objects.

Java deserialization has a long, painful history. Around 2017 the Jenkins project introduced JEP-200, which replaced the platform’s permissive object stream with a ClassFilter allow-list. The intent was to ensure that only an approved set of classes could ever be deserialized, neutralising the classic “gadget chain” attacks that abuse arbitrary library classes during object reconstruction.

CVE-2026-53435 is interesting precisely because it does not rely on a classic external gadget chain. The problem here is narrower and more subtle:

–  The allowed types were too broad for this code path. The config.xml handling allowed deserialization of arbitrary types defined in Jenkins core or in installed plugins. These are legitimate Jenkins classes that the ClassFilter does not block — so JEP-200 never trips.

–  Some of those legitimate objects are web-routable. Jenkins uses the Stapler framework, which maps URLs onto Java objects and their methods reflectively. If a deserialized object becomes part of the live graph, it can become reachable over HTTP and can influence how later requests are handled.

–  The endpoint’s permission model was insufficient. The affected path did not enforce a strong enough check for what an attacker could place and then reach. The fix adds an explicit Item/Read permission check on the endpoint, in addition to restricting the deserialized types.

In short: this is CWE-502 (Deserialization of Untrusted Data) where the danger is not a memory-corruption gadget but the insertion of an attacker-controlled, web-routable object into a trusted server’s request-handling graph. The official weakness definition captures the general risk: when a product deserializes untrusted data without sufficiently verifying it, attackers can manipulate object state, instantiate unintended objects, and ultimately reach code execution or privilege escalation.

Because the controller is the trust anchor of the build pipeline, a single successful chain has cascading consequences:

–  Secret theft. Stored credentials (cloud providers, container registries, SCM tokens, SSH keys) can be read and decrypted, enabling lateral movement well beyond Jenkins.

–  Source and IP exposure. Checked-out repositories, build scripts, and environment files on the controller and workspaces become readable.

–  Build and artifact poisoning. With code execution, an attacker can alter build steps, inject backdoors into produced binaries, or tamper with deployment jobs — a classic software-supply-chain attack.

–  Lateral movement to agents and cloud. The controller orchestrates build agents and frequently holds cloud roles; compromise often extends into connected environments.

–  Destruction and disruption. Code execution permits deletion or encryption of jobs, artifacts, and history, harming availability and recovery.