Live › vulnerability › CVE-2026-26287
Go to dashboardExternal Secrets Operator's webhook generator cleared its label-enforcement flag during initialization, so the check requiring the external-secrets.io/type=webhook label was skipped. A user who can create or reference generator resources can therefore get secrets exfiltrated through the webhook path that should have been refused.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 19:13 UTC, 0h before NVD. All times on this page are UTC.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| github.com/external-secrets/external-secrets | go | >= 0.10.0, < 1.3.2 | 1.3.2 |
Run go list -m github.com/external-secrets/external-secrets in the module, or check the deployed controller image version with kubectl get deploy -A -o wide | grep external-secrets.
1.3.2 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-26287")
Go Vulnerability Database, CC-BY 4.0 · EPSS scores by FIRST, used with attribution · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.