CVE-2026-92133

Executive Summary

CVE-2026-92133 is a credential-handling vulnerability in the Jenkins GitLab Plugin (version 1.2149.vcfc32c82b_f7f and earlier) that causes the GitLab API client to be cached under a key derived only from the credentials ID, without including the folder context in which the credentials are resolved. An attacker with Item/Configure permission can therefore cause the plugin to reuse a GitLab API client bound to credentials belonging to another folder, gaining access to GitLab API token credentials they are not entitled to use. Impact is bounded but meaningful: token disclosure and unauthorized GitLab API actions under the victim's identity within the affected Jenkins instance's trust boundary.

Technical Analysis

The vulnerability class is CWE-522: Insufficiently Protected Credentials, manifesting as a cache-key scoping flaw rather than a cryptographic or storage failure.

Jenkins credentials are organized hierarchically. Multiple folders within a single Jenkins controller can each hold a credential that shares the same credentials ID but resolves to different underlying GitLab API tokens. This is a legitimate and common configuration: the credentials ID is a logical name, and the "scope" is determined by the folder path where the credential is resolved (store hierarchy, with folder-local stores taking precedence over the global store).

The GitLab Plugin constructs a GitLab API client from a set of Jenkins credentials and caches that client to avoid rebuilding it on every invocation. According to the NVD description, the cache key is derived from the credentials ID alone — the folder in which the credentials were resolved is omitted from the key.

The consequence is a cache key collision across security scopes:

1. A user with Item/Configure permission on a job in Folder A configures that job to use a GitLab connection whose credentials ID is, for example, gitlab-token.
2. The plugin resolves gitlab-token for Folder A's context and caches the resulting API client under the key gitlab-token.
3. A different job, running under Folder B, legitimately configures the same credentials ID gitlab-token, creating the intended binding to a different token that Folder B owns.
4. Because the cache key does not include the folder, the second resolution can be served the first cached client — i.e. Folder A's token — or vice versa, depending on resolution order and cache population timing.

The attacker does not need to break any credential encryption. They need only the ability to configure a job that references a GitLab credentials ID, plus the ability to observe the effects of the mis-resolved credential — for example by triggering a build step that calls the GitLab API through the plugin and examining the API responses, error messages, or downstream behavior that reveals which identity the token represents.

The attack surface is therefore the Jenkins controller's job configuration API and UI, not the network edge. CVSS reflects this precisely:

• AV:N (Network) — the Jenkins controller is typically reachable over HTTP(S).
• AC:L (Low) — no race condition or specialized conditions required beyond normal caching behavior.
• PR:L (Low) — the attacker must hold Item/Configure permission, which is a non-trivial but commonly granted privilege.
• UI:N (None) — no victim interaction required.
• S:U (Unchanged) — the impact is confined to the Jenkins/GitLab credential scope.
• C:L (Low) / I:L (Low) / A:N (None) — confidentiality and integrity impact is limited to what the mis-resolved GitLab API token authorizes; there is no direct availability impact on Jenkins itself.

Score: 5.4 (Medium).

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template is available for CVE-2026-92133. The chain below is inferred from the vulnerability class (credential cache scoping / CWE-522) and the NVD description. It does not rely on any implementation detail beyond what the description states.

1. Reconnaissance / target identification. An attacker who already holds an authenticated Jenkins account with Item/Configure permission enumerates the controller. Relevant intelligence includes: folder structure, which credentials IDs exist and are usable, and which jobs reference GitLab connections. The attacker looks for a credentials ID that appears in more than one folder scope — or, failing that, simply uses any GitLab credentials ID they can legitimately name and observes whether the resolved client corresponds to a token that is not theirs. Tooling available to the attacker includes the Jenkins REST/CLI APIs for job configuration and the standard credential-listing visibility rules (credentials metadata such as IDs and descriptions is often visible to users who cannot read the secret material itself — which is precisely why a mis-resolved client is valuable to the attacker).

2. Triggering the flaw class. The attacker configures (or modifies) a job so that its GitLab connection uses a chosen credentials ID. When the plugin builds the GitLab API client for that credentials ID, the cache lookup is performed with a key that omits the folder. If a client for the same credentials ID was already cached from a different folder, the attacker's job receives the existing client rather than a freshly resolved one.

3. Payload / execution at the class level. There is no memory-corruption or injection payload. The "payload" is a configuration binding: the attacker points a build step or plugin-mediated operation at the GitLab API and lets the plugin authenticate with whatever token the cached client carries. Execution manifests as an outbound GitLab API call made with credentials the attacker is not entitled to use. The attacker then infers the token's identity and privileges from the API responses returned to the build.

4. Post-exploitation impact. With a mis-resolved token, the attacker operates against GitLab under the victim credential's identity, bounded by that token's scopes: reading repositories, project metadata, CI variables, merge requests, or performing write actions if the token permits. CVSS assigns C:L and I:L, meaning the plugin authors/NVD assess the practical blast radius as limited (token scopes, single trust boundary, no code execution on the Jenkins controller). The primary long-term risk is lateral movement from Jenkins configuration rights into GitLab SCM rights — an attacker who can configure Jenkins jobs can potentially convert that privilege into GitLab-side access.

