Tomcat cluster auth bypass shows why trusted-network assumptions fail

At a glance

What this is: This is a security analysis of CVE-2026-29146 in Apache Tomcat cluster communication, showing how forged replication messages can create fake identities and bypass authentication.

Why it matters: It matters because clustered application servers can turn identity trust assumptions into a server-wide compromise path when network reachability, session replication, and encryption are not authenticated together.

Context

Apache Tomcat clustering is meant to keep sessions and authentication state consistent across nodes, but that design only works when cluster peers are genuinely trusted and the replication channel is both authenticated and tightly constrained. In this case, the security problem is not just encrypted traffic, but unauthenticated peer acceptance inside a replication path that was assumed to be internal.

For IAM and NHI practitioners, the important detail is that authentication state can be manufactured upstream of application login logic. Once a forged identity is accepted into the cluster’s session state, downstream access controls no longer determine who gets in; the cluster has already made that decision.

This is a classic example of a network trust model outrunning the identity model. A control that looks strong at the transport layer can still fail if the application layer accepts session and role assertions without proving their origin.

Key questions

Q: What breaks when Tomcat cluster ports are reachable from untrusted networks?

A: The trust model breaks first. If a clustered Tomcat deployment accepts replication traffic from a network that is not tightly controlled, an attacker can try to inject or manipulate session state as if they were a legitimate node. That turns cluster communication into an identity control bypass path instead of a private coordination channel.

Q: Why does encrypted cluster traffic still fail to protect authentication state?

A: Because confidentiality is not the same as authenticity. If the replication channel leaks timing information or otherwise allows message forgery, an attacker can still create cluster messages that Tomcat accepts as trusted. In that case, encryption hides the payload but does not stop identity or session manipulation.

Q: What signs indicate a clustered application server is using unsafe trust assumptions?

A: Warning signs include session replication across broad networks, identity or role data flowing through cluster messages without separate validation, and security controls that rely on encryption alone. If the application treats replicated state as authoritative authentication output, the trust boundary is too weak.

Q: Should teams rely on cluster replication for authentication decisions?

A: No. Replication can move state between nodes, but it should not be the source of truth for who is authenticated or authorised. Authentication decisions need independent proof of origin, integrity, and policy enforcement, otherwise a compromised or forged cluster message can become a direct access control bypass.

Technical breakdown

Why unauthenticated cluster peers create a trust break

Tomcat clustering uses replication messages to keep session state aligned across nodes. When the cluster protocol assumes trusted peers by default, any host that can reach the cluster port can attempt to speak the replication language. That is a trust problem, not just a transport problem, because the application is willing to accept session data from a sender it has not authenticated. Encryption alone does not fix that if the channel still accepts messages from unverified peers or if the message format exposes enough structure for manipulation.

Practical implication: Treat cluster membership as an authenticated control plane, not as a network convenience.

How the EncryptInterceptor padding oracle enables message forgery

The EncryptInterceptor flaw is a timing-based padding oracle. In AES-CBC mode, decryption errors should not leak enough signal to help an attacker distinguish valid from invalid padding, but here the server’s response timing changes based on the decryption outcome. That gives an attacker a side channel to recover plaintext and then generate new ciphertext without the key. Because parts of the cluster message header remain in plaintext and affect processing flow, the attacker can shape the server’s handling of the payload and iterate toward valid forged messages.

Practical implication: Assume any timing-differentiated decryption path can become a message-forgery primitive.

How forged session state becomes authentication bypass

Once an attacker can inject a valid-looking cluster message, Tomcat’s authentication store becomes the target. In the SSO cache path, a fabricated session identifier can be mapped to arbitrary usernames and roles. In the DeltaManager path, the attacker can create a session and then inject a principal into it before login logic ever runs. In both cases, the application trusts replicated state as if it were local, legitimate authentication output. That breaks the boundary between session management and identity assurance.

Practical implication: Move trust decisions out of replicated session state unless the replication channel itself is strongly authenticated and integrity-protected.

Threat narrative

Attacker objective: The attacker wants to impersonate a fully privileged user inside Tomcat and gain control of the server and hosted applications.

