Advisory · CVE-2026-34486
Tomcat cluster encryption flaw invites unauthenticated RCE
An incomplete earlier fix lets attackers bypass Apache Tomcat's EncryptInterceptor, sending unencrypted cluster messages that reach Java deserialization and enable unauthenticated remote code execution.
- Vendor
- Apache
- Product
- Tomcat
- Identifier / CWE
- CVE-2026-34486
CWE-311 - Action timing
- Aug 25, 2026
Explain it like I’m five
Tomcat hired a bouncer to check IDs at the club door, but a paperwork error told the bouncer to wave people through even when their ID looks fake. Attackers walk in unencrypted and can take over the bar.
- 01Regression introduced
An incomplete fix for the earlier CVE-2026-29146 changes EncryptInterceptor behavior from drop-on-crypto-error to fail-open.
- 02Bypass attempt
An unauthenticated attacker sends an unencrypted message to the Tribes cluster receiver (TCP 4000 by default).
- 03Decryption fails silently
Decryption throws an exception that is logged, but the original unencrypted bytes are still forwarded to the next interceptor.
- 04Deserialization sink
The bytes reach an unfiltered Java deserialization path, and researchers have demonstrated this yields unauthenticated remote code execution.
What happened
On August 4, 2026, CISA added CVE-2026-34486 to the Known Exploited Vulnerabilities catalog, citing active exploitation of a missing-encryption flaw in Apache Tomcat. The vulnerability is rated high at CVSS 7.5.
Tomcat’s Tribes clustering stack uses an EncryptInterceptor that is supposed to authenticate and decrypt cluster messages and stop anything that fails those checks. An incomplete fix for the earlier CVE-2026-29146 moved a single control-flow statement so that when decryption fails, the raw unencrypted message is forwarded to the next interceptor anyway. The encryption layer becomes a gate that waves failures through instead of a hard stop.
The flaw affects Apache Tomcat 11.0.20, 10.1.53, and 9.0.116, fixed in 11.0.21, 10.1.54, and 9.0.117. The 8.5.x branch is not affected because it has no EncryptInterceptor. Public proof-of-concept analysis shows the forwarded bytes reach an unfiltered Java deserialization sink, producing unauthenticated remote code execution over the network with no credentials required. CISA notes the flaw can be chained with CVE-2025-24813, and threat reporting has described attackers deploying Java deserialization-based reverse shells against vulnerable servers.
What to do
- Inventory Tomcat deployments, including containers and cloud instances, and confirm whether Tribes clustering is enabled.
- Upgrade affected branches immediately: 11.0.20 to 11.0.21, 10.1.53 to 10.1.54, or 9.0.116 to 9.0.117.
- Where patching must wait, firewall the cluster communication ports (TCP 4000 by default) so only trusted cluster nodes can connect, using network segmentation and private paths.
- Review Tomcat and network logs for unexpected cluster traffic, repeated decryption failures, and suspicious outbound connections, which can indicate scanning or compromise.
- After upgrading, verify that encryption protections are functioning and confirm the running version.
Management note
This is a case where enabling encryption made things worse, because a broken gate looked like a real one. Any clustered Tomcat with the receiver port reachable from untrusted networks is an unauthenticated RCE target that attackers are already scanning for. Patching is the primary remediation, but the investigation matters too: exploitation leaves the attacker inside your application tier.