CVE-2026-34486 | Apache Tomcat: EncryptInterceptor Bypass to Remote Code Execution

This article examines a Missing Encryption of Sensitive Data vulnerability in Apache Tomcat, a widely deployed open-source Java servlet container. The flaw allows an attacker with network reachability to the Tribes receiver port to bypass the EncryptInterceptor protecting Tomcat’s cluster (Tribes) communication channel.

Tracked as CVE-2026-34486 with a CVSS 3.1 score of 7.5 (High), the flaw was introduced by the fix for the padding-oracle vulnerability CVE-2026-29146. When decryption of an incoming cluster message fails, the error is logged but the message is still delivered up the interceptor chain. An attacker who can reach the receiver does not need credentials or the cluster encryption key.

CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog on August 4, 2026. SOCRadar reports its use in a Taiwan-focused campaign deploying SNOWLIGHT through a CommonsCollections6 deserialization chain. Safe Security independently reproduced the bypass and command execution in an isolated Docker lab with the required gadget library on the Tomcat classpath.

2. Apache Tomcat Description

Apache Tomcat is an open-source web server and servlet container developed by the Apache Software Foundation under the Apache License 2.0. It implements the Jakarta Servlet, Jakarta Expression Language, and WebSocket specifications, and is widely deployed as a Java application server across embedded, enterprise, and government environments.

Tomcat’s optional clustering module (“Tribes”) provides session replication and message broadcast between nodes over a TCP receiver (default port 4000), and can be hardened with the EncryptInterceptor, which encrypts cluster traffic using a pre-shared symmetric key. This vulnerability bypasses the interceptor’s inbound checks.

3. Vulnerability Severity

The published CVSS vector assigns High confidentiality impact and no integrity or availability impact. The lab demonstrates an additional consequence: on a configuration with a usable deserialization gadget chain, the bypass can lead to unauthenticated remote code execution. CISA’s KEV listing confirms known exploitation; the campaign details below come from SOCRadar’s investigation.

Affected: Apache Tomcat 11.0.20 only

Affected: Apache Tomcat 10.1.53 only

Affected: Apache Tomcat 9.0.116 only

Condition: clustering enabled with the EncryptInterceptor configured on the Tribes channel, and the cluster receiver port (default TCP 4000) reachable by the attacker; the three affected releases are exactly those that shipped the CVE-2026-29146 fix (11.0.19 was never released; its changes first appeared publicly in 11.0.20)

Fixed: Apache Tomcat 11.0.21 / 10.1.54 / 9.0.117 (April 2026); Red Hat shipped corrected packages for RHEL 7–10 and JBoss Web Server via RHSA errata

Other upstream Apache releases are unaffected by this specific regression. Vendor-maintained packages may include backports; assess those packages against the vendor advisory. The CVE-2026-29146 fix that introduced this regression had already changed the default EncryptInterceptor algorithm from AES/CBC/PKCS5Padding to AES/GCM/NoPadding in the affected branches; later releases separately added replay protection. Tomcat 8.5, which reached end-of-life before the CVE-2026-29146 regression was introduced, is not affected.

5. Where is the vulnerability present?

The vulnerability is present in org.apache.catalina.tribes.group.interceptors.EncryptInterceptor.messageReceived(). The EncryptInterceptor sits in the Tribes channel interceptor stack and is responsible for decrypting inbound cluster messages and encrypting outbound ones using a pre-shared symmetric key.

In March 2026, the CVE-2026-29146 fix changed the default algorithm from AES/CBC/PKCS5Padding to AES/GCM/NoPadding and restructured the decrypt path. In the 9.0.x branch reproduced in this lab, that preceding change shipped as commit 0112ed22. The restructuring moved the call handing a message up the interceptor chain, super.messageReceived(msg), outside the try/catch protecting the decryption logic.

The result in the affected releases is a fail-open condition: when an incoming message cannot be decrypted, for example, because it is plaintext attacker traffic that fails AES/GCM processing, the interceptor logs encryptInterceptor.decrypt.failed and then passes the original, unverified bytes up the channel stack. The original bytes are forwarded downstream despite the decryption failure.

The interceptor delivers messages even when validation fails (Red Hat’s CWE-807 mapping). This bypasses inbound message-authenticity enforcement: an attacker who can reach the Tribes receiver port can inject crafted cluster-message bytes without knowing the pre-shared key. Because Tribes reconstructs received messages through Java serialization, the injected bytes reach a plain ObjectInputStream deserialization sink in GroupChannel.messageReceived() in the tested lab configuration, turning the encryption bypass into a pre-auth deserialization attack surface.

The CVE-2026-34486 correction moves super.messageReceived(msg) back inside the try block, so a message is delivered only after successful decryption. Apache lists branch-specific fix commits 776e12b3 for 9.0.x, 55f3eb91 for 10.1.x, and 1fab40cc for 11.0.x. The Apache advisory credits Bartlomiej Dmitruk of striga.ai as the finder.

