CVE-2026-34487

What it actually does

A vulnerability in the cloud membership clustering component of Apache Tomcat causes it to incorrectly write sensitive Kubernetes bearer tokens into its log files. This constitutes an information disclosure flaw (CWE-532), allowing any entity with access to the logs to retrieve these credentials.

Why it matters to the business

Exposure of a Kubernetes bearer token can lead to a full compromise of the associated Kubernetes cluster. An attacker could steal or destroy sensitive data, disrupt critical services hosted on the cluster, and use the compromised environment as a pivot point for further attacks within the corporate network, leading to significant financial loss, reputational damage, and regulatory penalties.

How an attack unfolds

An attacker first gains read access to the log files of a vulnerable Apache Tomcat server. This can be achieved through a separate vulnerability like path traversal, a system misconfiguration that exposes logs, or through insider access. The attacker then parses the log files to locate the Kubernetes bearer token, which is stored in clear text. Using this stolen token, the attacker authenticates to the Kubernetes API server, gaining the same level of access as the Tomcat application. From there, they can execute commands within the cluster to exfiltrate data, deploy malicious containers, or disrupt operations.

How to fix it

Immediately upgrade Apache Tomcat instances to a version that corrects the vulnerability. According to the advisory, users should upgrade to one of the following versions or later: - For 11.0.x users: Upgrade to 11.0.21 - For 10.1.x users: Upgrade to 10.1.54 - For 9.0.x users: Upgrade to 9.0.117 As a temporary mitigation if patching is not immediately possible, severely restrict read access to Tomcat log files and rotate credentials for any potentially exposed Kubernetes service accounts.

How to confirm the fix worked

To confirm remediation, verify that all Apache Tomcat instances are running a patched version (11.0.21+, 10.1.54+, or 9.0.117+). After upgrading, inspect new log files generated by the cloud membership component to ensure bearer tokens are no longer being written. To check for historical exposure, perform a forensic review of all archived Tomcat logs, searching for patterns that match Kubernetes bearer tokens.

Typical attack path

1. Attacker gains read access to Apache Tomcat log files through misconfiguration, a separate vulnerability, or insider threat.
2. Attacker searches the log files for string patterns matching Kubernetes bearer tokens (JWTs).
3. Attacker extracts the exposed bearer token from the log entry.
4. Attacker uses the stolen token with a tool like 'kubectl' or direct API calls to authenticate to the Kubernetes API server.
5. Attacker leverages the compromised identity to perform malicious actions within the cluster, such as stealing data or deploying backdoors.

How to detect it

To detect historical or ongoing exploitation, security teams must analyze Apache Tomcat log files for the presence of Kubernetes bearer tokens, which are structured as JSON Web Tokens (JWTs). Look for long, base64-encoded strings, often in three parts separated by dots. Correlate access to these logs with subsequent authentication events to the Kubernetes API server. Monitor Kubernetes audit logs for any suspicious activity, such as unexpected pod creation, privilege escalation, or data access from an identity associated with a Tomcat service account.

• regex:eyJ[A-Za-z0-9\-_]+\.eyJ[A-Za-z0-9\-_]+\.[A-Za-z0-9\-_]+
• k8s.io/client-go
• bearer_token
• clustering.kubernetes

What your security team should do

• Immediately patch all vulnerable Apache Tomcat instances, prioritizing those running in Kubernetes environments.
• Scan all historical and current Tomcat log files for exposed Kubernetes bearer tokens. If any are found, revoke the tokens immediately.
• Investigate the activity of any compromised tokens by analyzing Kubernetes API server audit logs for unusual or unauthorized actions.
• Implement strict, least-privilege access controls for all log directories and log aggregation platforms.
• Review service account permissions in Kubernetes to ensure they are scoped to the minimum required for their function.