CVE-2026-26287: External Secrets Operator: label enforcement bypass in webhook generator enables secret exfiltration
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)
Other sources
External Secrets Operator reads information from a third-party service and automatically injects the values as Kubernetes Secrets. Starting in version 0.10.0 and prior to version 1.3.2, 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. Version 1.3.2 contains a patch.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/external-secrets/external-secretsto a version that resolves this vulnerability.Fixed in 1.3.2 - Upgrade
Upgrade
External Secrets Operatorto a version that resolves this vulnerability.Fixed in 1.3.2Patch PR #5901 - Configuration
Disable webhook generators if they are not needed, or deny generators.external-secrets.io/v1alpha1 Webhook via an admission policy.
External Secrets Operator webhook generators = disabled or denied - Configuration
Enforce an OPA Gatekeeper or Kyverno admission policy requiring referenced secrets to be labeled external-secrets.io/type=webhook.
Kubernetes admission policy external-secrets.io/type=webhook label requirement = required - Configuration
Limit who can create generators of kind Webhook.
External Secrets Operator RBAC Webhook generator creation permission = restricted - Configuration
Update the secret label to external-secrets.io/type=webhook before using it with the webhook generator.
Kubernetes Secret external-secrets.io/type = webhook - Compensating control
Restrict egress from External Secrets controller pods to an allowlist using a Kubernetes NetworkPolicy or service mesh egress policy.
Event History
Frequently Asked Questions
Who can exploit this issue?
A user who has permission to create Webhook generators can exploit it. They can configure a Webhook generator to reference a victim secret that is not labeled for Webhook use and send its contents to a malicious URL.
Is a secret label normally intended to prevent this access?
Yes. The provider-side check should require the referenced secret to have the label external-secrets.io/type=webhook. Due to the initialization-order bug, that check is skipped for affected Webhook generator operations.
What can be done if an upgrade cannot be applied immediately?
Disable Webhook generators if they are not required, or deny Webhook resources in generators.external-secrets.io/v1alpha1 through an admission policy. Also limit RBAC permissions to create Webhook generators, require referenced secrets to carry the Webhook label, and restrict egress from external-secrets controller pods to an allowlist.
How can egress controls reduce the impact?
The described exfiltration sends secret data to a malicious URL. Kubernetes NetworkPolicy or a service-mesh egress policy that allows controller pods to reach only approved destinations can prevent or limit that outbound transfer.