CVE-2026-70426: Jenkins Remoting JEP-200 deserialization filter bypass SECURITY-3911 : unfiltered ClassNotFoundException fallback in MultiClassLoaderSerializer.resolveClass and ObjectInputStreamEx.resolveClass lets agents deserialize blocked core-classpath classes on the controller

Jenkins Remoting (agent–controller communication library) contains two unfiltered ClassNotFoundException fallback paths in its deserialization class-resolution code. In hudson.remoting.MultiClassLoaderSerializer.Input.resolveClass() (and identically in hudson.remoting.ObjectInputStreamEx.resolveClass()), the primary path resolves the incoming class name against the channel-annotated classloader and then applies the JEP-200 class filter (channel.classFilter.check(c)). When that lookup throws ClassNotFoundException, the fallback super.resolveClass(desc) resolved the class via the receiving JVM's own classloader without applying the class filter. An attacker able to speak the agent protocol (Agent/Connect permission, a compromised agent, or code running on an agent) can therefore deserialize a JEP-200-blocked class on the Jenkins controller by serializing it with a spoofed TAG_SYSTEMCLASSLOADER annotation, forcing the ClassNotFoundException fallback. The blocked class's readObject then executes in the controller JVM, yielding remote code execution on the controller.

• Package/component: org.jenkins-ci.main:remoting (Jenkins Remoting), embedded in Jenkins core (jenkins.war).
• Affected: Remoting <= 3384.v60d89463d9e0 (except backport 3355.3357.v931d3c992987); Jenkins weekly <= 2.575; LTS <= 2.568.1.
• Fixed: Remoting 3385.vf1123fb_515da_ (Jenkins 2.576 / LTS 2.568.2).
• Risk: Critical (CVSS 3.1 9.6, AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) — agent-to-controller RCE. AC:H because the gadget class must live on the controller's core classpath and evade the pre-JEP-200 static denylist (which this bypass does not defeat).

Impact Parity

• Disclosed/claimed maximum impact: arbitrary code execution on the Jenkins controller from the agent side of a Remoting channel (RCE).
• Reproduced impact from this run: OS command execution on the Jenkins controller JVM across the real JNLP4-connect (TCP) channel, proven twice by two independent direct OS-level observations per attempt: (1) /bin/sh -c executed on the controller writing a marker file with id/hostname output inside the controller container (uid=0(root) ... jvm_pid=...), and (2) an outbound TCP callback from the controller JVM to an attacker-controlled listener carrying the per-attempt token and the controller hostname.
• Parity: full.
• Not demonstrated: nothing material; the ClassCastException after readObject detonation is an artifact of the minimal PoC gadget (Serializable-only), not a limitation of the bypass. A real-world exploit would use a gadget class already on the core classpath whose readObject performs the malicious action (exactly the pattern this PoC models).

Root Cause

src/main/java/hudson/remoting/MultiClassLoaderSerializer.java (vulnerable line 137):

} catch (ClassNotFoundException ex) {
    return super.resolveClass(desc);        // <-- no channel.classFilter.check(...)
}

and identically src/main/java/hudson/remoting/ObjectInputStreamEx.java line 64:

} catch (ClassNotFoundException ex) {
    return super.resolveClass(desc);        // <-- no filter.check(...)
}

The name-based check channel.classFilter.check(name) still runs first, so classes on the pre-JEP-200 static denylist (e.g. commons-collections functors) remain blocked; but the class-level JEP-200 check (jenkins.security.ClassFilterImpl.isBlacklisted(Class)), which rejects classes whose code location is not Jenkins core/Remoting/a plugin and which are not in whitelisted-classes.txt, is skipped on the fallback path. An attacker forces the fallback by writing TAG_SYSTEMCLASSLOADER (-3) as the class annotation: the receiver then tries Class.forName(name, false, null) (bootstrap loader), which throws ClassNotFoundException for any non-JDK class, and the fallback resolves the class through the deserializing frame's classloader (on a real controller, the Jetty webapp classloader, which can see the whole core classpath and delegates to the application classloader) — completely bypassing the JEP-200 decision.

