CVE-2026-92133

Jenkins GitLab Plugin 1.2149.vcfc32c82b_f7f and earlier caches the GitLab API client it builds for alternative GitLab API token credentials using a cache key derived only from the credentials ID, omitting the folder in which the credential was resolved. As a result, when credentials with the same ID exist in different folders, a cached client built with one folder's token can be reused for an item in another folder. An attacker with Item/Configure permission on an item can trigger this and effectively use a GitLab API token credential they are not entitled to, gaining limited unauthorized access to the connected GitLab instance (low confidentiality and integrity impact per the CVSS score of 5.4). Affected users are operators of Jenkins controllers running the GitLab Plugin at or below 1.2149.vcfc32c82b_f7f, particularly multi-folder setups that use folder-scoped credentials sharing IDs. Exploitation has not been observed in the wild, no public proof-of-concept is known, and the issue is not listed in CISA's KEV catalog.

What to do: Update the Jenkins GitLab Plugin to the first patched release after 1.2149.vcfc32c82b_f7f (fixes were shipped alongside Jenkins' batch advisory covering 20 plugin vulnerabilities). Meanwhile, audit folder-scoped GitLab API token credentials for colliding IDs across folders and restrict Item/Configure permission to trusted users. Check GitLab audit logs for unexpected API activity that could indicate a token was used without authorization.