Exploit for Reliance on Untrusted Inputs in a Security Decision in Apache Tomcat CVE-2026-29146 CVE-2026-34486

## https://sploitus.com/exploit?id=9E374C4D-62B4-5A2E-934A-F7CA5E58C7AE
# CVE-2026-34486: Apache Tomcat EncryptInterceptor Bypass

| Field | Value |
|-------|-------|
| **CVE** | CVE-2026-34486 |
| **CVSS** | 7.5 HIGH |
| **Type** | Missing Encryption of Sensitive Data |
| **Component** | Apache Tomcat Cluster EncryptInterceptor |
| **Published** | 2026 |

## Overview

CVE-2026-34486 is a regression introduced by the incomplete fix for [CVE-2026-29146](https://vulners.com/cve/CVE-2026-29146). In Apache Tomcat's cluster replication, the `EncryptInterceptor` is responsible for encrypting and authenticating cluster messages. A refactoring in the fix for CVE-2026-29146 inadvertently moved the `super.messageReceived(msg)` call outside the try-catch block that handles decryption failures. As a result, when a message fails decryption (i.e., it is received in plaintext but the interceptor expects encrypted data), the raw unencrypted message is still passed up the handler chain instead of being discarded.

## Technical Details

### Code Flow Regression

The `EncryptInterceptor.messageReceived()` method is invoked when a cluster message arrives. The expected flow is:

1. Receive raw message bytes
2. Decrypt and validate the message (inside a try-catch)
3. If decryption succeeds, call `super.messageReceived(msg)` to forward the decrypted message
4. If decryption fails, discard the message (or log an error)

In the vulnerable versions, the decryption/validation logic remains wrapped in a try-catch, but the call chain was restructured so that `super.messageReceived(msg)` executes **outside** the try-catch block that guards the decryption. The variable `msg` is declared before the try-catch and assigned within it. When decryption throws an exception, `msg` retains its initial (unencrypted/raw) value, and the catch block only logs the error — it does not return early. Execution continues to `super.messageReceived(msg)` with the unprocessed raw data.

This means an attacker who can reach the Tomcat cluster port can inject arbitrary unencrypted messages that the interceptor will accept and process.

### Simplified Pseudocode of the Bug

```java
public void messageReceived(Message msg) {
    // msg arrives raw
    try {
        // decrypt and populate msg fields
        decrypt(msg);
    } catch (Exception e) {
        log.error("Decryption failed", e);
        // BUG: no return statement here
    }
    // msg is still the original unencrypted object when catch is hit
    super.messageReceived(msg); // outside try-catch → passes raw data
}
```

The fix must ensure that either:
- `super.messageReceived(msg)` is called only inside the try block after successful decryption, or
- The catch block returns immediately so the unencrypted message is never forwarded.

## Affected Versions

| Product | Versions |
|---------|----------|
| Apache Tomcat 11 | 11.0.20 |
| Apache Tomcat 10 | 10.1.53 |
| Apache Tomcat 9  | 9.0.116 |

## Reproduction

### Prerequisites

- A vulnerable Tomcat instance with cluster replication enabled using the `EncryptInterceptor`
- Network access to the Tomcat cluster port (commonly 4000 or 5000, configured via ``)
- Python 3.6+

### Steps

1. Identify a Tomcat cluster member with the `EncryptInterceptor` configured in `server.xml`.
2. Determine the cluster receiver address and port.
3. Run the exploit script to send a crafted raw cluster message.
4. Observe that the message is accepted and logged by the receiver, bypassing encryption validation.

## PoC

The `exploit.py` script in this directory demonstrates the bypass. It constructs a minimal Tomcat cluster message (based on the `ClusterMessage` serialization format) and sends it directly to the receiver port without any encryption. A vulnerable interceptor will accept and forward the message despite the missing encryption.

## Mitigation

Upgrade to a patched version of Apache Tomcat:

| Product | Patched Version |
|---------|-----------------|
| Apache Tomcat 11 | 11.0.21+ |
| Apache Tomcat 10 | 10.1.54+ |
| Apache Tomcat 9  | 9.0.117+ |

If upgrading immediately is not possible, restrict network access to the Tomcat cluster port to trusted hosts only (e.g., via firewall rules or binding the receiver to a loopback or private interface).

## References

- [CVE-2026-34486](https://vulners.com/cve/CVE-2026-34486)
- [CVE-2026-29146](https://vulners.com/cve/CVE-2026-29146) (original vulnerability)
- [Apache Tomcat Security Advisories](https://tomcat.apache.org/security.html)
- [EncryptInterceptor Documentation](https://tomcat.apache.org/tomcat-10.1-doc/cluster-howto.html)