CVE-2023-40342 - Stored XSS Vulnerability in Jenkins Flaky Test Handler Plugin – Simple Explanation, Exploit Example & Fix

Jenkins is a widely-used automation server popular in CI/CD (Continuous Integration/Continuous Delivery) pipelines. One of its plugins, the Flaky Test Handler, helps teams identify flakey (inconsistent) tests by visualizing flaky results. But in versions 1.2.2 and earlier, there was an important and dangerous vulnerability: CVE-2023-40342.

This post breaks down what the vulnerability is, how bad guys could exploit it, gives you a simple code example, and tells you how to protect your Jenkins setup.

What is CVE-2023-40342?

In short: The Jenkins Flaky Test Handler plugin (version 1.2.2 and before) does not properly escape JUnit test content shown in the Jenkins UI. This means attackers can put malicious JavaScript or HTML in JUnit reports, and when Jenkins shows those reports, the code runs in your browser. Boom: stored Cross-Site Scripting (XSS).

Why Does It Matter?

Stored XSS is one of the most serious web vulnerabilities. If someone can put JavaScript in your Jenkins UI, they could:

Steal builds, secrets, or inject builds with malicious code

If you let anyone or any outside process push test results to Jenkins, you are at risk!

Who Can Attack?

Any attacker who has control over uploaded/flushed JUnit report XML files can inject malicious code. This could be a developer, a compromised CI process, or someone who can upload build artifacts to Jenkins.

The Vulnerable Code Behavior

With this bug, Jenkins Flaky Test Handler simply dumped whatever's inside a JUnit <failure> or <error> element onto its UI — no escaping, no filtering. So, if you wrote HTML or JavaScript in the test output, Jenkins would trust it, render it, and your browser would run it.

Suppose you have a test like this in your codebase

@Test
public void testMalicious() {
    fail("<img src='x' onerror='alert(\"Hacked by CVE-2023-40342!\")'>");
}

With the Flaky Test Handler installed (pre-1.2.3), this would produce a JUnit XML report file similar to:

<testsuite>
  <testcase classname="ExploitTest" name="testMalicious">
    <failure>
      &lt;img src='x' onerror='alert("Hacked by CVE-2023-40342!")'&gt;
    </failure>
  </testcase>
</testsuite>

But maybe your test system escapes brackets, so an attacker might try including script tags in another way, or even regenerate the JUnit XML:

<testsuite>
  <testcase classname="ExploitTest" name="testMalicious">
    <failure>
      <![CDATA[<script>alert('XSS via Jenkins!')</script>]]>
    </failure>
  </testcase>
</testsuite>

What happens?
When a Jenkins user views the flaky test results, the plugin renders the *unescaped* content. If the XML contains script tags or images with onerror, the browser executes the attacker's JavaScript!

public void testMalicious() {

fail("alert('Exploited CVE-2023-40342!')");
}

How to Fix?

Update the plugin!
-Jenkins Flaky Test Handler Plugin 1.2.3 and later fixes the bug: it escapes all output, so JavaScript/HTML can't run!

Restart Jenkins or let it reload the plugin.

Bonus:
If you’re stuck on an old version, you could try to block unsafe test content, or use a web proxy (like a Web Application Firewall) to filter XSS, but those are poor substitutes for patching!

Official Resources and References

- Jenkins Security Advisory (CVE-2023-40342)
- NVD Entry for CVE-2023-40342
- Jenkins Flaky Test Handler Plugin Page
- OWASP XSS Guide

Summary table

| Affected plugin | Flaky Test Handler |
|-------------------|-------------------|
| Affected version | <= 1.2.2 |
| Fixed version | 1.2.3 |
| Vulnerability | Stored XSS (CVE-2023-40342)|
| Exploit requires | Control over JUnit reports or build process |
| Impact | Javascript execution in Jenkins UI, session theft, UI manipulation, data loss |
| Solution | Update plugin or sanitize JUnit input |

Conclusion

CVE-2023-40342 is a textbook example of why plugins must sanitize all user input, even "trusted" XML from test automation.
If you use Jenkins for mission critical CI/CD, keep all plugins up-to-date and restrict who can submit artifacts!

Stay safe, and happy building!

*This post is based on public disclosures and enhanced for clarity and learning. For critical environments, always follow best security practices and monitor plugin vulnerabilities regularly.*

Timeline

Published on: 08/16/2023 15:15:00 UTC
Last modified on: 08/18/2023 20:05:00 UTC