If you use Jenkins for building and deploying your code, you probably rely on plugins to connect with various tools. But what if a plugin lets anyone with basic permissions walk away with all your credentials? That’s what happened with CVE-2023-40345, a major flaw uncovered in the Jenkins Delphix Plugin.

Let’s break it down: what went wrong, how it can be exploited, and what you should do.

What is CVE-2023-40345?

This security issue lies in the Jenkins Delphix Plugin versions 3..2 and earlier. The problem? The plugin didn’t properly isolate sensitive credentials. Anyone with basic “Overall/Read” permission in Jenkins could poke around and grab secrets meant only for admins or other jobs.

Why Is This Bad?

Jenkins jobs often connect to databases, clouds, and sensitive systems by storing usernames, passwords, and tokens as credentials. These secrets are supposed to be tightly controlled—you don’t want everyone to see or use them. When plugins mishandle credential access, they rip that safeguard away.

How The Exploit Works

Imagine you’re a regular Jenkins user—no admin rights. Normally, you can see some projects and maybe submit new job configs, but nothing more dangerous. If the Delphix Plugin is installed (up to version 3..2), you can take the following steps to steal credentials you shouldn’t have:

Find a Credential Lookup Field

- The plugin provides a UI field/dropdown that lets users pick which credentials a job should use.

The Bug: No Context Isolation

- The plugin fails to limit the list to only your credentials. Instead, all credentials stored globally or for certain jobs are listed!

Grab The Credentials

- With “Overall/Read” access, just view the list or the autocomplete chooser, and you’ll see all available credential IDs and even their descriptions.
- You can then reference these credentials in your own jobs, using them in builds or even dumping their actual secrets in a build log.

PoC (Proof of Concept) Exploit

Here’s a simplified code snippet showing how an attacker could enumerate and dump credentials using a Jenkins pipeline that references other people's secrets:

// Suppose you found 'delphix-credential-id' from the auth picker
pipeline {
    agent any
    stages {
        stage('Dump Credentials') {
            steps {
                withCredentials([usernamePassword(credentialsId: 'delphix-credential-id', usernameVariable: 'USER', passwordVariable: 'PASS')]) {
                    sh '''
                        echo Username: $USER
                        echo Password: $PASS
                    '''
                }
            }
        }
    }
}

Result: When this pipeline runs, the console output will print usernames and passwords—credentials you were never meant to see!

Official References & Fixes

- Jenkins Security Advisory: SECURITY-3135
- NVD CVE-2023-40345

The problem was fixed in Delphix Plugin version 3..3 (August 2023). The update sets the correct security context when listing or checking credentials so you only see or use what you’re supposed to.

Update Now: Make sure your Jenkins Delphix Plugin is at version 3..3 or later.

2. Review User Permissions: Don’t give “Overall/Read” to non-essential users if you can avoid it.
3. Audit Credential Usage: Check logs and recent jobs for any suspicious credential access around the time before your update.

Why This Matters

This flaw is a reminder that even read-only users can be dangerous if plugins are flawed. Always keep plugins updated, review Jenkins advisories regularly, and use the principle of least privilege.


Stay safe—never underestimate how small bugs in automation tools can lead to big leaks.
If you want to dive deeper, check the full Jenkins advisory here.


(This article is original content from an AI assistant. Always reference official advisories for the latest details.)

Timeline

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