Apache Tomcat runs the Java layer underneath a large share of enterprise and public-sector applications across Europe, often invisibly, tucked behind a load balancer as the actual thing executing business logic. On 4 August, CISA added CVE-2026-34486 to its Known Exploited Vulnerabilities catalog, confirming attackers are actively exploiting a flaw in Tomcat’s EncryptInterceptor, the component responsible for encrypting communication between nodes in a Tomcat cluster. The uncomfortable part is where this flaw came from.
A patch that undid its own predecessor
In April, Apache fixed CVE-2026-29146, a padding oracle vulnerability that let an attacker decrypt cluster session data without holding the encryption key. Teams running clustered Tomcat deployments patched, reasonably assumed the encryption weakness was closed, and moved on. That April fix, shipped in 9.0.116, introduced CVE-2026-34486: a regression that allows EncryptInterceptor to be bypassed entirely, meaning cluster traffic on the patched version can travel unencrypted, the exact outcome the original fix was supposed to prevent. Apache corrected it properly in 9.0.117, along with 11.0.21 and 10.1.54, but that second fix landed quietly as a version bump, not as a headline advisory, which is precisely why CISA’s KEV addition now matters: it is public confirmation that attackers found and are using the gap before most administrators noticed it existed.
Why this is easy to miss in a change log
Tomcat clustering is typically configured once, by whoever set up session replication or high availability years ago, and rarely revisited unless something breaks. A CVE fixing a previous CVE in the same component does not read as urgent from a change log entry, and an organisation that patched in April has every reason to believe the matter is closed. It is not, unless the version currently running is 9.0.117, 10.1.54, or 11.0.21 specifically, not merely “newer than 9.0.115.”
What to check today
Confirm your exact Tomcat version against the three fixed releases above, not just whether you have patched since April. If you run Tomcat clustering with EncryptInterceptor enabled for session replication, treat any traffic sent while running 9.0.116 as potentially exposed, and review cluster network segmentation as a compensating control regardless of patch status, since EncryptInterceptor was never meant to be your only protection for that traffic.
If your infrastructure includes Apache Tomcat clusters and you want a review of your patch level, cluster configuration, or broader Java application server exposure, contact Excello Digital. We help European engineering teams verify that a patch actually closed the gap it claimed to, rather than assuming a version number tells the whole story.