CVE-2025-62159
HighCVSS 8.7Exploitation Probability (EPSS)
Low risk22th percentile - higher than 22% of all known CVEs
Summary
In External Secrets Operator versions 0.10.1 through 0.19.2, the BeyondTrust provider retrieved Kubernetes secrets directly without validating the namespace context or the type of secret store. This allowed unauthorized cross-namespace secret access, violating security boundaries and potentially exposing sensitive credentials.
Risk Assessment
Sensitive credentials stored in Kubernetes secrets may be exposed. This breaches namespace isolation and could lead to privilege escalation.
Recommendation
Upgrade External Secrets Operator to version 0.20.0 or later, which enforces namespace validation. As a workaround, use Kyverno or OPA to prevent using the BeyondTrust provider or validate the (Cluster)SecretStore.
Other vulnerabilities in External Secrets Operator
See all- CVE-2026-26287High
External Secrets Operator versions from 0.10.0 to 1.3.1 contain a bug in the webhook generator initialization order that clears the EnforceLabels flag after it is set. This skips the label check for external-secrets.io/type=webhook, allowing an operation that should fail. Version 1.3.2 contains a patch.
- CVE-2026-22822High
A vulnerability in External Secrets Operator (versions 0.20.2 to 1.2.0) allows bypassing security mechanisms via the `getSecretKey` template function, which can fetch secrets across namespaces using the controller's roleBinding. This function was completely removed in version 1.2.0.
Original NVD description (English source)
External Secrets Operator reads information from a third-party service and automatically injects the values as Kubernetes Secrets. A vulnerability was discovered in the BeyondTrust provider implementation for External Secrets Operator versions 0.10.1 through 0.19.2. The provider previously retrieved Kubernetes secrets directly, without validating the namespace context or the type of secret store. This allowed unauthorized cross-namespace secret access, violating security boundaries and potentially exposing sensitive credentials. In version 0.20.0, the provider code was updated to use the `resolvers.SecretKeyRef` utility, which enforces namespace validation and only allows cross-namespace access for `ClusterSecretStore` types. This ensures secrets are only retrieved from the correct namespace, mitigating the risk of unauthorized access. All users should upgrade to the latest version containing this fix. As a workaround, use a policy engine such as Kyverno or OPA to prevent using BeyondTrust provider and/or validate the `(Cluster)SecretStore` and ensure the namespace may only be set when using a `ClusterSecretStore`.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS