GPU VulnDB

Database/Control plane, storage & DevOps

External Secrets Operator: webhook generator skips the required type label check

CVSS 7.1CVE-2026-26287Control plane, storage & DevOpscurated

Impact

From 0.10.0 to before 1.3.2, an initialization-order bug in the webhook generator cleared the EnforceLabels flag after it had been set, so the provider-side check for the external-secrets.io/type=webhook label never ran. Operations that should have been refused with "secret does not contain needed label" succeeded instead, meaning a referenced Kubernetes Secret that was never marked for webhook use could be consumed by a webhook generator. In a multi-tenant cluster that label is part of how an operator fences which secrets a namespace's generators may touch, and External Secrets is usually the component holding credentials for the whole fleet - registry pulls, object storage, model buckets. The scored impact is confidentiality-led and requires an authenticated low-privilege caller.

Who can reach it

A cluster user authenticated with enough privilege to create or control an ExternalSecret/generator referencing a webhook generator and a Secret in reach of the operator. Not reachable without cluster API access.

What to do

Upgrade External Secrets Operator to 1.3.2 and let the controller deployment roll - this is a control-plane Deployment restart, no node drain and no reboot. Until it is applied, the label check cannot be relied on, so treat any Secret reachable by a webhook generator as effectively unlabelled and gate it with RBAC and namespace separation instead.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.