Impact Assessment

Business impact centers on credential disclosure and unauthorized use within a source-control trust boundary, not on remote code execution or service outage.

• Confidentiality (C:L): Exposure of GitLab API token credentials the attacker is not entitled to use. The exact data reachable depends entirely on the scopes of the mis-resolved token.
• Integrity (I:L): If the leaked token carries write scopes, the attacker can modify GitLab-side resources (branches, tags, merge requests, CI configuration) under the victim identity. No integrity impact is assigned to Jenkins configuration integrity itself in the CVSS vector beyond this.
• Availability (A:N): No availability impact asserted.
• Scope (S:U): The vulnerability is scoped to the credential resolution context; there is no privilege escalation beyond the accessible GitLab token.

Affected systems: Jenkins controllers running the GitLab Plugin at version 1.2149.vcfc32c82b_f7f or earlier, where the same credentials ID is used across multiple folder scopes.

Blast radius: Bounded by (a) the number of GitLab credentials IDs that are duplicated across folders, (b) the privileges of those tokens, and (c) the number of users who hold Item/Configure on any job that can reference those IDs. In organizations that centralize Jenkins with a flat job namespace and unique credentials IDs, exploitation is not possible because there is no cross-folder ID collision. In organizations using folder-scoped multi-tenant Jenkins with duplicated credentials IDs, the precondition is realistic.

No CISA KEV listing, no known exploitation in the wild, and no public PoC were identified at time of writing. This is assessed as proof-of-concept-stage / opportunistic risk rather than active campaign risk.

Detection Guidance

Detection must focus on two planes: (1) Jenkins job-configuration changes that reference GitLab credentials, and (2) outbound GitLab API traffic whose source identity does not match the initiating job's folder scope. Because the flaw is a logic/credential-scoping bug, network signatures are inherently approximate — the rules below are behavioral heuristics, not precise exploit signatures.

Sigma Rule

title: Jenkins GitLab Plugin Cross-Folder Credential Cache Abuse (CVE-2026-92133)
id: 8b6f0a2c-3f1e-4d9a-9c2b-1a7e5d4c92133
status: experimental
description: Detects job configuration changes that bind GitLab credentials in Jenkins, a precondition for abusing the folder-agnostic credential cache in the Jenkins GitLab Plugin (CVE-2026-92133).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-92133
author: threat-intel
date: 2026/01/01
tags:
  - attack.t1078
  - cwe.522
logsource:
  product: jenkins
  service: audit
detection:
  selection_event:
    eventAction:
      - 'configSubmit'
      - 'update'
      - 'created'
      - 'updated'
  selection_target:
    eventType: 'Item'
  selection_gitlab:
    - 'gitlab'
    - 'gitlabConnection'
    - 'gitlabApiToken'
  filter_known_automation:
    authenticatedUser:
      - 'automation-bot'
      - 'svc-jenkins'
  condition: selection_event and selection_target and selection_gitlab and not filter_known_automation
falsepositives:
  - Legitimate job edits that change GitLab connections in normal change windows
  - Configuration-as-Code reconciliation runs
level: medium

YARA Rule

rule CVE_2026_92133_Jenkins_GitLab_Credential_Cache
{
    meta:
        description = "Heuristic detection of Jenkins GitLab Plugin descriptors referencing GitLab credentials IDs, relevant to CVE-2026-92133 analysis of job configs and plugin metadata"
        author = "threat-intel"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-92133"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $p1 = "gitlab" ascii nocase
        $p2 = "GitLabConnection" ascii nocase
        $p3 = "gitlabApiToken" ascii nocase
        $p4 = "com.dabsquared.gitlabjenkins" ascii nocase
        $p5 = "credentialsId" ascii nocase

    condition:
        filesize < 2MB and
        (uint32(0) == 0x04034b50 or uint32(0) == 0x504B0304 or true) and
        ($p4 or ($p1 and $p5) or ($p2 and $p5) or ($p3 and $p5))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-92133 Jenkins GitLab Plugin - suspicious job config referencing GitLab credentials"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/configSubmit" or content:"/config.xml"; http.request_body; content:"gitlab"; nocase; http.request_body; content:"credentialsId"; nocase; threshold:type limit, track by_src, count 5, seconds 60; classtype:attempted-user; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-92133; sid:202692133; rev:1;)

alert http any any -> any any (msg:"CVE-2026-92133 Jenkins GitLab Plugin - GitLab API call from Jenkins controller"; flow:established,to_server; http.host; content:"gitlab"; nocase; http.header; content:"PRIVATE-TOKEN"; nocase; threshold:type limit, track by_src, count 50, seconds 60; classtype:policy-violation; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-92133; sid:202692134; rev:1;)

Elastic Detection

