CVE-2026-42875: External Secrets Operator Auth Bypass

CVE-2026-42875 Overview

CVE-2026-42875 affects the External Secrets Operator (ESO), a Kubernetes controller that reads information from third-party secret management services and injects the values as Kubernetes Secrets. Versions prior to 2.4.0 contain an authorization flaw [CWE-285] in the handling of namespaced SecretStore resources that use a CAProvider with type ConfigMap. When caProvider.namespace was set, ESO resolved certificate authority (CA) material from a namespace other than the one hosting the SecretStore. This behavior bypassed the namespace boundary normally enforced for SecretStore-backed references. Version 2.4.0 fixes the issue.

Critical Impact

A tenant controlling a namespaced SecretStore can reference CA material from arbitrary namespaces, undermining the multi-tenant isolation expected from namespaced resources.

Affected Products

• external-secrets/external-secrets versions prior to 2.4.0
• Namespaced SecretStore resources configured with CAProvider of type ConfigMap
• Kubernetes clusters relying on ESO for cross-tenant secret distribution

Discovery Timeline

• 2026-05-11 - CVE-2026-42875 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42875

Vulnerability Analysis

The External Secrets Operator synchronizes secrets from external providers into Kubernetes through SecretStore and ClusterSecretStore custom resources. A SecretStore is a namespace-scoped resource, meaning its configuration and the references it makes are expected to remain within the namespace where the resource is defined. ESO supports optional TLS verification against external providers through a CAProvider field, which can point at a ConfigMap or Secret holding the CA certificate.

In versions before 2.4.0, the shared runtime CA resolver honored the caProvider.namespace field even when the parent resource was a namespaced SecretStore. The resolver fetched the ConfigMap from the namespace specified by the user instead of restricting the lookup to the SecretStore namespace. This contradicts the tenant isolation guarantees that namespaced SecretStore resources are meant to provide.

The vulnerability is categorized as Improper Authorization [CWE-285]. Exploitation requires the attacker to already hold permissions to create or modify SecretStore objects in a namespace, which is reflected in the low privilege requirement of the network-reachable attack vector.

Root Cause

The root cause is missing namespace enforcement in the shared CA resolver used by provider implementations. The resolver did not distinguish between namespaced SecretStore references, which must be confined to a single namespace, and ClusterSecretStore references, which legitimately permit cross-namespace lookups.

Attack Vector

An authenticated tenant with rights to create a SecretStore in their own namespace sets caProvider.type: ConfigMap and caProvider.namespace to a target namespace. The controller reads the referenced ConfigMap and applies its contents as the CA bundle. While the contents are not directly exfiltrated, the lookup itself bypasses the namespace boundary and can enable downstream impersonation or man-in-the-middle conditions against the external provider when a tenant supplies an attacker-controlled CA from another namespace. See the GitHub Security Advisory GHSA-wv26-88m5-6h59 for vendor details.

Detection Methods for CVE-2026-42875

Indicators of Compromise

• SecretStore manifests in tenant namespaces that set caProvider.namespace to a value different from the SecretStore's own namespace.
• Audit log entries showing the external-secrets controller service account reading ConfigMap resources outside the namespace of the requesting SecretStore.
• Unexpected changes to TLS validation behavior or provider endpoints in tenant SecretStore definitions.

Detection Strategies

• Query the cluster for all SecretStore resources and flag any where spec.provider.*.caProvider.namespace is populated and does not match metadata.namespace.
• Enable Kubernetes API server audit logging for configmaps get operations performed by the ESO controller, then correlate the target namespace with the originating SecretStore.
• Compare deployed ESO versions across the fleet against the fixed release 2.4.0.

Monitoring Recommendations

• Alert on creation or modification of SecretStore objects that include a cross-namespace caProvider reference.
• Track ESO controller version drift in continuous compliance scans of cluster workloads.
• Review RBAC bindings that grant tenants create or update rights on SecretStore resources and reduce scope where possible.

How to Mitigate CVE-2026-42875

Immediate Actions Required

• Upgrade External Secrets Operator to version 2.4.0 or later in every cluster where ESO is installed.
• Inventory existing SecretStore resources and remove or correct any caProvider.namespace value that points outside the resource's own namespace.
• Restrict SecretStore creation rights through RBAC to trusted operators while remediation is in progress.

Patch Information

The issue is fixed in external-secrets 2.4.0. The fix enforces that namespaced SecretStore resources resolve CAProvider references only within the SecretStore's own namespace. Refer to the GitHub Security Advisory GHSA-wv26-88m5-6h59 for the upstream advisory and release notes.

Workarounds

• Remove the caProvider field from namespaced SecretStore resources until the operator is upgraded.
• Use a ClusterSecretStore managed by platform administrators when cross-namespace CA references are required.
• Apply admission policies (for example, Kyverno or Gatekeeper) that reject SecretStore manifests where caProvider.namespace differs from metadata.namespace.

# Example Kyverno policy snippet to block cross-namespace caProvider references
# Reject SecretStore objects whose caProvider.namespace differs from metadata.namespace
kubectl get secretstores.external-secrets.io -A -o json \
  | jq '.items[] | select(
      (.spec.provider | .. | .caProvider? // empty)
      | .namespace? // "" as $ns
      | $ns != "" and $ns != .metadata.namespace
    ) | {ns: .metadata.namespace, name: .metadata.name}'