External Secrets Operator EUVD-2026-93468

Requires: (1) ESO running an affected version (>= 0.10.0 and < 1.3.2); (2) the webhook generator feature in use (generators.external-secrets.io/v1alpha1 Webhook); and (3) the attacker holding Kubernetes RBAC rights to create Webhook generator resources - this is the primary gating prerequisite and is why the CVSS vector carries PR:L rather than PR:N. Limiting factors that reduce realistic risk: exploitation is impossible without delegated generator-creation permissions, so single-tenant or tightly-RBAC'd clusters are largely unaffected; the attack is also blunted by the vendor-listed mitigations (disabling/denying Webhook generators via admission policy, Kyverno/OPA enforcement of the required label, and NetworkPolicy egress allowlists that prevent the controller from reaching an arbitrary malicious URL). Clusters that do not use webhook generators at all are not exploitable.

This is a legitimate but conditional access-control flaw in the External Secrets Operator (ESO) webhook generator, rated CVSS 7.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N). The vector shows network attack surface (the Kubernetes API) with low complexity and no user interaction, but critically PR:L - meaning an attacker must already hold Kubernetes RBAC permission to create Webhook generators, so this is NOT an unauthenticated remote issue. The underlying defect (CWE-696, incorrect behavior/initialization order) reliably clears the EnforceLabels flag, so once the privilege prerequisite is met exploitation is deterministic rather than probabilistic. No EPSS score, KEV listing, or public POC is present in the provided data; per precision rules the exploitation status is 'no public exploit identified at time of analysis.' The absence of KEV and EPSS data means real-world exploitation signal is UNKNOWN, not zero. Weighing these signals together, this is a real but moderate-priority issue: the high confidentiality impact (secret exfiltration) is gated behind a non-trivial RBAC privilege and the need for webhook generators to be in use, so it is most relevant to multi-tenant clusters where generator-creation rights are delegated to semi-trusted users. Single-admin clusters face limited practical exposure.

In a multi-tenant Kubernetes cluster, a user who has been granted RBAC permission to create Webhook generators (but not to read a particular victim Secret) creates a Webhook generator that references that unlabeled victim Secret and points at an attacker-controlled URL. Because the initialization-order bug clears the EnforceLabels flag, ESO skips the 'external-secrets.io/type=webhook' label check that should have blocked the operation, and the controller reads the Secret and sends its contents to the malicious endpoint. No public exploit code is identified at the time of analysis, though the deterministic nature of the bug makes reproduction straightforward for anyone with the required generator-creation rights.