Zerodayhub

TL;DR — The Tomcat EncryptInterceptor bypass in CVE-2026-34486 makes an encryption layer fail open. Send an unencrypted cluster message, decryption fails, and the message gets forwarded anyway — into Java deserialization. It is on CISA KEV with an EPSS of 0.81. The good news is the scope is genuinely narrow: exactly three Tomcat versions, and only with clustering enabled.

What Is the Tomcat EncryptInterceptor Bypass?

Apache Tomcat can run as a cluster, replicating session data between nodes so a user does not get logged out when one server dies. That replication runs over the Tribes framework, which by default listens on TCP port 4000. Because those messages carry session data, Tomcat offers EncryptInterceptor: a component that wraps cluster traffic in pre-shared-key AES encryption.

The Tomcat EncryptInterceptor bypass means that protection can be skipped entirely. An attacker who can reach the cluster port sends a message in plaintext. The interceptor tries to decrypt it, fails, and — here is the bug — hands it up the chain regardless.

Before you go hunting: this is narrower than the headlines suggest. It affects exactly three upstream releases — 11.0.20, 10.1.53 and 9.0.116 — and only when clustering is enabled, EncryptInterceptor is configured, and the cluster port is reachable from wherever the attacker sits. Most Tomcat installations are not clustered at all. Having the class on disk is not the same as being exploitable.

How the Tomcat EncryptInterceptor Bypass Works

This is a regression, and an unusually instructive one. CVE-2026-34486 was introduced by the fix for an earlier flaw, CVE-2026-29146. During that fix the code was refactored, and the call passing the message up the interceptor chain ended up outside the try-catch block that handles decryption failure.

# The shape of the regression - illustrative, not source
try:
    message = decrypt(msg)          # throws when the message is not encrypted
except DecryptionError:
    log.error(...)                  # error is logged...
forward_to_next_interceptor(msg)    # ...but this still runs. Fail open.

One indentation level. That is the whole vulnerability. When decryption throws, the exception is caught and logged, and execution continues to the forwarding call as though nothing happened. The raw, unencrypted, attacker-controlled message proceeds down the chain.

Why that matters more than “cluster data is readable”: Tomcat cluster messages are Java serialized objects, and the receiving node deserializes them. Deserialization of untrusted input is one of the most reliable paths to remote code execution in the Java ecosystem. The encryption was not only providing confidentiality — it was the authentication check standing between the internet and a deserialization sink. Remove it and an unauthenticated attacker is feeding objects straight into that sink.

Formally the CVE is classified as missing encryption of sensitive data, which undersells it. The confidentiality loss is real, but the deserialization path is what earned this a place on KEV.

Reading the CVSS Score

The scored vector describes the encryption failure, not the downstream consequence — which is why 7.5 looks conservative next to a working RCE chain.

Note C:H with I:N and A:N. CVSS is scoring exactly what the advisory describes: sensitive data that should have been encrypted was not. It is not scoring “and then you deserialize whatever arrives.” This is a good example of why the vector is worth reading rather than sorting your backlog by the number alone.

The EPSS figure is the one to sit up for. At 0.81 this is in rare company — most CVEs we cover score in the low hundredths. Public exploit code plus a trivially network-reachable service will do that. Set against that, sensor telemetry currently shows confirmed in-the-wild status without a flood of observed attempts, which fits a vulnerability whose preconditions genuinely limit the target pool.

Active Exploitation of the Tomcat EncryptInterceptor Bypass

Apache fixed this back in April 2026. Public proof-of-concept code landed on GitHub around 23 July — multiple independent repositories, some demonstrating the full chain to code execution. CISA added it to the Known Exploited Vulnerabilities catalogue on 5 August.

The four-month gap between patch and KEV listing is the story. Anyone still exposed has been sitting on an available fix since spring. The publication of working exploit code is what converted a quiet advisory into an active threat — a pattern worth internalising, because it repeats constantly.

What to check and hunt for:

• Is clustering even enabled? Look for a <Cluster> element in server.xml. No clustering, no exposure.
• If it is, confirm your exact version. Only 11.0.20, 10.1.53 and 9.0.116 are affected — check vendor backports separately, as distributions may carry the flaw at other version numbers.
• Any connection to TCP 4000 or 5000 from outside your cluster subnet
• EncryptInterceptor decryption failure messages in your Tomcat logs — on a healthy cluster these should essentially never appear, which makes them a high-signal indicator
• Unexpected child processes spawned by the Tomcat JVM, the usual tell for successful deserialization attacks

Remediation & Mitigation: Patching Tomcat

Upgrade to 11.0.21, 10.1.54 or 9.0.117 or later, matching your branch. The fixes have been available since April 2026.

• Patch every cluster member. A single unpatched node still accepts the crafted messages, so a partial rollout leaves the door open.
• Firewall the cluster port. Tribes traffic should never be reachable from a general network, let alone the internet. Bind the receiver to a private interface and restrict TCP 4000 and 5000 to known cluster members.
• Verify after upgrading. Because this was a regression in a previous fix, confirm encryption is actually behaving — send an unencrypted message from a test host and check it is rejected rather than logged and forwarded.
• Question whether you need clustering. If session replication is not doing anything for you, turning it off removes the attack surface permanently.

Two lessons worth taking away, neither about Tomcat. The first is that patches introduce vulnerabilities too. This is the third regression-driven CVE we have covered in a week: a refactor during a security fix reopened the hole it was closing. Treat security patches as code changes that need review, not as unambiguously safe.

The second is that internal networks deserve the same discipline as public ones. Cluster traffic is trusted implicitly, carries serialized objects, and is often left wide open on the assumption that segmentation holds. When it does not, that trust becomes the vulnerability.

Related ZeroDayHub Coverage

The patch-regression pattern is having a moment. See also the N-able N-central authentication bypass, which was likewise an incomplete fix for an earlier flaw, and the Langflow unauthenticated RCE, another case of a component trusting input it should have rejected outright.

Sources & Further Reading

• CISA Known Exploited Vulnerabilities Catalog
• NVD — CVE-2026-34486
• Apache Tomcat security advisories
• The Hacker News — CISA flags Langflow, Tomcat and N-central flaws
• SentinelOne — Technical details and affected versions
• Penligent — On the real scope of the vulnerability
• KEVIntel — Exploitation status and EPSS