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.
Summary A bug in the webhook generator initialization order incorrectly cleared the label-enforcement flag (EnforceLabels) after it was set, resulting in the provider-side check for external-secrets.io/type=webhook being skipped (and the operation to succeed while it should have failed with secret does not contain needed label 'external-secrets.io/type: webhook'. Update secret label to use it with webhook.
Impact A user with the permission to create webhook generator can set the webhook generator to a victim' secret (which was not previously labelled for webhook's use), and exfiltrate it to a malicious URL.
Mitigations Until you upgrade, you can reduce risk by: - disabling webhook generators if not needed (or denying generators.external-secrets.io/v1alpha1 Webhook via an admission policy); - restricting RBAC: limit who can create generators of kind Webhook; - enforcing an admission policy (OPA Gatekeeper / Kyverno) requiring referenced secrets to be labeled external-secrets.io/type=webhook; - restricting egress from external-secrets controller pods to an allowlist (kubernetes NetworkPolicy / service mesh egress policy).
References - PR #5901 (fix: webhook initialization order)