Tomcat CVE-2026-34486: Cluster EncryptInterceptor Bypass

What to do

1. Check the version on every Tomcat node (bin/version.sh) and look for exactly 11.0.20, 10.1.53 or 9.0.116.
2. Check conf/server.xml for a <Cluster> element and an EncryptInterceptor; if neither is present, this CVE does not apply.
3. Upgrade affected nodes to the current release on their branch (11.0.27, 10.1.61 or 9.0.123), not just the minimum fix.
4. Firewall the Tribes receiver port (4000-4100 by default) so only the other cluster members can reach it, including Kubernetes NetworkPolicies.
5. If you do not need session replication, remove the <Cluster> element entirely.

How to check if you are affected or compromised

• Search catalina logs on clustered nodes for 'Failed to decrypt message' SEVERE entries, which can indicate unencrypted messages injected into the cluster port.
• Review connections to the cluster receiver port from addresses that are not cluster members.
• Check hosts for the SOCRadar-reported indicators: connections to 130.94.30.168:8080, a /tmp/log_de.log file, or a process spoofing the name [kworker/0:2].
• Look for unexpected JSP files such as tunnel.jsp or tunnels.jsp in webapps, which the same operator used for tunneling.

What happened#

On April 9, 2026, the Apache Tomcat team announced CVE-2026-34486, rated Important. A mistake in the fix for an earlier bug, CVE-2026-29146 (a padding-oracle weakness in the cluster EncryptInterceptor), allowed the EncryptInterceptor to be bypassed. Bartlomiej Dmitruk of striga.ai reported it on March 26. The CISA-ADP and Red Hat scores on the NVD entry are CVSS 3.1 7.5.

The EncryptInterceptor belongs to Tribes, the messaging layer Tomcat uses to replicate HTTP sessions between cluster nodes. In the affected releases, a message that failed decryption was logged as an error and then passed along anyway, so the encryption check failed open. Replication messages are serialized Java objects. HeroDevs and other analyses say this lets an unauthenticated attacker who can reach the cluster port get code execution through Java deserialization, provided a usable gadget library is on the classpath. They describe the 7.5 score as a floor.

CISA added the CVE to the KEV catalog on August 4, 2026, with an August 7 deadline. The entry says it "can be chained with CVE-2025-24813", the 2025 partial-PUT bug covered in our separate brief.

Who is affected#

Exactly three releases are affected: 11.0.20, 10.1.53 and 9.0.116, the only builds that shipped the faulty fix. Fixes are in 11.0.21, 10.1.54 and 9.0.117. Earlier releases predate the regression, and Tomcat 8.5 is not affected. Red Hat lists JBoss Web Server and RHEL Tomcat packages, so check vendor-packaged builds as well as Apache tarballs and container images.

Being on one of those versions is not enough on its own. All of the following must also be true:

• Tribes clustering is enabled. It is off by default and requires a <Cluster> element in server.xml.
• The EncryptInterceptor is configured. It is not part of Tomcat's default cluster configuration.
• An attacker can reach the receiver port. By default that is the first free port from 4000 to 4100, bound to a real interface rather than localhost.

The teams that use the EncryptInterceptor tend to be the ones replicating sessions across networks they do not fully control, such as cloud VPCs or shared Kubernetes namespaces.

Do you really need to act?#

Most Tomcat users do not. A single, non-clustered Tomcat behind a load balancer has no Tribes listener at all. If you do run a cluster, the version window is narrow, and any regular patching since April has already moved you past it.

For teams that match every condition, this is serious and already exploited. SOCRadar analyzed a China-nexus operator's staging server and found CVE-2026-34486 used against 37 Taiwanese hosts around April 24 to 29, 2026, with two confirmed compromises that delivered the SNOWLIGHT loader. The same operator separately used CVE-2025-24813 against Taiwanese targets on May 8. No public source we found explains how the two bugs are chained in a single attack, so read CISA's wording as "used by the same actors" unless more detail appears.

One point applies whatever your version. Apache's clustering guide says the cluster "is written on the basis that a secure, trusted network is used" and that running it on an untrusted network is not safe. A cluster port reachable from untrusted hosts is a problem on any release, and the EncryptInterceptor has had further fixes since April, listed on the Tomcat 9 security page.

What to do now#

1. Run $CATALINA_HOME/bin/version.sh on each node and note any node on 11.0.20, 10.1.53 or 9.0.116.
2. Run grep -nE 'Cluster|EncryptInterceptor' $CATALINA_BASE/conf/server.xml. No match means this CVE does not apply to that node.
3. Upgrade affected nodes to 11.0.27, 10.1.61 or 9.0.123, the current releases, and rebuild container images that pin the old versions.
4. Restrict the receiver port to cluster members only. Check what is listening with ss -ltnp | grep -E ':40[0-9]{2}', and in Kubernetes add a NetworkPolicy so other pods cannot reach it.
5. If you do not actually need session replication, remove the <Cluster> element.

How to tell if you were hit#

On clustered nodes running an affected version, search the Catalina logs for SEVERE "Failed to decrypt message" entries. HeroDevs singles out one pattern worth an alert: a lone decrypt failure on a clustered node with no other error around it. Review connections to the receiver port from addresses that are not cluster members. SOCRadar's indicators for this campaign include connections to 130.94.30.168:8080, a /tmp/log_de.log file, a process masquerading as [kworker/0:2], and JSP tunnel files named tunnel.jsp or tunnels.jsp. If you find any of these, isolate the node, preserve logs and memory, and rotate every secret the Tomcat process could read.

Timeline#

• Mar 26, 2026 — Issue reported to the Tomcat security team.
• Apr 9, 2026 — Apache publishes CVE-2026-34486. Fixed releases 11.0.21, 10.1.54 and 9.0.117 are available.
• Apr 24–29, 2026 — SOCRadar dates exploitation against Taiwanese hosts to this window.
• Jul 31, 2026 — SOCRadar publishes its SNOWLIGHT campaign analysis.
• Aug 4, 2026 — CISA adds CVE-2026-34486 to KEV.
• Aug 7, 2026 — CISA remediation deadline for federal agencies.

Vulnerability records

• CVE-2026-34486 · KEV 2026-08-04 · Missing Encryption of Sensitive Data vulnerability in Apache Tomcat due to the fix for CVE-2026-29146 allowing the bypass of the EncryptInterceptor.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Apache Tomcat — [SECURITY] CVE-2026-34486 announcement lists.apache.org
2. Apache Tomcat — Apache Tomcat 9.x vulnerabilities tomcat.apache.org
3. CVE record — CVE-2026-34486 cve.org
4. NVD — CVE-2026-34486 nvd.nist.gov
5. CISA — Known Exploited Vulnerabilities: CVE-2026-34486 cisa.gov
6. Apache Tomcat — Clustering/Session Replication How-To tomcat.apache.org
7. SOCRadar — Tracing SNOWLIGHT: A China-Nexus Campaign Against Government Infrastructure socradar.io
8. HeroDevs — CVE-2026-34486: Apache Tomcat EncryptInterceptor Fail-Open Bypass herodevs.com