Tomcat logged the decryption failure, then forwarded the message anyway

Apache Tomcat's vulnerability pages carry one of the shortest advisories the project has published this year. Under the heading "Important: The fix for CVE-2026-29146 allowed the bypass of the EncryptInterceptor", the entry for CVE-2026-34486 says, in its entirety:

An error in the fix for CVE-2026-29146 allowed the EncryptInterceptor to be bypassed.

Apache Tomcat security pages, entry for CVE-2026-34486

It was reported to the Tomcat security team on 26 March 2026 and made public on 9 April 2026. On 4 August it turned up in CISA's Known Exploited Vulnerabilities catalog. What the advisory does not explain, the linked commit does.

One line, moved

The 11.0.x fix is commit 1fab40cc, authored by Mark Thomas on 30 March 2026 with the message "Better error handling - partial revert of 6d955cc". It touches two files and changes four lines. The substantive part is in java/org/apache/catalina/tribes/group/interceptors/EncryptInterceptor.java:

             xbb.clear();
             xbb.append(data, 0, data.length);
 
+            super.messageReceived(msg);
         } catch (GeneralSecurityException gse) {
             log.error(sm.getString("encryptInterceptor.decrypt.failed"), gse);
         }
-        super.messageReceived(msg);
     }

Before the fix, super.messageReceived(msg) sat outside the try block. A cluster message that failed to decrypt threw GeneralSecurityException, was logged at error level — and was then passed up the interceptor chain anyway. The encryption layer recorded its own failure and delivered the message regardless. That is the bypass: an attacker who cannot produce a correctly encrypted message does not need to, because the failure path forwards it too.

Tomcat's changelog entry for the fix is equally terse: "Better error handling for the EncryptInterceptor. (markt)".

The commit being partially reverted, 6d955cc, was itself a security fix — CVE-2026-29146, "EncryptInterceptor vulnerable to padding oracle attack by default", where "The EncryptInterceptor used CBC by default which is vulnerable to a padding Oracle attack." Both CVEs went public on the same day.

One release per branch

Apache lists the affected versions as 11.0.20, 10.1.53 and 9.0.116 — a single release on each branch. The repairs shipped in 11.0.21 (dated 2026-04-04), 10.1.54 and 9.0.117, via branch-specific commits 1fab40cc, 55f3eb91 and 776e12b3.

Scope is narrower than "Tomcat". The EncryptInterceptor is a Tribes cluster component that has to be configured explicitly, and Tomcat's own documentation describes it as adding "encryption to the channel messages carrying session data between nodes". A standalone Tomcat never loads this code path. A clustered Tomcat that never configured the interceptor has a different problem — unencrypted cluster traffic — but not this one.

Why it resurfaced in August

CISA added CVE-2026-34486 to the KEV catalog on 2026-08-04, four months after the patch, with a due date of 2026-08-07 and the required action "Mitigation per vendor instructions, compliance with CISA BOD 26-04 guidance required". Known ransomware campaign use is listed as "Unknown". The catalog entry adds a pointer Apache's does not:

"Apache Tomcat contains a missing encryption of sensitive data vulnerability that allows the bypass of the EncryptInterceptor. This vulnerability can be chained with CVE‐2025‐24813."

CISA does not spell out the chain, and neither will we. CVE-2025-24813 is Tomcat's partial-PUT flaw from March 2025, whose remote-code-execution path required, per Apache's own advisory, that the "application was using Tomcat's file based session persistence with the default storage location" and "included a library that may be leveraged in a deserialization attack". Serialized session data is exactly what the EncryptInterceptor is there to protect in transit.

Remediation

Upgrade to 9.0.117, 10.1.54 or 11.0.21 or later, per branch. There is no configuration workaround: the fail-open is in the interceptor's error handling, so the only options are a patched release or removing the interceptor — and removing it leaves session replication in the clear, which is worse.

Two checks worth running while you are in there. First, confirm whether your server.xml cluster channel actually declares the EncryptInterceptor; if it does not, this CVE is not yours, but the plaintext one is. Second, cluster membership and message ports should not be reachable outside the cluster's own segment regardless of which Tomcat you run — the interceptor is defense in depth, not the perimeter.

The KEV catalog stood at version 2026.08.10 with 1,662 entries when we read it.

Primary sources: Apache Tomcat 11 vulnerabilities, Apache Tomcat 10 vulnerabilities, Apache Tomcat 9 vulnerabilities, apache/tomcat commit 1fab40cc, Tomcat 11 cluster interceptor documentation, CISA Known Exploited Vulnerabilities catalog, read 2026-08-11.