GPU VulnDB

Database/Control plane, storage & DevOps

Jenkins: agent config update names its own target, letting one agent's configurer take over another

CVE-2026-84651Control plane, storage & DevOpscurated

Impact

The REST API and CLI endpoints that update agent configuration do not check that the submitted XML describes the agent being edited, so a user holding Agent/Configure on one agent can name a different agent in the document and overwrite it. The attacker gains that agent's configuration, its inbound agent secret and its environment variables. On a GPU fleet agents are the build executors pinned to specific hardware, and their environment variables routinely carry registry credentials, cloud keys and cluster tokens; the inbound secret additionally lets an attacker impersonate that node's connection to the controller and receive work intended for it. This is a boundary failure between teams that each own their own agents, not a controller-admin-only issue.

Who can reach it

Authenticated Jenkins user holding Agent/Configure on at least one agent, reaching the controller's HTTP REST API or CLI. No administrator rights and no access to the victim agent are required.

What to do

Upgrade Jenkins past the affected lines - the record names 2.579 and earlier and LTS 2.568.2 and earlier as vulnerable; check SECURITY-4025 in the 2026-09-02 advisory for the exact fixed release. Applying it means restarting the controller JVM: the queue pauses, running builds are lost unless drained first, and agents reconnect on their own. No GPU node reboot. Because the flaw discloses inbound agent secrets, rotate the secrets of any agent whose configuration could have been touched and tighten who holds Agent/Configure.

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.