An attacker with network reachability to a Tomcat cluster node’s receiver port can send a crafted, unencrypted Tribes message. On an affected release, decryption fails, the error is logged, and the message is still processed. If a deserialization gadget chain, such as CommonsCollections, is reachable on the node’s classpath, this yields unauthenticated remote code execution as the Tomcat JVM user, with no credentials and no knowledge of the cluster’s encryption key required.

SOCRadar reports a Taiwan-focused campaign deploying SNOWLIGHT, a malware family associated with China-nexus actors UNC5174/UNC6586. Its investigation describes recovered staging-server toolkits combining a CVE-2026-34486 exploit script, ysoserial and a CommonsCollections6 gadget chain built against apache-tomcat-9.0.116/lib. The reported chain targeted cluster port 4000 to deliver a SNOWLIGHT loader. This campaign evidence is separate from Safe Security’s isolated lab validation.

Even without a usable gadget chain, the bypass breaks the channel’s message-authenticity and integrity enforcement: plaintext, unauthenticated bytes can be accepted and delivered downstream despite EncryptInterceptor decryption failure. Depending on message type and downstream handlers, forged cluster traffic could corrupt replicated state or trigger other application effects. This flaw does not itself decrypt legitimate AES/GCM-protected traffic for a passive eavesdropper. The most severe observed chain is application-server compromise as the Tomcat JVM user, with broader host takeover, malware staging, and lateral movement depending on that service account’s privileges and the surrounding environment.

Upgrade Apache Tomcat to 11.0.21, 10.1.54, or 9.0.117 or later, which deliver the corrected EncryptInterceptor error handling. Messages are delivered only after successful decryption.

On Red Hat platforms, follow the product-specific CVE status and applicable RHSA errata. Red Hat lists affected RHEL package streams and JBoss Web Server 7.0 packages on RHEL 8, 9, and 10; it lists JBoss Web Server 6 as unaffected.

Restrict network access to the configured Tribes receiver and membership channels so that only genuine cluster peers can reach them. The receiver defaults to TCP 4000 and, with the default autoBind=100, can select the first available port from 4000 through 4099. Where multicast membership is used, its default heartbeat channel is UDP 45564 and should be restricted separately. The EncryptInterceptor must not be the only control protecting cluster traffic.

Audit the server classpath for deserialization gadget libraries (commons-collections and similar) reachable from the common classloader, and remove any that are not required; this reduces the available deserialization attack surface but does not guarantee a limit on future impact.

Monitor Tomcat logs for “encryptInterceptor.decrypt.failed” / “Failed to decrypt message” entries followed by continued message processing, and monitor for unexpected plaintext TCP sessions to cluster receiver ports. The vulnerable and patched nodes showed decrypt failures; only the vulnerable release showed messages subsequently reaching the deserializer.

Treat unexpected decrypt-failure bursts on 9.0.116, 10.1.53, or 11.0.20 as high-priority investigation signals. Correlate them with Unable to deserialize events, new processes, outbound connections, and filesystem changes. Successful gadget execution may not emit an Unable to deserialize error, so that count can understate exploit delivery.

8. Exploit Implementation

The September 29 lab run compared a two-node Tomcat 9.0.116 cluster with a Tomcat 9.0.117 control node. All three nodes used EncryptInterceptor with AES/GCM/NoPadding and the same shared key and gadget library. The fixed node had no configured replication peer; cluster membership was therefore different. The attacker and targets were on an isolated Docker network with no published host ports.

The lab placed commons-collections 3.2.1 in tomcat/lib and used a CommonsCollections6 gadget generated by ysoserial. A marker file was removed as session cleanup before testing and its absence was checked on the vulnerable node before the new injection. The screenshots below belong to this September 29 run.

Docker and Docker Compose

The two Tomcat 9.0.116 nodes, Tomcat 9.0.117 control, and attacker container

The configured EncryptInterceptor and gadget library in the lab

Python 3 injection helper and ysoserial in the attacker container

Step 1. Confirm the lab state, versions, encryption settings, and membership difference.

2. Establish the marker state, then send a plaintext Tribes frame to the vulnerable node. The lab helper /tools/inject.py wraps the payload bytes in Tribes framing over TCP.

Figure 1: The marker file is absent on the vulnerable node before this run’s injections. The prior session’s marker was removed before this check.

Figure 2: The new run records a decryption failure followed 16 milliseconds later by a deserialization error for the vulnerable node after the plaintext frame was submitted.

3. Generate the same CommonsCollections6 gadget family and submit it as the unencrypted message body.

Figure 3: The payload is sent to Tomcat 9.0.116 and the marker appears in that container. Together with the before check and the bypass logs, this supports command execution in the tested configuration.

4. Send the same payload to Tomcat 9.0.117 and inspect the marker and log result.

This run shows the marker absent before injection and present afterward on Tomcat 9.0.116, while the patched control lacks it after receiving the same payload. The command result is confined to the lab container; it does not establish broader host compromise.

Figure 5: Impact recap from Figure 3. This repeats the September 29 payload and marker result, not an additional run.