CVE-2023-40339 - How Jenkins Config File Provider Plugin Leaks Plaintext Credentials in Build Logs

Date Discovered: August 16, 2023  
Affected Plugin: Jenkins Config File Provider Plugin  
Impacted Versions: 952.va_544a_6234b_46 and earlier

TL;DR

A serious flaw (CVE-2023-40339) in the Jenkins Config File Provider Plugin causes sensitive credentials embedded in configuration files to be printed in clear text to Jenkins build logs. This means any user with read access to the logs may easily recover secrets like passwords, tokens, or API keys—an easy recipe for a security nightmare.

What’s the problem?

Many Jenkins users rely on the Config File Provider Plugin to inject sensitive files (like ~/.npmrc, .env, or settings.xml) into builds, often with credentials in them. This plugin is supposed to keep any secrets in those files under wraps by *masking* them in logs—that is, replacing them with <b></b>*.

But with versions up to 952.va_544a_6234b_46, this doesn’t happen. If your build runs a command that prints the contents of your secret-infused config file, everyone can read the credentials straight from the log!

Suppose you use the plugin to provide a config file with embedded credentials

# .npmrc
//registry.npmjs.org/:_authToken=SECRET_NPM_TOKEN

If your Jenkins pipeline accidentally or intentionally runs

sh 'cat $CONFIG_FILE'

The output in your build log will look like

[Pipeline] sh
+ cat /tmp/config-file-provided-by-plugin
//registry.npmjs.org/:_authToken=SECRET_NPM_TOKEN

Now, anyone with log access can steal your npm token.

Review logs for credentials.

Search logs using keywords like password, token, api_key, or just circular patterns like = or :.  

Any Jenkins or team member with log access can see credentials.

- If logs are sent to external systems (e.g., Splunk, S3, log aggregators), even more people (or attackers) might see them.

Is there a patch or workaround?

Yes—Upgrade!  
Any version after 952.va_544a_6234b_46 contains the fix according to the Jenkins Security Advisory.

Restrict access to build logs wherever possible.

- Double-check that you are *not* printing configuration files or lines containing secrets in your build steps.
- Use Jenkins credentials binding for sensitive data instead of embedding secrets in files if at all possible.

Careful: Historical log exposure

Upgrading fixes future exposures, but past build logs will still contain any printed credentials.

Audit past logs for leaked secrets.

- Rotate any tokens/keys/passwords you find exposed.

References

- Jenkins Security Advisory for CVE-2023-40339
- NVD Entry
- Config File Provider Plugin GitHub
- List of Jenkins Security Vulnerabilities

Summary

If you use Jenkins Config File Provider Plugin 952.va_544a_6234b_46 or earlier, credentials in your config files could be in your logs—right now. Upgrade immediately, scrub your historical logs, and rotate any affected secrets. Jenkins plugins are powerful, but with great power comes the need for careful patching and review.

If you must print sensitive files for debugging, at least mask secrets yourself

def secret = "SECRET_NPM_TOKEN"
def masked = fileContents.replaceAll(secret, "")
println masked

Better yet—never print secrets at all.

*Written exclusively for this request by an AI security researcher. Not to be copied without proper attribution. Always check vendor advisories for the latest on security vulnerabilities.*

Timeline

Published on: 08/16/2023 15:15:00 UTC
Last modified on: 08/22/2023 18:55:00 UTC