GPU VulnDB

Database/Control plane, storage & DevOps

Jenkins: inconsistent case handling in user and group names allows impersonation of other accounts

CVE-2026-70429Control plane, storage & DevOpscurated

Impact

Jenkins treats case in user and group names inconsistently across its authentication and authorization paths. An attacker who can create a user or group whose name case-insensitively matches an existing one can, in some configurations, be treated as that principal and inherit its permissions. On a GPU fleet the Jenkins controller is usually the thing holding registry push credentials, cluster kubeconfigs, and firmware or driver rollout jobs, so inheriting an administrator's or release engineer's permissions means being able to change what image lands on the nodes. The record does not enumerate which security realms are affected, so the practical blast radius depends on your realm and whether name creation is open to the attacker.

Who can reach it

Anyone able to create a new user or group name in the configured security realm - open signup on the built-in database, or a directory or SSO source where the attacker influences account and group names. No prior Jenkins permissions on the target account are needed.

What to do

Upgrade past Jenkins 2.575 (weekly) or LTS 2.568.1; the advisory for 2026-08-05 SECURITY-3924 has the exact fixed releases - take them from there rather than assuming the next point release. In the meantime disable open signup and audit existing users and groups for names that differ only by case. Upgrading the controller is a Jenkins service restart with builds quiesced; agents and GPU nodes are untouched.

References

Related entries

All Control plane, storage & DevOps entries

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.