sequence by process.entity_id with maxspan=5m
  [process where process.name : "java" and process.args : "*jenkins*"]
  [file where file.name : "config.xml" and file.path : "*jobs*"]
  [network where network.protocol == "http" and
      process.name : "java" and
      url.domain : "*gitlab*" and
      http.request.headers contains "PRIVATE-TOKEN"]

Splunk SPL Query

index=jenkins_audit OR index=jenkins
(eventAction="configSubmit" OR eventAction="update" OR eventAction="created" OR eventAction="updated")
(eventType="Item" OR eventType="Folder")
| eval blob=lower(_raw)
| where match(blob, "gitlab") AND match(blob, "credentialsid")
| stats count min(_time) as first_seen max(_time) as last_seen values(eventAction) as actions values(authenticatedUser) as users by jenkins_item_path, authenticatedUser
| where count >= 1
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| sort - last_seen

Wazuh OSSEC Rule

<group name="jenkins,cve-2026-92133,">
  <rule id="202692133" level="8">
    <decoded_as>json</decoded_as>
    <field name="eventAction">configSubmit|update|created|updated</field>
    <field name="eventType">Item|Folder</field>
    <regex type="pcre2">(?i)gitlab</regex>
    <regex type="pcre2">(?i)credentialsId</regex>
    <description>CVE-2026-92133: Jenkins job configuration changed referencing GitLab credentials - possible cross-folder credential cache abuse precondition</description>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>

  <rule id="202692134" level="10">
    <if_sid>202692133</if_sid>
    <field name="authenticatedUser">^(?!automation-bot|svc-jenkins).*$</field>
    <description>CVE-2026-92133: Non-automation user modified GitLab credential binding in Jenkins - investigate for credential scope abuse</description>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence is 0/4 (UNPATCHED). No patch reference, vendor fix, or tracked workaround was identified in any source at time of writing. The following guidance is therefore precautionary and must be re-validated once the Jenkins security advisory for this issue ships.

1. Immediate mitigations.

• Eliminate cross-folder credentials-ID collisions. Audit all GitLab credentials IDs across global and folder scopes. Ensure no credentials ID is reused in more than one resolution scope. Where duplicates exist, re-key them with scope-unique identifiers (e.g. gitlab-token-folderA, gitlab-token-folderB). This removes the precondition for the cache collision entirely and is the single most effective control.
• Reduce Item/Configure exposure. Item/Configure is a heavily granting permission. Review which principals hold it and apply least privilege — particularly for users on multi-tenant Jenkins controllers where folder isolation is a security boundary.
• Restrict and monitor GitLab token scopes. Reduce the blast radius of any token that could be mis-resolved: enforce minimum necessary scopes, prefer read-only tokens where build jobs only need read access, and set expiry dates.
• Treat the flaw as a cross-boundary credential leak for IR purposes. If you operate a multi-tenant controller, assume that any user with Item/Configure may have observed a GitLab token identity belonging to another folder and rotate affected tokens.

2. Patch / upgrade steps.

• No fixed version is currently available. Monitor the Jenkins Security Advisories page and the GitLab Plugin changelog for the version that includes the folder-aware cache key fix.
• When a patched plugin version is released, upgrade the GitLab Plugin via the Jenkins Update Center (or your configuration-management tooling) and restart the controller.
• Prior to restart, rotate all GitLab API token credentials referenced by the affected plugin, since the exposure may already have occurred.
• Validate post-upgrade that repeated runs across folder scopes resolve distinct, correct tokens (e.g. by asserting the token identity observed in build logs matches the expected folder).

3. Long-term hardening.

• Enforce scope-unique naming conventions for credentials IDs in CI/CD governance policy and CI linters.
• Adopt external, centrally scoped secret management (Hashicorp Vault, cloud secret managers) with Jenkins credential bindings that carry explicit, scope-qualified identifiers, rather than relying on Jenkins-internal folder semantics.
• Where possible, use one Jenkins controller per trust boundary to eliminate the folder-as-security-boundary pattern.
• Add the detection rules above to SIEM and audit pipelines, and alert on any configuration change that introduces or modifies GitLab credential bindings outside a change window.

References

• NVD — CVE-2026-92133: https://nvd.nist.gov/vuln/detail/CVE-2026-92133
• CWE-522: Insufficiently Protected Credentials: https://cwe.mitre.org/data/definitions/522.html
• Jenkins Security Advisories (monitor for the advisory covering the GitLab Plugin fix): https://www.jenkins.io/security/advisories/
• Jenkins GitLab Plugin (release/changelog source for the eventual patched version): https://plugins.jenkins.io/gitlab-plugin/
• MITRE ATT&CK T1078 — Valid Accounts: https://attack.mitre.org/techniques/T1078/

Exploit-in-the-wild status: None. No public PoC, no Nuclei template, no CISA KEV listing, and no threat-actor campaign evidence was identified for CVE-2026-92133 at time of writing. EPSS has not yet been scored by FIRST.org and no EPSS value should be inferred. The vulnerability is currently assessed as an unpatched, medium-severity credential-scoping flaw requiring authenticated Item/Configure access on a multi-tenant Jenkins controller — a realistic but precondition-heavy exploitation model.