The fix that switched the encryption off: CVE-2026-34486 in Apache Tomcat

What the component actually does

When a Java application runs on several Tomcat servers behind a load balancer, the nodes have to exchange user sessions: if your shopping cart, your authentication or your token lives in the session, and the next request lands on a different node, that session must already be there. The mechanism is called session replication, and it travels over the cluster's internal network.

That traffic carries sensitive material: session identifiers, application attributes, sometimes user data. This is why Tomcat provides EncryptInterceptor, a component that sits in the communication channel between nodes and encrypts its contents. It is a measure designed for anyone who does not trust the network they are talking over — a shared data centre, a cloud network, a segment several teams can reach.

Two flaws in a row

On 9 April 2026 the Apache Software Foundation published two CVEs that need to be read together.

The first is CVE-2026-29146: «Padding Oracle vulnerability in Apache Tomcat's EncryptInterceptor with default configuration». In plain terms, the way the component handled the padding of encrypted blocks let an observer of the traffic derive information about the content, one piece at a time. It affected a very wide range of versions — from 11.0.0-M1 through 11.0.18, 10.0.0-M1 through 10.1.52, 9.0.13 through 9.0.115, plus the older 8.5 and 7.0 series — and the fix arrived with versions 11.0.19, 10.1.53 and 9.0.116. Credit for the discovery, per the CVE record, goes to Uri Katz and Avi Lumelsky of Oligo Security.

The second is CVE-2026-34486, and the title Apache gave it says it all: «Fix for CVE-2026-29146 allowed bypass of EncryptInterceptor». The official description reads «Missing Encryption of Sensitive Data vulnerability in Apache Tomcat due to the fix for CVE-2026-29146 allowing the bypass of the EncryptInterceptor». Classification CWE-311, missing encryption of sensitive data. Affected versions: 11.0.20, 10.1.53 and 9.0.116. Fixed in 11.0.21, 10.1.54 and 9.0.117. Reported by Bartlomiej Dmitruk of striga.ai.

1. 9 April 2026
   The two CVEs

   Apache publishes CVE-2026-29146 (padding oracle) and CVE-2026-34486 (bypass of the fix).

2. 9 April 2026
   The patch for the patch

   11.0.21, 10.1.54 and 9.0.117 are released.

3. 4 August 2026
   Into CISA KEV

   The CVE joins the catalogue of vulnerabilities known to be exploited.

4. 7 August 2026
   The deadline

   Remediation date set by CISA for US federal agencies.

The detail worth reading twice

Versions 10.1.53 and 9.0.116 appear on both lists: they are the versions that fix the padding oracle and the versions affected by the bypass. Anyone who upgraded as soon as the first fix shipped — that is, anyone who did exactly the right thing, and quickly — ended up with a bypassable encryption component.

It is worth being precise about the difference between the two flaws, because they are not equivalent. A padding oracle is a cryptographic weakness: the encryption is there, but it leaks information if somebody probes it patiently. A bypass of the interceptor is something else: it means the encryption may not be there at all. The first problem forces an attacker to work. The second only asks them to listen.

That also explains the score. The assigned CVSS 3.1 is 7.5, with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N: reachable over the network, no privileges and no user interaction required, high impact on confidentiality and none on integrity or availability. It is not a takeover of the server: it is cluster traffic that stops being protected.

Why it landed in KEV, and what that really means

CISA's Known Exploited Vulnerabilities catalogue does not list vulnerabilities that are dangerous in theory: it lists vulnerabilities with evidence of real-world exploitation. The entry records dateAdded: 2026-08-04, dueDate: 2026-08-07, cwes: ["CWE-311"] and knownRansomwareCampaignUse: "Unknown". The required action is anchored to directive BOD 26-04, which requires US federal agencies to apply vendor mitigations or discontinue the product.

A vulnerability that exposes internal cluster traffic ends up in KEV for a specific reason: session replication traffic very often carries valid session identifiers. For most applications, a valid session identifier is an authentication that has already happened. Whoever intercepts it does not need to guess a password.

It is worth being equally clear about what we do not know: CISA does not publish details of the observed exploitation, names no actor, and the window between patch availability (April) and KEV entry (August) is nearly four months. When exploitation began is not publicly known.

What to do

Check the version, not the date of your last update. The safe versions are 11.0.21, 10.1.54 and 9.0.117 or later. If you are on 11.0.20, 10.1.53 or 9.0.116 you are exposed even though you updated recently — in fact, precisely because you updated recently.

Check whether you actually use EncryptInterceptor. The flaw concerns those who configured encryption on the cluster channel. If your Tomcat is not clustered, or does not use that component, this particular CVE does not touch you — but then it is worth asking what protects your replication traffic today, if anything does.

Do not treat the cluster network as a trusted zone. This case shows how fragile that assumption is: the component that secured the channel was first weakened and then made disableable, with no change in the application's visible behaviour. Segmenting the replication network, controlling who can reach those ports and monitoring the traffic remain valid defences even when the cryptographic layer breaks.

Add one check to your patching process: has the patch itself been fixed? That is the real lesson here. Patching fast is the right strategy and should stay that way — but an update is not a destination. Both CVEs carry the same publication date: anyone who read the April advisory to the end already had both pieces of information.