Critical Apache Tomcat Flaw Allows Full Server and Application Takeover (CVE-2026-29146)

Executive Summary

Apache Tomcat is one of the most widely deployed Java application servers in the world, helping run the backend of web applications across virtually every industry from healthcare and online banking portals to government services and enterprise SaaS platforms. Tens of thousands of organizations, such as JPMorgan Chase, Tesco, Starbucks, and Walmart, trust it to handle HTTP requests, manage user sessions, and enforce access controls for their most critical applications. A 2025 report estimates that 70% of Java developers use Tomcat as their application server, making it a high-value target.

The Oligo Security research team has uncovered a critical vulnerability in Tomcat’s cluster communication stack that leads to unauthenticated remote code execution (RCE). The vulnerability, tracked as CVE-2026-29146, stems from a cryptography flaw in the EncryptInterceptor used for cluster replication. The component exposes a timing-based padding oracle that allows an attacker with network access to the cluster port to decrypt and forge encrypted cluster messages without the encryption key, enabling session manipulation and the injection of malicious serialized payloads.

From a high level, here is how the vulnerability works:

• Tomcat’s cluster protocol does not authenticate peers by default and assumes nodes communicate over a trusted network. This enables an attacker to send messages directly to the cluster's internals as if they were a trusted node, enabling arbitrary manipulation of session and authentication data.
• The layer that encrypts cluster traffic has a flaw in how it handles decryption errors, leaking just enough timing information for an attacker to crack open captured traffic and forge new messages without a key. This means even deployments that turned on encryption for protection are exposed.
• By sending crafted messages into the cluster, an attacker can plant a fabricated user identity, complete with hand-picked roles and permissions, into Tomcat's authentication store. When a request arrives carrying that identity, Tomcat treats it as a fully authenticated, fully authorized user.

‍

The end result is that an attacker with network access and no credentials can gain control of a vulnerable Tomcat server and the applications running on it. 

CVE-2026-29146 was addressed in Tomcat 11.0.20 and corresponding releases, but the implemented fix was later shown to be flawed, resulting in a new vulnerability (CVE-2026-34486) that enabled bypass of the EncryptInterceptor. As a result, users are urged to upgrade to the latest version of Tomcat (11.0.21). 

Background: Tomcat Clustering and Security

Many production Tomcat deployments run in a clustered configuration, meaning multiple server instances work together as a single system. To maintain a seamless user experience, these nodes often share session state so users aren’t logged out if traffic shifts from one node to another. This setup is especially common in environments that prioritize uptime, such as healthcare, large-scale web platforms, and financial services.

The provided security guidance for users that run Tomcat in a clustered configuration follows:

Effectively, the cluster protocol is designed for secure, trusted networks, and should not be exposed to untrusted ones. Apache recommends private LANs, VPNs, or IPSEC as appropriate controls. 

Despite documented limitations, many operators treat EncryptInterceptor as a sort of security guarantee. Encrypting cluster traffic feels like a meaningful security control, and for teams managing complex infrastructure, enabling it and opening the cluster port to a broader corporate or cloud network is a reasonable-seeming tradeoff. 

The problem is that EncryptInterceptor is vulnerable in a way that makes the assumption dangerous.

Technical Findings

What Went Wrong

EncryptInterceptor uses AES-CBC encryption without authentication and is vulnerable to a padding oracle attack: a well-documented cryptographic technique that, in theory, can allow an attacker to decrypt encrypted traffic and forge valid messages without knowing the key. In this case, however, exploitation is not so straightforward. We identified a non-conventional trigger for the oracle, combining a subtle timing signal with the fact that only part of the payload is encrypted. This creates a unique and previously unrecognized attack path. 

Two design flaws work together to make this possible.

First, the Tribes message header, including flags that control how the server processes and responds to messages, is transmitted in plaintext and not authenticated before the encrypted payload. An attacker can freely manipulate these flags without any knowledge of the encryption key. One flag in particular forces the server to send its acknowledgment response only after it has finished processing the message rather than before.

This matters because of the second flaw. The server's two failure modes produce measurably different response times. In both cases the server ultimately returns the same acknowledgment response, but the time required to generate that response differs depending on whether padding validation succeeds or fails.

