Database/Container, Kubernetes & orchestration

Apache Tomcat: cloud membership clustering writes the Kubernetes bearer token into the log file

CVSS 7.5CVE-2026-34487Container, Kubernetes & orchestrationcurated

Impact

The cloud membership provider Tomcat uses to discover cluster peers inside Kubernetes logs the service account bearer token it authenticates with. Anyone who can read Tomcat's logs - a log-shipping pipeline, a shared observability stack, an operator with container log access, a sidecar in the same pod - obtains a live credential for the Kubernetes API with whatever rights that service account holds. On a fleet where the API server governs tenant namespaces, GPU device plugin configuration and scheduling, a leaked pod token is the usual first step from log access to cluster access. Only deployments using Tomcat clustering with the cloud membership provider are affected; the token is as valuable as the RBAC bound to that account.

Who can reach it

Anyone able to read the Tomcat log stream, including downstream log aggregation. No authentication to Tomcat itself is required once the logs are visible; the Kubernetes API is then reached with the leaked token.

What to do

Upgrade to Tomcat 11.0.21, 10.1.54 or 9.0.117 and restart the affected instances (daemon restart; no node drain). Treat every token already written to logs as compromised: delete the service account token secret or rotate the account so existing tokens stop working, and purge or restrict the archived logs that contain it.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-34487 https://lists.apache.org/thread/4xpkwolpkrj8v5xzp5nyovtlqp3y850h http://www.openwall.com/lists/oss-security/2026/04/09/28

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.