1. Entry occurs when an attacker with network access reaches the Tomcat cluster receiver port on a deployment that exposes replication beyond a strictly trusted network.
2. Credential access is not the primary step here; instead, the attacker leverages a timing oracle to recover encrypted cluster message content and construct valid forged messages without the encryption key.
3. Escalation follows when the attacker injects fabricated session or principal data into Tomcat’s replicated authentication state, causing the server to accept a fake identity and permissions.
4. Impact is full application and server takeover because the forged identity bypasses login and enables privileged actions such as arbitrary code execution through the Manager application.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trusted-network assumptions are a broken identity control when replication can be reached remotely: Tomcat’s design assumed cluster peers were already inside a trusted boundary, so replication traffic could be treated as an internal truth source. That assumption fails when network reachability and cluster membership are not the same thing. The implication is that identity assertions must be validated at the replication boundary, not inherited from topology.

Replicated session state is not an authentication system: This flaw works because application servers often treat session replication as a neutral transport for identity data, even though it can carry the very decision that determines access. Once an attacker can write into that state, the server is no longer verifying identity, it is consuming it. Practitioners should treat replicated authentication state as a governed control surface, not a convenience layer.

Encryption without peer authentication creates trust debt: The article shows that confidential transport is insufficient when message origin is unverified and failure handling leaks timing differences. That combination gives an attacker a path from observation to forgery. For identity programmes, the lesson is that transport controls and trust controls are different layers, and one cannot substitute for the other.

Cluster communication needs explicit identity governance: This is not just a Tomcat issue, it is a pattern that appears whenever systems assume internal systems are inherently trustworthy. The named concept here is cluster trust collapse: when replication channels are allowed to assert identity state without proving sender authenticity, access control becomes downstream theatre. Practitioners should audit any design where session, role, or principal data crosses nodes unverified.

Access control can fail upstream of the login screen: The server never gets a chance to enforce the right answer if an attacker can pre-load the answer into replicated state. That breaks the common governance assumption that authentication decisions happen only at the user boundary. The practical conclusion is that identity assurance must extend into the state replication path whenever application servers share sessions.

What this signals

Cluster trust collapse: This vulnerability shows that replication channels need the same identity scrutiny as user-facing login flows. When a server accepts session and principal data from a peer without proving that peer’s authenticity, the cluster can become the place where access control is bypassed rather than enforced.

For practitioners, the governance question is not whether encryption exists, but whether the cluster can ever assert authentication state on its own. If it can, then the identity boundary sits in the wrong place and the programme is relying on topology to do the work of assurance.

For practitioners

• Map every exposed cluster receiver port Inventory Tomcat deployments where replication traffic is reachable beyond private LAN, VPN, or IPsec boundaries. Prioritise clusters that rely on EncryptInterceptor for security while still accepting messages from broad corporate or cloud networks.
• Verify authenticated encryption on replication paths Move clustered deployments away from unauthenticated AES-CBC replication patterns and confirm that any encrypted cluster channel also proves message origin and integrity, not just confidentiality.
• Treat replicated identity state as high-risk data Review whether SSO caches, session principals, and manager-level roles are being accepted from cluster messages without separate validation, and classify those objects as an identity trust boundary.
• Remove authentication dependence on trust-only clustering Where application control depends on clustered session state, ensure the cluster membership model cannot be used to inject principals, roles, or session identifiers into the authentication store.

Key takeaways

• Tomcat’s cluster replication model can turn into an authentication bypass when peer trust is assumed instead of proven.
• The article shows that forged messages can plant fake identities and roles, which means the server can accept attacker-controlled authentication state.
• The control that matters most is authenticated, tightly scoped cluster communication that never lets replication traffic become the source of identity truth.

Key terms

• Padding Oracle: A padding oracle is a side channel that reveals whether decrypted data has valid padding, even when the key is unknown. Attackers can use the signal to recover plaintext or forge ciphertext, especially when error handling or timing differences expose decryption outcomes.
• Database Replication: The process of copying database changes across multiple nodes so they remain aligned. For credential and identity services, replication is what makes failover possible, but it only works when schema changes, node membership, and data consistency are governed as one operational system.
• Authentication State: The current trust condition that tells the system whether a user can sign in and from which endpoint. In cross-device flows, authentication state must be managed separately from the device-bound passkey so that login, recovery, and update paths stay consistent.
• Trusted Network: A trusted network is a controlled group of participants who have been verified and accepted under shared rules. It gives people a way to trade, coordinate, or exchange value with less uncertainty because each member can be identified, recorded, and held accountable for actions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.