Jenkins is a popular automation server, heavily used for CI/CD pipelines. One of its strengths is the extensibility through hundreds of plugins. But every plugin can introduce new risks if not thoroughly checked for vulnerabilities. In 2023, researchers discovered such an issue in the AWS CodeCommit Trigger Plugin, tracked as CVE-2023-41941.

This post goes deep into this vulnerability—how it occurs, how it can be exploited, and what you should do to protect your Jenkins setup.

Which versions?: 3..12 and earlier

- Impact?: Allows users with low-level Overall/Read permission to enumerate Jenkins AWS credential IDs
- CWE: Improper Access Control (CWE-284)
- References: Jenkins Security Advisory 2023-09-06, CVE page

What’s Wrong in Jenkins AWS CodeCommit Trigger Plugin?

By default, a Jenkins plugin should restrict sensitive information (like credential IDs) to users with appropriate permissions. In this case, the plugin provides a way for pipeline authors to connect to AWS CodeCommit and trigger builds when changes are pushed.

However, *the plugin fails to check if the user trying to view credential IDs has the right permissions.* Anyone who has basic read access (Overall/Read) on Jenkins can list IDs of AWS credentials. While this doesn’t let them see the secrets themselves, knowing the IDs is a valuable step for attackers, as it helps with further attacks like phishing, brute forcing, or social engineering.

!Jenkins Permissions Diagram

Here’s a simplified version of what went wrong

// Controller method with missing permission check:
public ListBoxModel doFillAwsCredentialsIdItems(@QueryParameter String credentialsId) {
     // BAD: No permission check (should check for Credentials or Admin permissions)
     ListBoxModel items = new ListBoxModel();
     items.add("--- Select ---", "");
     // this function will include all AWS credential IDs available in Jenkins
     for (String id : getAllAwsCredentialIds()) {
         items.add(id, id);
     }
     return items;
}

It should be something more like

public ListBoxModel doFillAwsCredentialsIdItems(@QueryParameter String credentialsId) {
    // GOOD: checks if user has appropriate permission
    if (!Jenkins.get().hasPermission(CredentialsProvider.VIEW)) {
        throw new AccessDeniedException("Not authorized to view credentials.");
    }
    ListBoxModel items = new ListBoxModel();
    // ...
}

The function doFillAwsCredentialsIdItems should enforce permissions. It doesn’t, which means any authenticated user with basic Jenkins access can get the list of AWS credential IDs.

The typical exploitation path would run like this

1. Attackers log into Jenkins with any legitimate account (with the lowest level of access needed: Overall/Read). Even non-admins or project viewers often have this.

Visit a job with AWS CodeCommit or try configuring a new job.

3. Trigger the drop-down to select AWS credentials (often by using the “Add” button or viewing configuration forms)

A proof-of-concept using cURL might look like this

curl -u lowprivuser:password \
  "https://jenkins.example.com/job/myjob/aws-codecommit-trigger/fillAwsCredentialsIdItems";

The JSON/XML response will contain a list of IDs like

{
  "values": [
    { "name": "jenkins-aws-codecommit-prod", "value": "jenkins-aws-codecommit-prod" },
    { "name": "backup-bucket-credentials", "value": "backup-bucket-credentials" }
  ]
}

No secrets are exposed immediately, but now the attacker knows which credential IDs exist, and may try to use those as phishing lure or as part of targeted attacks elsewhere in Jenkins (or AWS).

Guess or enumerate the type of cloud accounts in use

- Attempt privilege escalation, social engineering attacks ("please rotate the AWS account ‘prod-main-user’...")
- Combine information with other weaknesses, such as disclosure of job configs or weak build permissions

*Even if you think "IDs alone are harmless", in practice enumeration is a valuable stepping stone for attackers.*

- Jenkins Security Advisory: SECURITY-3219

The official Jenkins writeup, including affected plugin versions and patch information.

- CVE-2023-41941 on NVD
- Github plugin repo

How To Fix (or Mitigate)

- Upgrade the Plugin: The issue is fixed in version 3..13 and newer. Always update security plugins ASAP.
- Tighten Jenkins read access: Don’t grant Overall/Read widely; restrict to trusted users.
- Audit who can view credentials: Use the Credentials Plugin to limit who can see or use credentials, not just their IDs.
- Review job configurations: Remove unnecessary AWS credentials and restrict their use as narrowly as possible.

Final Thoughts

CVE-2023-41941 is a classic example of how even small permission oversights in CI/CD platforms can increase risk. While it doesn’t leak secrets directly, it aids attackers—*and in modern pipelines, even small mistakes can snowball fast!* Make sure your Jenkins setup is fully updated and that your plugin permissions are locked down.

Stay vigilant, keep Jenkins updated, and don’t underestimate credential enumeration bugs.

*Feel free to share this post. For more on Jenkins security, check out the official Jenkins Security Documentation, and browse other recent Security Advisories.*

Timeline

Published on: 09/06/2023 13:15:11 UTC
Last modified on: 09/11/2023 18:44:44 UTC