Tomcat flaws risk token leakage

Apache Tomcat disclosed multiple vulnerabilities that include encryption bypasses and the potential for Kubernetes token leakage. The combination of middleware encryption issues and leaked orchestration credentials raises the possibility of broader cluster-level exposure for Java services. Operators running legacy Java stacks in Kubernetes should treat the patches as high-priority. (securityonline.info)

Apache Tomcat disclosed a flaw on April 9 that can spill a Kubernetes bearer token into logs, exposing cluster credentials if those logs are reachable. (nvd.nist.gov) Tomcat is the Java server that runs many web applications, and its clustering feature lets multiple servers share session state so users stay logged in as traffic moves between nodes. Apache said the token leak sits in the cloud membership component used for clustering. (tomcat.apache.org 1) (tomcat.apache.org 2) The affected ranges are broad: Tomcat 9.0.13 through 9.0.116, 10.1.0-M1 through 10.1.53, and 11.0.0-M1 through 11.0.20. Apache and the National Vulnerability Database say the fixes are 9.0.117, 10.1.54, and 11.0.21. (nvd.nist.gov) A bearer token is a password-like credential that software presents to Kubernetes to prove it can call the cluster control plane. If that token lands in log files, anyone with log access may be able to reuse it until the token expires or is revoked. (nvd.nist.gov) Apache rated the token leak itself as Low in Tomcat 11, but the United States Cybersecurity and Infrastructure Security Agency’s enrichment on the same record lists a Common Vulnerability Scoring System score of 7.5 out of 10 because it can expose confidential data over the network without authentication. (tomcat.apache.org) (nvd.nist.gov) The April 9 disclosure also included a separate High-severity issue, CVE-2026-34486, in Tomcat’s EncryptInterceptor, the module that encrypts cluster traffic between nodes. Apache said an earlier fix for CVE-2026-29146 was incomplete and allowed the EncryptInterceptor to be bypassed. (tomcat.apache.org 1) (tomcat.apache.org 2) That matters for clustered Java services because the two bugs touch the same part of the stack: one can weaken protection on traffic moving between Tomcat nodes, and the other can put a Kubernetes credential into logs generated by the clustering component. Tomcat’s security model says cluster traffic requires a trusted network unless the EncryptInterceptor is in use. (tomcat.apache.org 1) (tomcat.apache.org 2) Apache shipped the April fixes in releases published under Tomcat 9.0.117, 10.1.54, and 11.0.21, and the 10.1.54 changelog notes reduced log verbosity for Kubernetes connection attempts and failures plus better error handling for the EncryptInterceptor. (tomcat.apache.org) The timing is awkward for teams that already patched in March. A Tomcat-focused advisory from HeroDevs said CVE-2026-34486 affects 9.0.116 specifically, meaning some operators who updated for the earlier EncryptInterceptor flaw still needed the April release to finish the fix. (herodevs.com) For operators, the immediate work is narrow and concrete: upgrade Tomcat, review logs that may have captured Kubernetes tokens, and rotate any exposed credentials. The risk starts with a log line, but in a Kubernetes environment that log line can carry the key to much more. (nvd.nist.gov) (tomcat.apache.org)

Get your own daily briefing

Scout delivers personalized news, insights, and conversations tailored to your role and industry.

Download on the App Store

Shared from Scout - Be the smartest in the room.