Tomcat fixes Kubernetes token leaks

Apache Tomcat released patches for ten vulnerabilities, including encryption bypasses and issues that can leak Kubernetes tokens from containerised Java apps. The advisory urges upgrades because web application servers running in containers remain a common vector for exposing cluster credentials. The update is specifically relevant for Java workloads in hardened CI/CD and EKS environments. (x.com/the_yellow_fall)

Apache Tomcat pushed security fixes in early April after one flaw let a clustering component write a Kubernetes bearer token into server logs. (tomcat.apache.org) (nvd.nist.gov) The token-leak bug, tracked as CVE-2026-34487, affects Tomcat 11.0.0-M1 through 11.0.20, 10.1.0-M1 through 10.1.53, and 9.0.13 through 9.0.116. Apache fixed it in 11.0.21, 10.1.54, and 9.0.117. (nvd.nist.gov) (tomcat.apache.org) A Kubernetes service account token is the credential a pod uses to talk to the cluster’s application programming interface, the control plane that creates pods, reads secrets, and changes deployments. Kubernetes can mount that token into a pod automatically, and projected volumes can place it in the container filesystem for apps to read. (kubernetes.io 1) (kubernetes.io 2) In this case, Tomcat’s cloud membership feature for clustering exposed that token in log messages. If those logs are shipped to shared storage, a security information and event management system, or another team’s dashboard, the credential can spread far beyond the original pod. (nvd.nist.gov) (www.herodevs.com) The April patch set covered more than the token leak. Apache also fixed CVE-2026-34486, which let users bypass the EncryptInterceptor in Tomcat 11.0.20, 10.1.53, and 9.0.116 after an earlier fix for CVE-2026-29146 proved incomplete. (nvd.nist.gov 1) (nvd.nist.gov 2) That earlier flaw, CVE-2026-29146, was a padding-oracle weakness in the EncryptInterceptor’s default configuration. Apache’s April 9 disclosures also included CVE-2026-29145, an authentication failure in some client-certificate checks, and CVE-2026-32990, another incomplete fix tied to an older Tomcat bug. (nvd.nist.gov) (services.nvd.nist.gov) (nvd.nist.gov) The container angle is what makes the token leak operationally important. In Kubernetes, a pod’s service account gives code inside that pod an identity in the cluster, and in Amazon Elastic Kubernetes Service that same service account can also be linked to an Amazon Web Services Identity and Access Management role for cloud access. (kubernetes.io) (docs.aws.amazon.com) Amazon Elastic Kubernetes Service says service account tokens are time-bound and, with Identity and Access Management roles for service accounts, pods use that identity to obtain Amazon Web Services credentials. That limits some long-term exposure, but it also means a leaked token can still become a bridge to cluster or cloud permissions while it is valid. (docs.aws.amazon.com 1) (docs.aws.amazon.com 2) Apache’s version guide now lists 11.0.21, 10.1.54, and 9.0.117 as the current supported releases, while Tomcat 10.0.x is already out of support. For teams running Java web apps in containers, the immediate job is straightforward: upgrade Tomcat and check whether recent logs captured service account tokens before the patch landed. (tomcat.apache.org) (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.