Tomcat cluster encryption bypass lets attackers run code, CISA lists it

• Affected: Apache Tomcat 11.0.20, 10.1.53 and 9.0.116, when clustering uses the EncryptInterceptor.
• Fixed in: 11.0.21, 10.1.54 and 9.0.117.
• Exploited? Yes. In CISA KEV since 4 August 2026 (checked 27 October 2026).
• Do this now: upgrade, and firewall the cluster port to cluster members only.

What happened

An attacker who can reach a Tomcat cluster port can get unencrypted messages past its encryption layer. Tomcat then deserializes them. With a suitable gadget library on the classpath, that means remote code execution.

Apache disclosed CVE-2026-34486 on 9 April 2026. The fixed releases were already out. Apache rates it Important.

The bug sits in the EncryptInterceptor of Tomcat's Tribes clustering. It encrypts session replication traffic between nodes with a shared key. It is meant to drop anything that does not decrypt.

The flaw is a regression. Apache's fix for CVE-2026-29146, a padding oracle in the same interceptor, moved one line in the receive path. After that change, a failed decryption was logged and the original message was passed on anyway.

So the answer to the headline question is yes. A failed decryption check did let messages through, in these three releases only.

Who is affected

Only three releases carry the bug: 11.0.20, 10.1.53 and 9.0.116. Earlier releases keep the old behavior, which drops undecryptable messages. They may still need the CVE-2026-29146 fix.

Exposure needs a setup that is not the default:

• Tomcat runs as a cluster (Tribes, usually SimpleTcpCluster).
• The EncryptInterceptor is configured in that cluster.
• An attacker can reach the cluster receiver port. It is 4000 by default.

Am I affected? Check your version first. Then search server.xml for EncryptInterceptor. If neither matches, this CVE does not apply.

Code execution needs one more thing. A deserialization gadget chain must be on the classpath. Tomcat does not ship one. Applications often bundle libraries that provide one.

Red Hat ships fixed tomcat and tomcat9 packages for RHEL. Check your distribution's advisory if you use packaged Tomcat.

What is confirmed

Apache's advisory names the affected and fixed versions. The fix commit restores the old logic. Messages that fail decryption are dropped again.

The researcher, Bartłomiej Dmitruk of Striga, reported it on 26 March 2026. Striga's write-up of 13 April 2026 explains the chain. The receiver accepts connections from any host. Payloads reach a Java deserializer that has no class filter.

Striga published a PoC repository on 11 May 2026. We read it and did not run it. It is a lab setup. It adds a gadget library to Tomcat 11.0.20 before sending the payload.

CISA added the CVE to its Known Exploited Vulnerabilities catalog on 4 August 2026. Federal agencies had until 7 August 2026 to act. CISA notes it can be chained with CVE-2025-24813, an older Tomcat partial PUT flaw.

SOCRadar reported on 31 July 2026 that one operator used this CVE against Tomcat hosts in Taiwan in late April 2026. It counted 37 targeted hosts and two confirmed compromises. The payload delivered SNOWLIGHT malware.

What is not confirmed

Apache published no CVSS score. The 7.5 (High) score comes from CISA's enrichment and Red Hat. It rates confidentiality only, not code execution. Apache's own record files it as CWE-311, missing encryption.

That gap matters. The advisory text does not say "remote code execution". The RCE claim comes from Striga's research and from SOCRadar's attack data, and it depends on a gadget library.

We have no count of exposed Tomcat clusters. Cluster ports are rarely meant to face the internet. No ransomware use is known, per CISA.

SOCRadar's attribution to China-nexus access brokers is its own assessment. We did not verify it.

What to do

1. Upgrade to Tomcat 11.0.21, 10.1.54 or 9.0.117, or any later release.
2. Restrict the cluster receiver port to cluster members with a firewall. Apache's clustering docs say a cluster must run on a secure, trusted network.
3. Remove unused libraries that offer deserialization gadgets from the classpath.
4. Review logs from April 2026 onward for repeated "Failed to decrypt message" errors from unknown hosts.
5. On 11.0.20, 10.1.53 or 9.0.116 with an exposed port, treat the host as possibly compromised and investigate.

Our take

This is a security fix that created a worse bug. A padding oracle fix turned a fail-closed check into a fail-open one. The send path still failed closed, which made the gap easy to miss.

The deeper problem is Java deserialization of network input. We saw the same pattern in the Apache Camel deserialization flaws. Network filtering is the control that holds when a crypto layer fails.