By exploiting this defect, a low-privileged user or service account with the ability to create Webhook generator resources can reference any Kubernetes secret within the cluster, regardless of whether it carries the required security label. When the operator processes the request, it skips the validation check and transmits the secret data to an attacker-controlled endpoint defined in the webhook configuration. This affects External Secrets Operator versions 0.10.0 through 1.3.1. The fix was introduced in version 1.3.2.

Impact

Successful exploitation allows for the exfiltration of sensitive Kubernetes secrets, including API keys, database credentials, or tokens stored within the cluster. This threat specifically targets clusters where users have delegated permissions to create webhook generators. If unauthorized actors gain access to this capability, they can extract credentials that were previously protected by namespace or label-based access control, potentially leading to privilege escalation or lateral movement within the environment.

Recommendation

Prioritized actions for security teams:

• Upgrade the External Secrets Operator to version 1.3.2 or later to remediate CVE-2026-26287.
• Implement an admission policy using OPA Gatekeeper or Kyverno to explicitly enforce the presence of the external-secrets.io/type=webhook label on all secrets referenced by Webhook generator objects.
• Review RBAC configurations to strictly limit the create or patch permissions on generators.external-secrets.io/v1alpha1 resources.
• Apply Kubernetes NetworkPolicies or service mesh egress filters to restrict the External Secrets Operator pod to only communicate with known, trusted webhook destinations.