Skip to content
KitploitKITPLOIT
ToolsBlog
Submit
ToolsBlog
Submit

Hacking, PenTest, and Cybersecurity Tools for Your Security Arsenal!

Kitploit is a directory of hacking, cybersecurity, and pentesting tools. Discover the latest project updates to find vulnerabilities, analyze systems, automate testing, and strengthen your security.

··Feeds·Contact·Privacy·© 2026 Kitploit

Tool Directory

Categories

View all categories
Loading categories
SECURITY-218 | Kitploit
Tools/GitHubGitHub/jenkinsci-cert/security-218
Defensive ToolsVulnerability AnalysisScripting & AutomationConfiguration AuditingIncident ResponseArchived
GitHubjenkinsci-cert/security-218

SECURITY-218

View Repository
2059 years agoReviewed by Kitploit

Most Popular

View all →

Discover the most used tools by our community.

Explore all tools

Browse our collection of tools

View all tools →
Share
Website

This mitigation is obsolete as of Jenkins 2.54 and Jenkins LTS 2.46.2. If you have installed a 2.54+/LTS 2.46.2+ version of Jenkins anew, the Remoting-based CLI is disabled out of the box. If you installed an older version of Jenkins and upgraded to 2.54+ or LTS 2.46.2+, you will be prompted by an administrative monitor to go to Configure Global Security and disable the Remoting-based CLI. In either case, the following workarounds are unnecessary.

Or, if you are using Jenkins 2.32+ or 2.19.3+ (as mentioned in the security advisory of 2016 Nov 16), but older than 2.54, you may simply use the startup switch: -Djenkins.CLI.disabled=true

Mitigation for unauthenticated remote code execution via CLI

NOTE: This script was originally published in November 2015 to fix the SECURITY-218 zero-day vulnerability. It can also be applied as a workaround for the SECURITY-360 zero-day vulnerability published in November 2016.

This script can be used to shut down CLI subsystem of Jenkins to protect Jenkins from a known vulnerability.

When run from the Groovy script console (/script), this shuts down CLI subsystem of a running Jenkins without needing a restart.

When placed in $JENKINS_HOME/init.groovy.d/cli-shutdown.groovy it makes sure the protection stays in place after master restart.

To see if the mitigation is successfully applied, try running java -jar cli.jar -s $JENKINS_URL with cli.jar and make sure you get EOFException like the following:

root@kitploit:~
java.io.EOFException
	at java.io.DataInputStream.readFully(DataInputStream.java:197)
	at java.io.DataInputStream.readUTF(DataInputStream.java:609)
	at java.io.DataInputStream.readUTF(DataInputStream.java:564)
	at hudson.cli.CLI.connectViaCliPort(CLI.java:232)
	at hudson.cli.CLI.<init>(CLI.java:128)
	at hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
	at hudson.cli.CLI._main(CLI.java:479)
	at hudson.cli.CLI.main(CLI.java:390)
	Suppressed: java.io.IOException: https://ci.jenkins-ci.org/cli doesn't look like Jenkins
		at hudson.cli.FullDuplexHttpStream.<init>(FullDuplexHttpStream.java:81)
		at hudson.cli.CLI.connectViaHttp(CLI.java:158)
		at hudson.cli.CLI.<init>(CLI.java:132)
		... 3 more

FAQ

How do I interpret the output from this script?

It doesn't mean anything useful. So please ignore the output. See above for how to verify that the mitigation took place. To be safe, please also perform the verification again if you restart Jenkins.

Does this affect the REST API?

No.

What vulnerability is this a fix for?

Originally this was developed in November 2015 as a workaround for the SECURITY-218 zero-day remote code execution vulnerability. Releases with a fix were published on November 11, 2015.

On November 11, 2016, another zero-day remote code execution vulnerability (SECURITY-360) used a similar technique, and this workaround was effective here as well.

Download Tool