CVE-2025-62159: External Secrets Operator Auth Bypass

CVE-2025-62159 Overview

A critical vulnerability has been identified in the BeyondTrust provider implementation for External Secrets Operator, a Kubernetes operator that reads information from third-party secret management services and automatically injects the values as Kubernetes Secrets. The vulnerability allows unauthorized cross-namespace secret access due to improper namespace validation in the provider implementation.

The BeyondTrust provider in affected versions retrieved Kubernetes secrets directly without validating the namespace context or the type of secret store. This improper access control (CWE-284) allows attackers to bypass security boundaries and potentially access sensitive credentials stored in namespaces they should not have access to, violating Kubernetes multi-tenant security principles.

Critical Impact

Unauthorized cross-namespace secret access enables attackers to retrieve sensitive credentials from any namespace, potentially compromising the entire Kubernetes cluster's secret management infrastructure.

Affected Products

• External Secrets Operator versions 0.10.1 through 0.19.2
• BeyondTrust provider implementation within affected External Secrets Operator versions
• Kubernetes deployments utilizing the BeyondTrust provider for secret management

Discovery Timeline

• 2025-10-10 - CVE CVE-2025-62159 published to NVD
• 2025-10-14 - Last updated in NVD database

Technical Details for CVE-2025-62159

Vulnerability Analysis

This vulnerability stems from improper access control in the BeyondTrust provider's secret retrieval mechanism. The provider implementation failed to enforce namespace boundaries when retrieving Kubernetes secrets, allowing any user or process with access to the External Secrets Operator to potentially retrieve secrets from unauthorized namespaces.

In Kubernetes, namespaces provide a logical isolation boundary for resources including secrets. The External Secrets Operator distinguishes between SecretStore (namespace-scoped) and ClusterSecretStore (cluster-wide) resources. A properly implemented provider should only allow cross-namespace secret access when using a ClusterSecretStore, as this explicitly grants cluster-wide permissions.

The vulnerable implementation bypassed this fundamental security model by retrieving secrets directly without checking whether the requesting entity had proper namespace authorization or whether the secret store type permitted cross-namespace access.

Root Cause

The root cause of this vulnerability is the direct retrieval of Kubernetes secrets without proper namespace context validation in the BeyondTrust provider implementation. The provider code did not utilize the resolvers.SecretKeyRef utility function, which is designed to enforce namespace validation and restrict cross-namespace access to ClusterSecretStore types only.

This oversight meant that the provider would honor requests for secrets in any namespace, regardless of whether the requesting SecretStore resource existed in that namespace or had legitimate cluster-wide permissions through a ClusterSecretStore configuration.

Attack Vector

The vulnerability is exploitable over the network by attackers with access to create or modify External Secrets resources within a Kubernetes cluster. An attacker could craft malicious ExternalSecret resources that reference secrets in namespaces they do not have legitimate access to.

The attack scenario involves creating an ExternalSecret resource that specifies a target namespace containing sensitive credentials, such as database passwords, API keys, or service account tokens. Without proper namespace validation, the BeyondTrust provider would retrieve these secrets and expose them to the attacker's namespace, effectively bypassing Kubernetes RBAC controls on secret access.

The attack does not require user interaction and can be executed with low complexity once an attacker has obtained initial access to create External Secrets resources within any namespace of the affected cluster.

Detection Methods for CVE-2025-62159

Indicators of Compromise

• Unexpected ExternalSecret resources referencing namespaces different from where they are deployed
• Audit log entries showing secret access patterns crossing namespace boundaries via the BeyondTrust provider
• SecretStore resources attempting to access secrets outside their designated namespace scope
• Unusual secret synchronization activity from the External Secrets Operator pods

Detection Strategies

• Enable Kubernetes audit logging and monitor for cross-namespace secret access requests originating from External Secrets Operator service accounts
• Implement admission controller policies (Kyverno, OPA Gatekeeper) to detect and alert on ExternalSecret resources with suspicious namespace configurations
• Review External Secrets Operator logs for secret retrieval operations that span multiple namespaces without corresponding ClusterSecretStore configurations
• Deploy runtime security monitoring to track secrets access patterns and identify anomalous cross-namespace data flows

Monitoring Recommendations

• Configure alerting for any External Secrets resources created with namespace fields that differ from their deployment namespace
• Implement continuous compliance checks to verify all SecretStore resources are properly scoped to their respective namespaces
• Monitor External Secrets Operator version deployments across the cluster to identify instances running vulnerable versions (0.10.1 through 0.19.2)
• Track secrets synchronization metrics and alert on unusual spikes in cross-namespace secret operations

How to Mitigate CVE-2025-62159

Immediate Actions Required

• Upgrade External Secrets Operator to version 0.20.0 or later, which includes the fix utilizing the resolvers.SecretKeyRef utility for proper namespace validation
• Audit all existing ExternalSecret and SecretStore resources to identify any potentially malicious cross-namespace configurations
• Review Kubernetes audit logs for historical evidence of exploitation or unauthorized secret access
• Implement policy engine rules (Kyverno or OPA) as an interim control if immediate upgrade is not feasible

Patch Information

The vulnerability is addressed in External Secrets Operator version 0.20.0. The fix updates the BeyondTrust provider code to use the resolvers.SecretKeyRef utility, which enforces namespace validation and restricts cross-namespace access exclusively to ClusterSecretStore types. This ensures secrets are only retrieved from authorized namespaces, restoring proper security boundaries.

For detailed information about the security fix, refer to the GitHub Security Advisory.

Workarounds

• Deploy a policy engine such as Kyverno or OPA Gatekeeper to prevent the use of the BeyondTrust provider entirely until the upgrade can be completed
• Implement admission webhook policies that validate (Cluster)SecretStore configurations and ensure the namespace field may only be set when using a ClusterSecretStore
• Restrict RBAC permissions for creating ExternalSecret and SecretStore resources to minimize the attack surface
• Consider temporarily disabling the BeyondTrust provider and switching to alternative secret management providers with proper namespace validation

# Example Kyverno policy to validate ClusterSecretStore usage
# This policy ensures namespace field is only set for ClusterSecretStore types
# Deploy this as an interim control while planning the upgrade to version 0.20.0+
# kubectl apply -f clustersecretstore-validation-policy.yaml