GPU VulnDB

Database/Control plane, storage & DevOps

Jenkins Remoting: JEP-200 deserialization filter bypassed via fallback class resolution on the controller

CVE-2026-70426Control plane, storage & DevOpscurated

Impact

The JEP-200 class filter is not applied to classes resolved through a fallback path in Remoting's deserialization code, so anything on the Jenkins core classpath can be deserialized. Agent processes, code running on agents, and anyone holding Agent/Connect can use this to send gadget chains the filter was meant to stop - turning a build executor into a path toward the controller. In a GPU fleet the Jenkins controller is usually the account that pushes images, holds kubeconfigs and cloud credentials, and can schedule work on the cluster, so a compromise there is a fleet-wide credential problem. Build agents that run tenant or contributor code are the natural launch point, since agents are exactly the untrusted side of this trust boundary.

Who can reach it

A connected agent process, any code executing on an agent (a build step), or a network attacker holding the Agent/Connect permission. The agent-to-controller channel is the path; no controller-side authentication beyond agent connectivity is required.

What to do

Update Jenkins past the affected lines: the record names Remoting 3384.v60d89463d9e0 and earlier (except 3355.3357.v931d3c992987) as bundled in Jenkins 2.575 and earlier and LTS 2.568.1 and earlier - check the 2026-08-05 advisory for the exact fixed release. Applying it means restarting the controller JVM, which aborts running builds and drops agent connections; agents reconnect and pick up the updated Remoting jar automatically. No node reboot is involved.

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.