Fix commit: f1123fb515da74560db60645539019cfa77bce49 (jenkinsci/remoting, released as 3385.vf1123fb_515da_): both fallbacks became return channel.classFilter.check(super.resolveClass(desc)); / return filter.check(super.resolveClass(desc));. Diff captured in bundle/repro/security3911-fix.diff; vulnerable/fixed source lines captured in bundle/logs/vuln_unfiltered_fallback.txt and bundle/logs/fixed_filtered_fallback.txt.

Reproduction Steps

1. bundle/repro/reproduction_steps.sh (self-contained; uses only Docker images jenkins/jenkins:2.575-jdk21, jenkins/jenkins:2.576-jdk21, maven:3.9-eclipse-temurin-21, alpine:3.22 plus the harness sources in bundle/repro/harness/).
2. What it does:
   • Records the image digests and the war manifests (Remoting-Embedded-Version: 3384.v60d89463d9e0 for 2.575, 3385.vf1123fb_515da_ for 2.576) and the real fix-commit diff from a jenkinsci/remoting checkout (verifying the exact vulnerable and fixed lines).
   • Extracts the byte-identical remoting-3384.v60d89463d9e0.jar from the vulnerable war and compiles the PoC gadget (hudson.security3911.Payload, Serializable, readObject executes /bin/sh + outbound callback) into payload.jar, and the attack agent.
   • For each of two vulnerable and two fixed attempts: boots a real Jenkins controller (fresh JENKINS_HOME, setup wizard disabled, inbound-agent TCP listener on port 50000, production JnlpSlaveAgentProtocol4 accept path) with payload.jar on the controller's own launch classpath (a harness jar, as sanctioned by the ticket's reproduction requirements — the filter, channel, and UserRequest.deserialize path are 100% product code). init.groovy.d creates the agent1 inbound node, prints its JNLP secret, and proves the production JEP-200 filter identity: SECURITY3911_CHANNEL_DEFAULT_FILTER=jenkins.security.ClassFilterImpl and SECURITY3911_FILTER_PROBE=REJECTED: Rejected: hudson.security3911.Payload (i.e. the production filter blocks the payload class at class level on both builds).
   • The attack agent performs the real JNLP4-connect handshake using the production negotiation classes (JnlpAgentEndpoint, JnlpProtocolHandlerFactory, JnlpProtocol4Handler, IOHub, PublicKeyMatchingX509ExtendedTrustManager), builds a genuine hudson.remoting.UserRequest, replaces its serialized request bytes with bytes produced by a SpoofedTagSystemClassLoaderOutput (exactly the regression-test helper from the fix commit), and sends it over the established channel. The controller's DefaultJnlpSlaveReceiver.afterChannel/SlaveComputer.setChannel production flow runs on the same connection.
3. Expected evidence:
   • Vulnerable (2.575): Payload.readObject executes on the controller during UserRequest.deserialize → marker file /tmp/CONTROLLER_PWNED_<token>.txt inside the controller container (contents include uid=0(root) and the controller hostname) AND an outbound callback SECURITY3911_CALLBACK token=... phase=readObject controller_host=<controller> received by the attacker's listener.
   • Fixed (2.576): SecurityException: Rejected: hudson.security3911.Payload; see https://jenkins.io/redirect/class-filter/ returned over the channel; no marker, no callback.

Evidence

• Full run log: bundle/logs/reproduction_steps.log (two consecutive full runs, both OVERALL=0, exit code 0).

• Per-attempt controller and agent logs: bundle/logs/attempt-{vuln,fixed}-{1,2}/{controller,agent}.log.

• Direct OS-execution markers (collected from inside the controller containers via docker exec): bundle/logs/attempt-vuln-1/CONTROLLER_PWNED_security3911-vuln-1-*.txt and bundle/logs/attempt-vuln-2/CONTROLLER_PWNED_security3911-vuln-2-*.txt, e.g.:

  SECURITY3911_MARKER token=security3911-vuln-1-1786004490 phase=readObject
  uid=0(root) gid=0(root) groups=0(root)
  dc3492613861            <- controller container hostname
  jvm_pid=100
  

