Database/Control plane, storage & DevOps

Jenkins GitLab plugin: global connection URL can be overwritten, sending admin API tokens to an attacker

CVE-2026-84664Control plane, storage & DevOpscurated

Impact

The plugin lets a low-privileged authenticated user rewrite the controller-wide GitLab connection through Stapler data binding, including the endpoint URL. The GitLab API tokens an administrator configured stay in place and are then presented to whatever host the attacker names, which hands over a credential that in most build fleets can read and often write the repositories that define pipelines, Helm charts and container image builds. On a GPU fleet whose job definitions, model-serving manifests and node bootstrap come out of GitLab, a stolen API token is a supply-chain foothold rather than a CI nuisance. It also silently redirects every job using that connection, so status reporting and merge-request integration break in ways that look like a GitLab outage.

Who can reach it

Remote authenticated Jenkins user with low privileges (PR:L). No administrator rights and no user interaction are required; the target is the controller's own global configuration.

What to do

Upgrade the GitLab plugin past 1.9.16 per SECURITY-4097 in the 2026-09-02 Jenkins advisory; the advisory names 1.9.16 and earlier as affected without stating a fixed release, so take the current plugin version. Cost is a controller restart to load the plugin - the queue pauses, agents reconnect, and running builds are lost unless you drain first. Because tokens may already have been sent elsewhere, rotate the GitLab API credentials configured in Jenkins as part of the same window rather than after it.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-84664 https://www.jenkins.io/security/advisory/2026-09-02/#SECURITY-4097

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.