CVE-2026-34486: Apache Tomcat — EncryptInterceptor Bypass, Cluster RCE

Background

Apache Tomcat is the dominant open-source Java servlet container and web server, deployed across enterprise applications, financial services platforms, and government systems worldwide. Tomcat includes a clustering module, Tribes, that enables session replication and messaging across multiple Tomcat instances. EncryptInterceptor is a Tribes component that encrypts cluster communication traffic between nodes, preventing interception of session data transmitted across the cluster network.

CVE-2026-34486 is a missing encryption vulnerability (CWE-311) in EncryptInterceptor that allows the bypass of cluster communication encryption. The practical impact is deserialization and remote code execution on the Tribes communication port. CISA added this to the Known Exploited Vulnerabilities catalog on August 4, 2026, with a mandatory remediation deadline of August 7, 2026.

Technical Mechanism

The vulnerability is a regression introduced while patching CVE-2026-29146, a prior padding-oracle vulnerability in the EncryptInterceptor. The fix for that vulnerability modified error handling in the decryption path. The change moved validation logic in a way that causes EncryptInterceptor to fail open when it encounters malformed or unencrypted packets, rather than dropping them.

In the affected code path, when EncryptInterceptor receives a packet it cannot decrypt, instead of silently discarding the packet it passes the raw bytes onward for processing. These bytes reach the Tribes deserialization layer, which uses Java’s ObjectInputStream to deserialise cluster messages.

Java deserialisation of attacker-controlled bytes is exploitable when the target classpath contains deserialisation gadget chains. Enterprise Tomcat deployments commonly include libraries from which gadget chains are well-documented (Apache Commons Collections, Spring Framework, and others). An attacker targeting the Tribes port, typically TCP 4000 in default configurations, can send a crafted serialised object payload that executes arbitrary code on the Tomcat host.

The attack requires network access to the cluster communication port. In correctly configured environments, this port is bound to internal cluster network interfaces only, not internet-facing. However, in misconfigured or developer deployments, the port may be accessible from broader networks.

Real-World Exploitation Evidence

Public exploit code is available for CVE-2026-34486. CISA’s KEV addition confirms active exploitation in the wild. The combination of a publicly available exploit and CISA confirmation indicates opportunistic mass-scanning is likely ongoing against accessible Tomcat instances with clustering enabled.

The vulnerability affects three active major version lines of Tomcat (9.x, 10.x, 11.x), giving it broad exposure across the installed base. Tomcat deployments are common in enterprise Java application stacks and often run with broad network access in application tiers.

No specific threat actor attribution has been published at time of writing.

Impact Assessment

Successful exploitation grants remote code execution as the Tomcat service process. Typical deployment contexts mean this translates to:

• Access to application secrets, database connection strings, and configuration files within the Tomcat directory structure
• Ability to read, modify, or exfiltrate application data processed by the web applications running on the instance
• Lateral movement from the Tomcat host into backend infrastructure (databases, caches, internal APIs)
• Persistent backdoor deployment if the attacker achieves file write access to the web application directory

For clustered deployments, where multiple Tomcat instances share the Tribes communication network, successful exploitation of one node with access to the cluster port could enable further exploitation of co-located cluster members.

Affected Versions

Remediation Steps

1. Patch Tomcat to the fixed version for your version line. Fixed versions are 9.0.117, 10.1.54, and 11.0.21. Prioritise any Tomcat instance with clustering enabled and an accessible Tribes port.

2. Restrict the Tribes communication port. The Tribes/cluster communication port (default TCP 4000) should be bound only to cluster network interfaces and blocked at the firewall from any untrusted network. If your application tier runs behind a load balancer or application delivery controller, the cluster port should be inaccessible from the internet or from untrusted internal segments.

3. Audit clustering configuration. If Tomcat clustering is not actively used, review whether EncryptInterceptor and the cluster communication module are enabled unnecessarily. Disabled components cannot be exploited.

4. Verify Tribes bind address. In conf/server.xml, check the address attribute on the Receiver element within the Cluster configuration:

   <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
             address="192.168.1.x"  <!-- Should be a specific internal IP, not 0.0.0.0 -->
             port="4000" />

   address="auto" or address="0.0.0.0" binds to all interfaces, including public ones.

5. Audit for exploitation indicators. Review Tomcat access logs and system process logs around the Tribes port for unexpected connections or processes spawned from the Tomcat service.

Detection Guidance

Network-level detection:

Monitor for unexpected connection attempts to TCP port 4000 (default Tribes port) or the configured cluster communication port from sources outside the expected cluster network segment.

# Firewall/network log query
dst_port:4000 AND NOT src_ip:(known_cluster_ips) 
| stats count by src_ip 
| where count > 5

Host-based detection:

Look for unexpected child processes spawned by the Tomcat service process (typically java or catalina). Any processes executing shell commands, creating new files outside the Tomcat directory, or establishing outbound network connections not part of normal application traffic are suspicious.

Java deserialization detection (if using a Java agent or RASP):

Deserialization gadget chain execution typically involves reflection-based method invocation on classes like Runtime, ProcessBuilder, or equivalent. Java security managers or runtime application self-protection agents that monitor for suspicious reflection chains during deserialisation can detect exploitation attempts.

Log-based indicator:

Successful exploitation may not leave obvious Tomcat access log entries since Tribes communication does not pass through the standard HTTP request path. Focus on system-level process and file activity monitoring on Tomcat hosts rather than application logs.

Timeline

References

• NVD Entry — CVE-2026-34486
• Apache Tomcat Security Advisory (mailing list)
• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 26-04 Guidance