• Outbound callback (agent log): CALLBACK_RECEIVED from=/172.19.0.2:38064 msg=SECURITY3911_CALLBACK token=security3911-vuln-1-1786004490 phase=readObject controller_host=dc3492613861 — the source IP and hostname belong to the controller container, proving the controller JVM executed attacker code and dialed out.

• Vulnerable-channel exception (expected, post-detonation): ClassCastException: class hudson.security3911.Payload cannot be cast to class hudson.remoting.Callable (hudson.security3911.Payload is in unnamed module of loader 'app'; ...) — confirms the fallback resolved the class via the controller-side loader.

• Fixed-channel rejection: EXCEPTION=Error: Failed to deserialize the Callable object. <- SecurityException: Rejected: hudson.security3911.Payload; see https://jenkins.io/redirect/class-filter/ with CALLBACK_COUNT=0 and no marker.

• Production filter provenance (controller log, both builds): SECURITY3911_CHANNEL_DEFAULT_FILTER=jenkins.security.ClassFilterImpl, SECURITY3911_FILTER_PROBE=REJECTED: Rejected: hudson.security3911.Payload, and the JUL line jenkins.security.ClassFilterImpl#notifyRejected: hudson.security3911.Payload in file:/opt/harness/payload.jar might be dangerous, so rejecting.

• Negative control: bundle/repro/negative_control_observation.json (both fixed attempts: rejection observed, command_executed=false, zero callbacks, zero marker files).

• Environment: Docker 29.1.3; jenkins/jenkins:2.575-jdk21 (@sha256:16778c994cfc..., Remoting 3384.v60d89463d9e0) and jenkins/jenkins:2.576-jdk21 (@sha256:8c1c7e28b463..., Remoting 3385.vf1123fb_515da_); OpenJDK 21 controllers/agents; harness SHA-256s in bundle/logs/harness_sha256.txt.

Recommendations / Next Steps

• Upgrade to Jenkins 2.576 / LTS 2.568.2 (Remoting 3385.vf1123fb_515da_) or the 3355.3357.v931d3c992987 backport line.
• The fix is correct and minimal: route both ClassNotFoundException fallbacks through the channel's class filter, mirroring the primary path.
• Defense in depth: restrict Agent/Connect, isolate agents, and monitor for Rejected: ... class-filter log lines plus unexpected outbound connections from the controller.
• Testing: the fix commit's regression tests (ClassFilterTest multiClassLoaderSerializer_spoofedSystemClassLoader_isRejected and objectInputStreamEx_emptyClassLoader_fallbackIsFiltered) cover both fallbacks; this run reproduces the same spoof over the real JNLP4/TCP production path.

Additional Notes

• Idempotency: the script runs two clean attempts per role with fresh JENKINS_HOME per attempt, unique per-attempt tokens, a fresh Docker network per run, and full container cleanup; two consecutive end-to-end runs both passed (OVERALL=0).
• The second vulnerable fallback (ObjectInputStreamEx.resolveClass) is exercised when the remote peer does not advertise multi-classloader RPC capability; it is fixed by the same commit and follows the identical pattern (documented in the diff); the primary proof uses the MultiClassLoaderSerializer path, which is the default for JNLP4 agent channels.
• The harness payload class implements only Serializable (not hudson.remoting.Callable) because the controller's webapp/application classloader split would otherwise fail linking; this mirrors a real gadget whose effect lives in readObject, and it makes the proof stronger: execution happens during deserialization, before any Callable cast or arbitrary-callable permission check.
• Fresh Jenkins installs do not auto-install bundled detached plugins; the script installs the war-bundled instance-identity.hpi + bouncycastle-api.hpi into JENKINS_HOME/plugins (what the setup wizard would do) so the production JNLP4 TLS listener is functional.