CVE-2026-92133 Overview
CVE-2026-92133 affects the Jenkins GitLab Plugin version 1.2149.vcfc32c82b_f7f and earlier. The plugin caches the GitLab API client built for alternative GitLab API token credentials using a cache key derived from the credentials ID alone. The cache key omits the folder in which the credentials are resolved. Attackers with Item/Configure permission can access GitLab API token credentials they are not entitled to use. The weakness maps to [CWE-522: Insufficiently Protected Credentials].
Critical Impact
Authenticated users with job configuration rights can reuse cached GitLab API tokens from other folders, breaking Jenkins credential isolation boundaries.
Affected Products
- Jenkins GitLab Plugin 1.2149.vcfc32c82b_f7f
- Jenkins GitLab Plugin earlier releases using the same cache implementation
- Jenkins controllers relying on folder-scoped GitLab API token credentials
Discovery Timeline
- 2026-09-16 - CVE CVE-2026-92133 published to NVD
- 2026-09-16 - Jenkins Security Advisory SECURITY-3851 released
- 2026-09-16 - Last updated in NVD database
Technical Details for CVE-2026-92133
Vulnerability Analysis
The Jenkins GitLab Plugin builds an API client instance for each set of alternative GitLab API token credentials it uses. To avoid rebuilding the client on every call, the plugin caches instances keyed by the credentials identifier. The cache lookup ignores the folder context in which the credentials were originally resolved.
Jenkins credential scoping relies on folders to isolate secrets between teams and projects. Two different folders can legitimately define distinct credentials that share the same string identifier. When the plugin services a request, it returns whichever cached client was created first for that identifier, regardless of the caller's folder scope.
The impact is confined to confidentiality and integrity of GitLab operations performed through the plugin. An attacker cannot exfiltrate the raw token value, but they can direct the cached client to perform GitLab API calls under another team's identity.
Root Cause
The root cause is an incomplete cache key. The plugin uses only the credentials ID as the map key for the GitLab API client cache. Folder path, credential domain, and resolution context are omitted. This violates the credential lookup contract enforced elsewhere in Jenkins, where folder-scoped credentials must not leak across folder boundaries.
Attack Vector
An attacker requires an authenticated Jenkins account with Item/Configure permission on any job in the controller. The attacker creates or modifies a job that references a credentials identifier matching one used in another folder. When the plugin resolves the identifier, it returns the cached API client bound to the higher-privileged folder's token. Subsequent GitLab operations execute with the victim's token privileges. Exploitation requires no user interaction and occurs entirely over the network path to the Jenkins controller. Refer to the Jenkins Security Advisory SECURITY-3851 for authoritative technical detail.
Detection Methods for CVE-2026-92133
Indicators of Compromise
- GitLab API requests originating from the Jenkins controller that use tokens not expected for the requesting job's folder scope.
- Creation or modification of Jenkins jobs that reference GitLab credential identifiers matching credentials stored in unrelated folders.
- GitLab audit log entries showing token usage patterns that do not correlate with the owning team's build activity.
Detection Strategies
- Correlate Jenkins job configuration change events with the credential identifiers referenced, flagging identifier collisions across folders.
- Compare GitLab API token usage timestamps against the schedules of jobs authorized to hold those credentials.
- Review Jenkins audit logs for users with Item/Configure permission who reference credential IDs outside their assigned folder tree.
Monitoring Recommendations
- Ingest Jenkins controller logs and GitLab audit events into a centralized data lake for cross-source correlation.
- Alert on new Jenkins jobs that reference GitLab credential identifiers previously scoped to sensitive folders.
- Track GitLab personal access token scopes and rotate tokens observed making anomalous API calls.
How to Mitigate CVE-2026-92133
Immediate Actions Required
- Inventory Jenkins folders and identify any GitLab credential identifiers reused across folders.
- Restrict Item/Configure permission to trusted users until the plugin is upgraded.
- Rotate GitLab API tokens configured in Jenkins if folder isolation was previously assumed as a security boundary.
Patch Information
Upgrade the Jenkins GitLab Plugin to a release later than 1.2149.vcfc32c82b_f7f that addresses SECURITY-3851. Consult the Jenkins Security Advisory SECURITY-3851 for the fixed version and upgrade guidance.
Workarounds
- Use unique credential identifiers across all Jenkins folders to prevent cache key collisions.
- Limit Item/Configure and job creation permissions using Jenkins role-based access control.
- Restart the Jenkins controller after credential changes to flush the in-memory GitLab API client cache.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
