Jenkins shipped a fix on August 5 for a critical hole in the deserialization protections that were supposed to be the platform’s main defense against exactly this class of bug. CVE-2026-70426 (CVSS 9.0) shows that the JEP-200 class filter — Jenkins’ hardening layer against untrusted deserialization, introduced years ago after a string of RCE disasters — has a fallback code path that never got the filter applied to it. Anything that can reach that path can turn deserialization back into remote code execution on the controller.

What happened

Jenkins’ security team disclosed the flaw as SECURITY-3911 in the 2026-08-05 security advisory. It lives in the Remoting library, the RMI-like channel that Jenkins controllers use to talk to build agents. Remoting has carried the JEP-200 class filter since 2019 specifically to stop agents (and anyone who can act as one) from smuggling malicious serialized objects to the controller. CVE-2026-70426 exists because that filter is only enforced on the primary resolution path — a secondary, fallback path used to resolve certain classes skips the filter entirely, and it will happily resolve classes already present on the Jenkins core classpath.

Affected versions are Remoting 3384.v60d89463d9e0 and earlier (all versions except 3355.3357.v931d3c992987), shipped inside Jenkins weekly 2.575 and earlier, and Jenkins LTS 2.568.1 and earlier. Given how Remoting is bundled into essentially every Jenkins install, the exposed footprint is the entire non-updated fleet.

Technical details

Exploitation requires the ability to act as, or execute code on, a Jenkins agent — either a compromised build agent, a malicious job that runs untrusted build steps, or an attacker who already holds the Agent/Connect permission. From that position, the attacker crafts a serialized payload that resolves through the unfiltered fallback path instead of the JEP-200-protected primary path. Because the fallback path still permits classes on the Jenkins core classpath, gadget chains built from core Jenkins classes are usable for the bypass, and successful exploitation yields arbitrary code execution on the controller process itself.

This is the same failure shape as prior JEP-200 bypasses: the filter is a blocklist/allowlist gate on a specific deserialization entry point, and each new bypass tends to be a previously-overlooked entry point rather than a flaw in the filter’s logic. It’s a reminder that class-filter defenses are only as strong as their coverage across every code path that touches ObjectInputStream.

Impact assessment

A controller compromise via CI/CD tooling is close to worst-case for a software organization. Jenkins controllers routinely hold deploy keys, cloud provider credentials, container registry tokens, code-signing material, and source access spanning every project the instance builds. An attacker who lands controller-level code execution through this bypass can tamper with build artifacts before they ship, exfiltrate secrets wholesale, and pivot into every downstream system those credentials touch — the textbook build-pipeline-to-supply-chain escalation. Multi-tenant Jenkins deployments where less-trusted teams or contractors run their own agents or jobs are the most exposed, since the required Agent/Connect permission or agent-side code execution is exactly what those setups grant by design.

No public PoC or confirmed in-the-wild exploitation has surfaced yet as of this writing, but the bug class (JEP-200 bypass, controller RCE) has a track record of rapid weaponization once researchers or attackers reverse the patch diff — the prior Jenkins deserialization RCE, CVE-2026-53435, went from disclosure to active exploitation in five days. Treat the patch window accordingly.

Mitigation — what to do now

  • Upgrade to Jenkins weekly 2.576 or LTS 2.568.2, both of which apply the class filter to the fallback resolution path.
  • If immediate patching isn’t possible, restrict who can hold Agent/Connect permission and audit which principals can register or run code as an agent — this is the access the bug requires.
  • Treat build agents as a trust boundary: don’t run untrusted or third-party job definitions on agents that share a Remoting channel with a controller holding production secrets.
  • Rotate credentials stored in Jenkins (deploy keys, cloud tokens, signing keys) if you have any indication an agent or job may have been compromised prior to patching.
  • Review the full 2026-08-05 advisory — SECURITY-3911 shipped alongside other fixes in the same release train.

Jenkins remains one of the most exposed pieces of infrastructure in a typical software organization precisely because it’s the thing every other system trusts. Patch controllers first, then chase down every stale agent still running the old Remoting jar.