CVE-2023-43497 - How Jenkins File Uploads Can Leak Secrets and Get You Hacked

If you're running Jenkins for CI/CD, this post is your wakeup call. In October 2023, a critical vulnerability—CVE-2023-43497—was disclosed, affecting Jenkins 2.423 and earlier, as well as LTS 2.414.1 and earlier. It's a simple bug with scary consequences: during file uploads, Jenkins uses unsafe temporary file handling, making your secrets and builds fair game for attackers with access to the Jenkins server.

Let’s break down what really happened, show you how it works, and help you patch your Jenkins before it’s too late.

What Is CVE-2023-43497?

In plain English: Jenkins uses a web framework called Stapler. When files get uploaded (think code, logs, configs), Stapler temporarily stores these files in your system's temp directory (often /tmp/ on Linux). Problem is, Jenkins lets the operating system decide the permissions for these temp files.

If your server’s default umask isn’t strict, these temp files could be readable or even writeable by other users on the same machine. That means a rogue user or a less trusted process can read uploaded files that may contain secrets, or overwrite them to inject malicious content.

Original References

- Jenkins Security Advisory (CVE-2023-43497)
- NVD Listing for CVE-2023-43497
- Stapler GitHub

How the Exploit Works

Imagine two users:

Alice: Jenkins admin uploading a config file

- Mallory: Malicious local user with (legit or otherwise) access to the Jenkins controller's server

Mallory has no Jenkins access, but she keeps an eye on /tmp (the place where Jenkins saves temp uploads). The second Alice uploads a file, Mallory grabs it—for example, a new Kubernetes credentials file.

Even worse, if the permissions let her write, Mallory could swap in her own file before Jenkins processes it. That could inject payloads, break your build, or steal secrets.

Here’s how an attacker might abuse this on a typical Linux server

# Watch and wait for files that Jenkins creates in /tmp
inotifywait -m /tmp -e create -e open

# Or, in another terminal, continuously list new files with open permissions
while true; do
  find /tmp -type f -perm -o=r -mmin -1 -ls
  sleep 3
done

Once a file pops up, simply cat /tmp/some-temp-file to read what Jenkins is uploading.

Here’s an idea of the vulnerable pattern (pseudocode)

// Used in Stapler file upload
File temp = File.createTempFile("upload_", null);
// No explicit permissions set! OS default applies.
inputStream.transferTo(new FileOutputStream(temp));

If your system umask allows 0644, then any user can read the file. A more secure practice would be:

File temp = Files.createTempFile("upload_", null, PosixFilePermissions.asFileAttribute(
      PosixFilePermissions.fromString("rw-------"))).toFile();

But Jenkins (and underlying Stapler) didn't do this.

Is Your Jenkins Affected?

Check your version!

Fixed: Jenkins 2.424, LTS 2.414.2 and later

(See advisory)

How Jenkins Fixed It

Starting with Jenkins 2.424 and LTS 2.414.2, any temporary files created for file uploads are now stored with strict permissions (read/write by Jenkins only).
You can see the fix PR here.

Upgrade Jenkins: Immediately update to 2.424+ or LTS 2.414.2+.

2. Audit your umask: Set umask 0077 for Jenkins service, to force restrictive default file permissions.
3. Follow the Principle of Least Privilege: Don’t allow other users or automation to share the server running Jenkins.

Temporary mitigation:

If you can't upgrade immediately, set a strict umask in your Jenkins startup script

# Place near the top of /etc/default/jenkins or similar
umask 0077

Conclusion

CVE-2023-43497 is another case where ignoring the boring details—like file upload permissions—can lead to a major breach. If you manage Jenkins, securing file uploads isn’t optional. Patch, audit, and isolate!


Further Reading:
- Jenkins Security Team Blog
- Secure Jenkins Installation Guide

---
Stay safe, keep building! 🚀

Timeline

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