CVE-2017-1000353 is a remote code execution vulnerability in Jenkins Jenkins. CISA added it to the Known Exploited Vulnerabilities catalogue on 2 October 2025, which means attackers have used it in real attacks. Jenkins contains a remote code execution vulnerability. Organisations running the affected product should apply the vendor fix or mitigation as a priority.
What makes this Jenkins vulnerability dangerous
CVE-2017-1000353 matters because remote code execution turns a software flaw into direct control of the Jenkins instance. In a CI/CD system, that can mean executing commands with the same privileges as the service, plugin, or automation context that Jenkins already trusts.
The danger is not just that the application crashes or leaks data. RCE can let an attacker change build logic, access build artifacts, tamper with release pipelines, or use the server as a pivot into wider infrastructure.
How organisations assess exposure
Exposure begins with asset inventory, because the first question is whether any Jenkins deployment is still present and reachable. Teams should confirm internet exposure, note whether the service is segmented, and compare their estate against vendor advisory and CISA KEV guidance rather than relying on memory or stale CMDB data.
For a vulnerability of this kind, the practical exposure check is simple: identify every Jenkins instance, determine whether it is externally reachable, and verify whether the vendor’s remediation advice has been applied. The NIST National Vulnerability Database and the CVE Program are the canonical references for record-level tracking, while the vendor advisory remains the source of truth for fix details.
Remediation and compensating controls
When a vulnerability can lead to execution, remediation should be treated as priority work, not backlog hygiene. If patching cannot happen immediately, reduce reachability, restrict administrative access, and remove unnecessary exposure paths into the Jenkins interface and any downstream systems it can control.
Compensating controls matter most when the server is exposed to untrusted networks or linked to high-value automation credentials. Hardening and isolation do not eliminate the flaw, but they can reduce the chance that a successful exploit becomes full environment compromise.
For vulnerability handling discipline, Vulnerability Management Guide is the most relevant internal reference for prioritisation, verification, and remediation tracking, and it aligns well with how KEV-listed issues should be handled in practice.
Detection, compromise review, and identity impact
After remediation, organisations should review whether the instance was already abused before the fix. That means looking for unexpected job changes, new admin actions, altered pipeline steps, suspicious shell activity, and signs that build credentials or tokens were touched during exploitation.
The identity impact can be material when Jenkins stores or can reach API keys, service accounts, SSH material, or deployment credentials. If exploitation is suspected, rotate the secrets the server could access, review privileged sessions created through Jenkins, and treat the CI/CD trust boundary as potentially contaminated until the review is complete.
The Homebrew GitHub token exposure 2018 example shows how a Jenkins-adjacent secret exposure can quickly turn into repository-level access, and the broader State of NHI & AI Agent Breach Report 2026 provides wider breach patterns around leaked keys, stolen tokens, and compromised service accounts.
Risk and Threat Considerations
Remote code execution is especially dangerous in Jenkins because the product often sits at the centre of software delivery, credentials handling, and privileged automation. A successful exploit can create both immediate system compromise and downstream trust abuse across build, deploy, and release workflows.
Failure mechanism: An attacker gains code execution in the Jenkins context, then abuses that position to run commands, alter pipelines, or harvest reachable credentials and tokens.
Impact: The compromise can spread beyond Jenkins into source control, artifact signing, deployment targets, and any environment that trusts the automation server.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | This CVE is a software flaw requiring prioritised remediation and verification. |
| AC-6 — Least Privilege | RCE impact depends on the privileges Jenkins can exercise after compromise. | |
| Recommendation — Track the Jenkins flaw to closure and confirm remediation on every exposed instance. Reduce the privileges available to the Jenkins service and its reachable credentials. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Exploitability and KEV status make this a vulnerability-management priority. |
| Recommendation — Prioritise and verify remediation for every Jenkins deployment in scope. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management Plan | This flaw requires an organised process for triage, patching and verification. |
| Recommendation — Apply a vulnerability-management process that accelerates KEV-listed remediation. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Remote code execution against Jenkins fits exploitation of an exposed application. |
| Recommendation — Map exposed Jenkins instances to T1190 and hunt for pre-patch exploitation. | ||
Practitioner Guidance
Why practitioners should care: Jenkins is often treated as operational plumbing, but a remotely exploitable Jenkins instance can become a high-value control point for software integrity and infrastructure access. Prioritise it accordingly in remediation queues and change windows.
What to watch for: Look for unusual job edits, unexpected plugin or configuration changes, new build steps, unexplained outbound connections, and secret-access patterns that do not match normal delivery activity. Those signals can indicate that exploitation occurred before the vulnerability was fixed.
Practitioner takeaway: If Jenkins was reachable by untrusted users or networks, assume the automation trust chain may need review, not just the host itself.
Related resources from NHI Mgmt Group
- CVE-2017-15944 (Palo Alto Networks PAN-OS Remote Code Execution)
- How should teams respond when Apache HTTP Server has a remote code execution CVE?
- What is the difference between a CVE that enables remote code execution and one that enables privilege escalation?
- CVE-2021-1647 (Microsoft Defender Remote Code Execution)