Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

CVE-2026-26287 — external-secrets

HIGHFix: external-secrets/external-secrets@25aa092

CVE-2026-26287 is a high-severity (CVSS 7.1) CWE-696 vulnerability in github.com/external-secrets/external-secrets. A fix is available for github.com/external-secrets/external-secrets — see the affected versions and patch details below.

External Secrets Operator: label enforcement bypass in webhook generator enables secret exfiltration

Also known asGHSA-q7hv-xx6h-q2x8GO-2026-6667
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 20, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-26287.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs15th percentile — riskier than 15% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-26287 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐹github.com/external-secrets/external-secrets

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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)

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/external-secrets/external-secrets≥ 0.10.0&&< 1.3.21.3.2go get github.com/external-secrets/external-secrets@v1.3.2

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/external-secrets/external-secrets, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/external-secrets/external-secrets to 1.3.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-26287 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

Red Hat is aware of a vulnerability in External Secrets Operator where label enforcement for webhook generators can be bypassed. An authorized user who can create a webhook generator may retrieve and exfiltrate a Secret that is not labeled for webhook use. Red Hat is preparing updates for affected products.

Workaround published by Red Hat
Until an update is available, disable webhook generators when they are not required. Restrict permission to create Webhook generator resources, enforce the external-secrets.io/type=webhook label with an admission policy, and restrict egress from External Secrets Operator controller pods to approved destinations. Upgrade to a Red Hat product update containing External Secrets Operator 1.3.2 or later when available.
Source: Red Hat security advisory for CVE-2026-26287 (CC BY 4.0)

Frequently Asked Questions

## 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 exfi
O3 Security · Impact-Aware SCA

Is CVE-2026-26287 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-26287: external-secrets — Fixed in 1.3.2