Moolen

**Name of the Vulnerable Software and Affected Versions** External Secrets Operator versions prior to 2.4.0 **Description** Namespaced SecretStore resources using CAProvider with type `ConfigMap` could resolve CA material from a different namespace when the `caProvider.namespace` variable was set. This behavior bypassed the namespace boundary enforced for SecretStore-backed references in providers relying on the shared runtime CA resolver. While the accessible data is used for CA validation and not directly exposed, this leads to a trust-boundary violation where a tenant can force its SecretStore to consume CA material owned by another namespace. Additionally, it allows for existence disclosure, enabling an attacker to infer if a specific target ConfigMap or key exists in another namespace. **Recommendations** Update to version 2.4.0.

**Name of the Vulnerable Software and Affected Versions** External Secrets Operator versions 0.10.1 through 0.19.2 **Description** The External Secrets Operator reads information from a third-party service and automatically injects the values as Kubernetes Secrets. A flaw exists in the BeyondTrust provider implementation where 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, potentially exposing sensitive credentials. The issue was addressed in version 0.20.0 by using the `resolvers.SecretKeyRef` utility, which enforces namespace validation and restricts cross-namespace access to `ClusterSecretStore` types. **Recommendations** Upgrade to External Secrets Operator version 0.20.0 or later. As a workaround, use a policy engine such as Kyverno or OPA to prevent using the BeyondTrust provider. As a workaround, validate the `(Cluster)SecretStore` and ensure the namespace may only be set when using a `ClusterSecretStore`.