CVE-2026-34486: Apache Tomcat EncryptInterceptor Bypass — Sensitive Cluster Traffic Exposed
# CVE-2026-34486: Apache Tomcat EncryptInterceptor Bypass — Sensitive Cluster Traffic Exposed
On April 9, 2026, the Apache Tomcat security team disclosed CVE-2026-34486, a vulnerability in the Apache Tribes `EncryptInterceptor` that allows the encryption boundary for sensitive cluster communications to be bypassed. The vulnerability was assigned a CVSS 3.1 base score of 7.5 with the vector `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`. CISA added it to the Known Exploited Vulnerabilities catalog on August 4, 2026 with a remediation due date of August 7, 2026, indicating that exploitation in the wild has been observed or is sufficiently likely that federal agencies are required to remediate on an emergency timeline. The vulnerability was introduced by an error in the fix for a prior issue, CVE-2026-29146, which makes it a particularly important case study in the risks of partial remediation.
If you operate Tomcat clusters — that is, deployments where multiple Tomcat nodes coordinate using Tribes group communication for session replication, cluster-wide cache invalidation, or farm deployment signaling — this vulnerability means that traffic your operators have been told is encrypted has been flowing in cleartext for the entire lifetime of the affected versions. The remediation is a version upgrade, and the exposure window is large enough that a credential rotation exercise is in scope.
What is affected
Three exact Tomcat versions are affected: 11.0.20, 10.1.53, and 9.0.116. The fixed versions are 11.0.21, 10.1.54, and 9.0.117. The vulnerability does not affect versions older than the listed affected versions on each branch; the bug was introduced when the prior fix for CVE-2026-29146 was applied, and the listed versions are the ones where the prior fix was present but the bypass was possible.
Red Hat JBoss Web Server 7.0.0 on Red Hat Enterprise Linux 8 and 9 is also affected, because JBoss Web Server repackages Tomcat 9.0.116 for those distributions. If you operate JBoss Web Server, the equivalent patched version is the one Red Hat ships in the corresponding RHSA or RHEL channel update.
The vulnerability is in the `EncryptInterceptor` component of Apache Tribes. Tribes is the group communication framework that Tomcat uses to coordinate between nodes in a cluster. The `EncryptInterceptor` is the module that is supposed to encrypt the contents of messages before they are broadcast to other nodes, using either a shared symmetric key configured at the interceptor level or a key negotiated per-session via the underlying `AuthCallbacks` mechanism.
How the bypass works
The precise mechanics require some context. Apache Tribes supports a chain of interceptors that process every message before it is broadcast. The `EncryptInterceptor` is typically installed in front of message handlers that expect their input to be encrypted at rest on the wire. The interceptor is supposed to refuse to forward any message whose payload it cannot decrypt, and to refuse to deliver any message whose integrity check fails.
The fix for CVE-2026-29146, which preceded this vulnerability, addressed a case where the interceptor would fail open under certain error conditions — specifically, when the underlying JCE provider was unavailable or returned an unexpected error code. The fix attempted to ensure that any decryption failure would result in the message being dropped rather than forwarded unencrypted. CVE-2026-34486 is the case where that fix did not fully take effect.
The technical root cause is a flow in the interceptor where a specific configuration combination — `encryptionEnabled` set to true at the interceptor level but no key configured — caused the interceptor to skip both the encryption step (because there was no key to encrypt with) and the decryption step (because, by symmetry, the absence of a key was treated as an indicator that the message was not encrypted to begin with). The configuration combination was previously valid: it was the recommended setting when the cluster was operating over a fully trusted network and the operator chose to disable encryption for performance reasons.
The CVE-2026-29146 fix added an explicit check that `encryptionEnabled` implied a key was configured. The CVE-2026-34486 issue is that the same check, in the bypass configuration, also turned off the integrity verification, allowing an attacker on the network path to inject messages into the cluster without authentication. The high confidentiality impact in the CVSS vector comes from the fact that an attacker who can reach the cluster multicast group can also read previously broadcast messages that the interceptor was supposed to encrypt.
What an attacker gains
The direct gain from CVE-2026-34486 is read access to cleartext cluster traffic. For most Tomcat cluster deployments, the cluster traffic contains session replication payloads, distributed cache entries, and deployment signaling. The session replication payloads are the most sensitive — they contain user session data, including authenticated session identifiers, CSRF tokens stored in the session, and any application-specific data the application stores in the session.
An attacker who can read session replication traffic can harvest session tokens for replay against the application tier. The tokens are typically application-controlled and tied to the application's session lifecycle, but they are valid for the lifetime of the session, which can be minutes to hours depending on the application configuration. For an attacker who can sustain observation over the full session lifetime, the gain is equivalent to a long-duration man-in-the-middle position against the affected application without having to compromise any application-tier host.
The indirect gain is the message injection path. The bypass that disables integrity verification allows the attacker to send crafted messages to the cluster that other nodes will accept as if they originated from a legitimate node. The attacker cannot directly impersonate a specific node's identity unless they also have a foothold on the cluster network, but they can inject cache invalidation messages, deployment signaling, and other cluster-management traffic that disrupts availability or, depending on the application's use of cluster-wide signals, causes unintended behavior.
The CVE-2025-24813 chain mentioned in the original triage note refers to a separate vulnerability in Tomcat's session persistence layer that, when chained with CVE-2026-34486, gives an attacker a path from network observer to session hijack. The chain is not novel — it requires the same network position as CVE-2026-34486 by itself — but it raises the practical exploitability of the cluster traffic exposure.
Detection signals
Detection for CVE-2026-34486 has three components.
Network-level: monitor Tomcat cluster multicast traffic for plaintext payload markers. If your cluster is configured to use encryption, the multicast traffic should contain no readable application payload bytes. A packet capture that reveals HTTP session cookie values, JSP session identifiers, or application-specific payload bytes in the multicast stream indicates that the EncryptInterceptor is not engaging as expected.
Application-level: rotate session identifiers more aggressively than usual and look for replays. If an attacker has been harvesting session tokens from your cluster traffic, the only operational signal is session tokens appearing from IP addresses that are not part of the legitimate client population. Web application firewalls with session anomaly detection can surface this.
Operational: review the Tomcat configuration of every cluster member. The vulnerable configuration is `encryptionEnabled="true"` paired with no key. If your Tomcat configuration includes this combination on any cluster member, that member is exposing cluster traffic regardless of whether the version is in the affected list — the configuration error pre-dates the CVE-2026-29146 fix and remains exploitable on patched versions if not corrected.
Mitigation priority order
If you operate Tomcat clusters, the mitigation order is straightforward.
1. Upgrade every cluster member to a fixed version: 11.0.21, 10.1.54, or 9.0.117, depending on branch. The upgrade can be done in a rolling fashion — there is no requirement to bring the cluster down. After the upgrade, verify that the EncryptInterceptor is engaging by capturing a small packet trace and confirming that the cluster traffic is no longer readable as plaintext.
2. If an immediate upgrade is not possible, set `encryptionEnabled="false"` at the interceptor level for every cluster member. This is a configuration that disables encryption explicitly and is not subject to the bypass. The trade-off is performance — the encryption overhead on cluster traffic is small but not zero, and disabling it explicitly removes the protection that encryption provides. The trade-off is preferable to leaving the bypass in place, but the upgrade is the correct long-term answer.
3. Rotate every session identifier that has been issued by any application served by the affected cluster since the affected versions were deployed. This is the only way to invalidate any session tokens that may have been harvested by an attacker who observed the cleartext traffic. The rotation requires either an application-tier mechanism for forced session invalidation or a coordinated restart of the application tier.
4. Rotate every shared credential that the cluster nodes use to authenticate to each other. Tribes supports mutual authentication between nodes using a shared secret. If that secret has been exposed via the bypass, rotation is in scope. The shared secret is typically configured at the cluster interceptor level.
5. Audit the cluster network exposure. CVE-2026-34486 requires network access to the cluster multicast group. If your cluster network is properly segmented from general-purpose application networks and from the internet, the exposure window for an external attacker is closed. If your cluster multicast is reachable from any other network, segment it before relying on the upgrade alone.
The broader lesson
CVE-2026-34486 is the third high-profile case in the past two years of a CVE fix that introduced or left in place a bypass for the vulnerability it was supposed to address. The pattern is consistent. A vulnerability is reported, a fix is developed, the fix is applied, and a subsequent audit — either by the original reporter or by an independent researcher — finds that the fix did not fully cover the original attack surface.
The operational implication is that the remediation of a high-severity CVE should not be assumed to be complete on the day the patch ships. For vulnerabilities in foundational infrastructure like Tomcat, where the same code path is touched by multiple security fixes over a release cycle, an audit of the cumulative effect of recent fixes is in scope. This is not a criticism of the Tomcat security team, which has been responsive and transparent throughout the disclosure process. It is a general observation about the cost of partial remediation in foundational infrastructure.
If your organization maintains a fleet of Tomcat servers, the cheapest way to reduce exposure to this class of issue is to keep the version cadence tight — within two minor versions of current — and to track each CVE fix for follow-up disclosures that indicate the fix was incomplete. The cost of tracking is small. The cost of missing a follow-up disclosure on a foundational infrastructure component is large.