External Secrets Operator
CVE-2026-22822
CRITICAL
GHSA-77v3-r3jw-j2v2
Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Tenant submits ExternalSecret via the K8s API (AV:N) with namespace-scoped rights (PR:L); the bypass crosses the namespace trust boundary (S:C) yielding foreign-secret disclosure (C:H) and limited secret injection (I:L).
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Primary rating from Vendor (github).
CVSS VectorVendor: github
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
11DescriptionCVE.org
External Secrets Operator reads information from a third-party service and automatically injects the values as Kubernetes Secrets. Starting in version 0.20.2 and prior to version 1.2.0, the getSecretKey template function, while introduced for senhasegura Devops Secrets Management (DSM) provider, has the ability to fetch secrets cross-namespaces with the roleBinding of the external-secrets controller, bypassing our security mechanisms. This function was completely removed in version 1.2.0, as everything done with that templating function can be done in a different way while respecting External Secrets Operator's safeguards As a workaround, use a policy engine such as Kubernetes, Kyverno, Kubewarden, or OPA to prevent the usage of getSecretKey in any ExternalSecret resource.
AnalysisAI
Cross-namespace secret disclosure in External Secrets Operator (versions 0.20.2 through 1.1.x) lets a low-privileged tenant who can author ExternalSecret resources abuse the getSecretKey template function to fetch secrets from other namespaces using the controller's own roleBinding, bypassing the operator's namespace-isolation safeguards. The function - originally added for the senhasegura DSM provider - was removed entirely in 1.2.0. There is no public exploit identified at time of analysis and EPSS is negligible (0.01%), but the authorization-bypass primitive is straightforward for any tenant with ExternalSecret create rights.
Technical ContextAI
External Secrets Operator (ESO) is a widely used Kubernetes controller that synchronizes secrets from external secret managers (Vault, AWS/GCP/Azure, senhasegura DSM, etc.) into native Kubernetes Secrets. ESO's security model relies on namespace scoping so a tenant's ExternalSecret can only materialize secrets the tenant is entitled to. The root cause is CWE-863 (Incorrect Authorization): the getSecretKey Go-template helper resolves secret references using the external-secrets controller's cluster-level ServiceAccount/roleBinding rather than the requesting tenant's permissions, so template evaluation effectively runs with the controller's elevated identity and crosses the namespace boundary the operator is supposed to enforce. The affected component per the CPE is cpe:2.3:a:external-secrets:external_secrets_operator.
RemediationAI
Vendor-released patch: version 1.2.0 - upgrade External Secrets Operator to v1.2.0 or later (release: https://github.com/external-secrets/external-secrets/releases/tag/v1.2.0; fix commit https://github.com/external-secrets/external-secrets/commit/17d3e22b8d3fbe339faf8515a95ec06ec92b1feb), which removes the getSecretKey function entirely; the advisory notes any legitimate use case can be reimplemented through supported mechanisms that respect ESO's namespace safeguards. If you cannot upgrade immediately, the vendor-recommended workaround is to deploy an admission/policy engine - Kyverno, Kubewarden, OPA/Gatekeeper, or native Kubernetes admission policies - to reject any ExternalSecret resource whose template references getSecretKey; the trade-off is that this requires a correctly scoped, well-tested policy covering all namespaces (a gap or bypass leaves the flaw exploitable) and may break any workload legitimately relying on that function until it is migrated. Consult SUSE-SU-2026:0403 and the Red Hat VEX for distro-specific fixed packages.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass
Kamaji is the Hosted Control Plane Manager for Kubernetes. Rated critical severity (CVSS 9.9), this vulnerability is rem
Jumpserver is a popular open source bastion host, and Koko is a Jumpserver component that is the Go version of coco, ref
String filter bypass in Inspektor Gadget Kubernetes eBPF tooling before fix. Insufficient string escaping enables filter
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: High| Product | Status |
|---|---|
| openSUSE Leap 15.6 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Fixed |
| openSUSE Leap 15.5 | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today