CVE-2026-22822: External Secrets Operator insecurely retrieves secrets through the getSecretKey templating function
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.
Security readout for executives and security teams
Plain-English summary
CVE-2026-22822 affects External Secrets Operator in Kubernetes. A template function named getSecretKey can let a user with limited Kubernetes access retrieve secrets across namespaces using the controller’s permissions. This can break tenant isolation and expose sensitive credentials. The vendor removed the function in version 1.2.0.
Executive priority
Treat as urgent for Kubernetes environments using External Secrets Operator. Secret exposure can undermine application, database, and cloud credentials. Prioritize upgrading affected clusters and enforcing policy controls, especially in multi-team or multi-tenant clusters.
Technical view
External Secrets Operator versions 0.20.2 through before 1.2.0 include getSecretKey, introduced for the senhasegura DSM provider. The function can fetch secrets cross-namespace with the external-secrets controller RoleBinding, bypassing intended safeguards. The issue is CWE-863, incorrect authorization, with CVSS 4.0 score 9.3. Version 1.2.0 removes the function.
Likely exposure
Clusters running External Secrets Operator >=0.20.2 and <1.2.0 are potentially exposed, especially where users can create or modify ExternalSecret resources. Exposure depends on Kubernetes RBAC, namespace boundaries, and whether policy controls block getSecretKey usage.
Exploitation context
Sources do not show CISA KEV listing or confirmed active exploitation. Exploitation requires local Kubernetes access with privileges to influence ExternalSecret templating. The business risk is unauthorized secret access across namespaces, potentially enabling credential theft and broader application compromise.
Researcher notes
The advisory states the function was removed because equivalent behavior can be achieved while respecting ESO safeguards. Public sources identify the vulnerable range and workaround, but do not provide evidence of exploitation in the wild. Avoid assuming impact outside External Secrets Operator without environment-specific validation.
Mitigation direction
Upgrade External Secrets Operator to version 1.2.0 or later.
Block getSecretKey in ExternalSecret resources using Kubernetes policy controls.
Use Kyverno, Kubewarden, OPA, or similar policy engines for enforcement.
Review vendor advisory and release notes before production rollout.
Restrict who can create or update ExternalSecret resources.
Validation and detection
Inventory External Secrets Operator versions across all clusters.
Identify clusters running versions >=0.20.2 and <1.2.0.
Search ExternalSecret resources for getSecretKey usage.
Review RBAC for users able to modify ExternalSecret resources.
Confirm policy controls reject new getSecretKey usage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-863: Authorization and privilege behavior lookup
Authorization weaknesses can support privilege escalation and valid-account review, depending on exploit path. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The affected technology mentions containers, so container-specific ATT&CK technique review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
5Timeline events
2ADP providers
9Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-863 · source CWE mapping
Incorrect Authorization
Incorrect Authorization represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.