CVE-2017-1000353

What Is Jenkins?

Jenkins is the world's leading open-source CI/CD automation server, used by software development teams globally to build, test, and deploy code. Jenkins orchestrates the software delivery pipeline and typically runs with broad access to source code repositories, build artifacts, deployment credentials, cloud provider keys, and production infrastructure. Because Jenkins agents often have elevated permissions to deploy to production, a compromised Jenkins server provides an attacker with a privileged foothold in the software supply chain — capable of injecting malicious code into builds, accessing secrets, and pivoting to production systems.

Overview

CVE-2017-1000353 is a critical unauthenticated remote code execution vulnerability in Jenkins caused by unsafe Java deserialization in the remoting-based Jenkins CLI. The Jenkins CLI accepted serialized Java objects from unauthenticated remote clients; an attacker could send a crafted SignedObject wrapping a malicious payload that bypassed Jenkins's existing deserialization blocklist by triggering deserialization through a fresh ObjectInputStream, executing arbitrary code on the Jenkins server. Fixed in Jenkins 2.46.2 (LTS) and 2.57 (weekly) on April 26, 2017. CISA added this to the KEV catalog in October 2025, reflecting ongoing exploitation of unpatched Jenkins installations.

Affected Versions

Technical Details

Root Cause: SignedObject Deserialization Bypasses Blocklist

CVE-2017-1000353 is a deserialization vulnerability (CWE-502) in the Jenkins remoting subsystem. Jenkins provided a CLI (Command Line Interface) accessible over the Jenkins remoting protocol that accepted Java-serialized objects from connecting clients. Jenkins had implemented a class blocklist to prevent known malicious deserialization gadget chains from being used — however, the blocklist was bypassable:

Bypass mechanism:

1. An attacker connects to the Jenkins CLI endpoint (TCP/JNLP or HTTP tunneled)
2. The attacker sends a java.security.SignedObject wrapping a serialized malicious payload
3. Jenkins's blocklist check examines the outer SignedObject class and finds no match — it passes
4. Jenkins deserializes the SignedObject using a new ObjectInputStream (bypassing the blocklist context)
5. Deserializing the SignedObject triggers deserialization of the inner payload with a fresh stream that also bypasses blocklist checks
6. The inner payload contains a gadget chain (e.g., Commons Collections) that executes arbitrary system commands during deserialization
7. The commands execute as the Jenkins process user — often a service account with broad deployment access

Why this is CVSS 9.8 (Critical):

• PR:N — no authentication required; the CLI endpoint accepts connections from unauthenticated clients
• UI:N — no user interaction needed; a single network connection triggers RCE
• Full C/I/A impact — code execution as the Jenkins service account with access to all secrets and deployment capabilities

Attack Characteristics

Discovery

The vulnerability was discovered and reported to the Jenkins security team, resulting in the April 26, 2017 security advisory. The bypass mechanism using SignedObject to escape the deserialization blocklist was a known technique for circumventing blocklist-based Java deserialization defenses.

Exploitation Context

• Java deserialization epidemic: CVE-2017-1000353 is part of the broad class of Java deserialization vulnerabilities that emerged from the 2015 Apache Commons Collections gadget chain research; Jenkins was one of many Java applications that implemented blocklist-based mitigations that proved bypassable via wrapper objects like SignedObject
• High-value CI/CD target: Jenkins servers are particularly attractive targets because they aggregate secrets — AWS keys, GitHub tokens, SSH private keys, Docker registry credentials — and have deployment access to production; compromising Jenkins is often equivalent to compromising the entire software supply chain of an organization
• Long tail of unpatched deployments: The 2025 KEV addition (8 years after the 2017 patch) reflects that self-hosted Jenkins deployments frequently go unpatched for extended periods; Jenkins upgrades can require plugin compatibility testing and are often deferred, leaving known-critical vulnerabilities in production
• CISA KEV (2025): Added October 2025 confirming active exploitation of unpatched Jenkins instances by threat actors targeting development infrastructure

Remediation

1. Upgrade Jenkins — upgrade to Jenkins 2.46.2 LTS or 2.57 weekly (or any later version). This is the definitive fix and should be prioritized immediately given the CRITICAL severity and unauthenticated exploitation.

2. Disable the remoting-based CLI — if upgrading is not immediately possible, disable the remoting-based CLI in Jenkins:

   • Jenkins → Manage Jenkins → Configure Global Security → uncheck "Enable CLI over Remoting"
   • This removes the vulnerable endpoint without upgrading Jenkins

3. Restrict network access to Jenkins — place Jenkins behind a VPN or internal network boundary; ensure the Jenkins port (default 8080) and JNLP agent port (default 50000) are not directly exposed to the internet.

4. Rotate all credentials stored in Jenkins — after confirming exploitation or as a precaution on systems that were exposed, rotate all secrets stored in Jenkins credential stores (API keys, SSH keys, cloud provider credentials).

5. Audit Jenkins agent permissions — apply least privilege to the Jenkins service account; agents should only have permissions to the systems they need to deploy to, limiting lateral movement if Jenkins is compromised.

6. Enable Jenkins authentication and authorization — ensure Jenkins requires authentication for all access (not configured as "Anyone can do anything"), reducing the attacker's available capabilities even if the CLI is accessible.