When decryption fails due to invalid padding, the server drops the message immediately. When padding happens to be valid, even if the decrypted content is unreadable, the server continues processing before ultimately failing, producing a slower response. By manipulating the plaintext header to activate the timing signal, then probing encrypted values and measuring response latency, an attacker can recover the plaintext byte-by-byte.

The same technique works in reverse. Once an attacker has mapped the encryption's response patterns, they can construct valid encrypted messages for any content they choose without the key. We confirmed the exploitability of this oracle by building a proof-of-concept that successfully forged a valid encrypted cluster message without knowing the encryption key.

What This Enables: Authentication Bypass and Full Server Takeover

With the ability to forge valid cluster messages, an attacker can target the components Tomcat uses to track who is authenticated. We found two distinct paths to full authentication bypass, each affecting a different part of Tomcat's authentication stack.

SSO Cache Poisoning

When ClusterSingleSignOn is configured, Tomcat replicates SSO session state across cluster nodes in a shared cache. An attacker can inject a forged cluster message that inserts a fabricated entry into this cache – a session ID of their choosing, mapped to a user identity with any username and any roles they want. Tomcat accepts and stores the entry without validation.

When the attacker sends an HTTP request carrying that session ID, Tomcat finds the fabricated entry and treats it as a legitimate authenticated user without checking any password or consulting any authentication system. This means that access controls for applications running on an impacted server are overridden. An attacker who assigns themselves manager-level roles gains full access to Tomcat's Manager application, and through it, the ability to deploy and execute arbitrary code on the server.

Session Principal Injection

This path does not require ClusterSingleSignOn at all, making it applicable to a much wider range of deployments. Any web application using DeltaManager, which is the default session manager for clustered Tomcat, is vulnerable.

An attacker can send two forged cluster messages: one to create a new session under an attacker-chosen session ID, and a second to inject a fabricated user identity with attacker-chosen roles into that session. When the attacker presents the session ID in an HTTP request, Tomcat reads the session, finds the cached identity, and treats it as authenticated before any login logic runs. The outcome is identical to the SSO path, leading to full access with no credentials required.

Why It Matters

Operators who enable EncryptInterceptor and expose the cluster port to a broader network do so most likely with some expectation of protection, even though Apache’s security guidance says otherwise. The padding oracle defeats the encryption entirely, and once an attacker can forge cluster messages, Tomcat's authentication model offers no further resistance. Fabricated identities are trusted unconditionally, and access controls across every application on the server can be bypassed at will.

TL;DR: EncryptInterceptor's encryption can be defeated without the key, allowing attackers to forge cluster messages. Those messages can be used to plant fake user identities with any permissions into Tomcat's authentication store, bypassing login and granting full server access, including the ability to deploy and execute arbitrary code.

Affected Versions and Mitigation

CVE-2026-29146 affects Tomcat deployments that meet the following conditions:

• Tomcat clustering is enabled
• The EncryptInterceptor is configured using the default AES/CBC/PKCS5Padding mode
• The cluster receiver port is reachable by an attacker

The issue has been fixed in Apache Tomcat 11.0.21 and corresponding versions.

If operators cannot upgrade immediately, the mitigation guidance below should be applied:

• Ensure the cluster receiver port is never exposed to untrusted networks
• Restrict cluster communication to private networks or VPNs
• If encryption is required, configure EncryptInterceptor to use AES/GCM/NoPadding, which provides authenticated encryption

Summary

Apache Tomcat’s cluster communication protocol was designed under the assumption that all participating nodes exist on a trusted network. CVE-2026-29146 demonstrates how dangerous that assumption can become when it meets modern deployment realities.

A combination of unauthenticated cluster messaging and a cryptographic flaw in the EncryptInterceptor allows attackers with network access to the cluster port to decrypt cluster traffic and forge trusted replication messages. Those messages can be used to inject arbitrary authentication state, allowing attackers to impersonate users, bypass access controls, and ultimately execute code on the server.

For defenders, the lesson is straightforward. Cluster communication channels must never be exposed to untrusted networks, even when encryption is enabled. Organizations running clustered Tomcat deployments should apply the latest patches and ensure that cluster ports remain strictly limited to trusted infrastructure.

If you need assistance assessing your Tomcat deployments or identifying potentially malicious activity related to these issues, contact our research team at info@oligosecurity.io.