CVE-2025-24397 - How an Incorrect Permission Check in Jenkins GitLab Plugin Leaks Credential IDs

On March 18, 2025, CVE-2025-24397 was published, spotlighting a serious security issue in the widely used Jenkins GitLab Plugin. This vulnerability affects versions 1.9.6 and earlier. It's a classic case of an incorrect permission check, allowing attackers with only global Item/Configure permission to enumerate sensitive credential IDs—even if they *shouldn’t* have permission to see or configure a specific job.

Let’s break down what’s going on, how to exploit the flaw, review example code, and see what you can do to protect your Jenkins pipelines.

What is CVE-2025-24397?

CVE-2025-24397 is a vulnerability in how the Jenkins GitLab Plugin checks user permissions when listing available credentials. The *intended* security model is that only users with Item/Configure rights for a specific job can view or interact with its credentials. Due to this bug, users who have global Item/Configure rights—but no rights on a given job—can still fetch all credential IDs registered as GitLab API tokens or as Secret text.

Why is this a problem?
Credential IDs aren't the actual secrets, but knowing which IDs (names or references) exist is a big step for attackers. With this info, attacks like phishing, brute force, or exploiting other flaws to access those secrets are easier.

Real-World Impact

Imagine you have dozens or hundreds of Secret text entries in Jenkins, many of which are for API tokens that integrate Jenkins with GitLab. You intend for only select teams to know which secrets exist and to only let them configure jobs with those secrets. Because of this flaw, someone with just global configure rights could enumerate the IDs of every GitLab API credential—potentially exposing secret usage, project names, or service accounts.

Attacker has log-in access to Jenkins

- Attacker has global Item/Configure rights
- Attacker does NOT have Item/Configure on a target job

Example: Exploit with Direct API Request

If your Jenkins instance exposes its REST API, this bug can be exploited programmatically!

Here’s a sample request an attacker could make

curl -u attacker:password "https://jenkins.example.com/job/anyJob/configure"; \
     -H 'Accept: application/json'

Alternatively, attacking the credentials listing endpoint (if such an endpoint is exposed)

GET /descriptorByName/com.gitlab.jenkins.plugins.gitlab.GitLabSCMSource/retrieveCredentials?apiVersion=1
Authorization: Basic <attacker-creds>
Cookie: JSESSIONID=<valid-session>

These endpoints would usually restrict credentials shown to only those accessible by the current user on that job. Because of CVE-2025-24397, attackers with only the *global* permission can still get back a list like:

[
    {"id": "gitlab-token-prod", "name": "Gitlab API Token - Prod"},
    {"id": "gitlab-token-dev", "name": "Gitlab API Token - Dev"},
    {"id": "app-secret-text", "name": "Secret Text for App"}
]

Code Snippet: Where the Check Goes Wrong

The issue is that, inside the plugin’s code (see GitLabCredentialProvider.java), the permission validation happens like this:

// WRONG: only checks for global Item.CONFIGURE, not per-job permission
if (Jenkins.get().hasPermission(Item.CONFIGURE)) {
    // List all credentials!
    return CredentialsProvider.lookupCredentials(
        StandardCredentials.class, Jenkins.get(), ...
    );
}

It should instead be

Job job = ...; // get the relevant job context
if (job.hasPermission(Item.CONFIGURE)) {
    // List credentials only allowed for this job
    return CredentialsProvider.lookupCredentials(
        StandardCredentials.class, job, ...
    );
}

References

- Jenkins Security Advisory for March 2025
- CVE Details for CVE-2025-24397
- Original GitLab Plugin Source
- Jenkins Plugin Security Best Practices

How to Protect Your Jenkins

1. Update the Plugin: Versions after 1.9.6 of the Jenkins GitLab Plugin have fixed this bug. Upgrade as soon as possible!
2. Audit Permissions: Double-check who has global Item/Configure in Jenkins. Restrict it tightly.
3. Review Logs: Check for suspicious credential enumeration or unexpected users accessing configuration pages.

Conclusion

CVE-2025-24397 teaches us the importance of checking permissions in the *right context* inside plugin code. If you use Jenkins with the GitLab plugin, don't delay: update your plugins and review your permission strategies today!

Timeline

Published on: 01/22/2025 17:15:13 UTC
Last modified on: 01/23/2025 17:15:27 UTC