CVE-2026-22822
Published: 21 January 2026
Summary
CVE-2026-22822 is a critical-severity Incorrect Authorization (CWE-863) vulnerability in External-Secrets External Secrets Operator. Its CVSS base score is 9.3 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 7.1th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified are NIST 800-53 AC-6 (Least Privilege) and CM-6 (Configuration Settings).
Deeper analysis
CVE-2026-22822 is a vulnerability in the External Secrets Operator, a Kubernetes component that reads information from third-party services and injects it as Kubernetes Secrets. Affecting versions starting from 0.20.2 up to but not including 1.2.0, the issue stems from the `getSecretKey` template function, originally introduced for the senhasegura DevOps Secrets Management (DSM) provider. This function enables fetching secrets across namespaces using the roleBinding permissions of the external-secrets controller, thereby bypassing the operator's intended security mechanisms. The vulnerability is rated with a CVSS v3.1 base score of 8.8 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) and is associated with CWE-863 (Incorrect Authorization).
An attacker with low privileges (PR:L) and local access (AV:L) to the Kubernetes cluster can exploit this vulnerability by crafting an ExternalSecret resource that invokes the `getSecretKey` function. This allows unauthorized access to secrets in namespaces beyond the attacker's scope, leveraging the controller's elevated roleBinding permissions. Successful exploitation results in high-impact confidentiality, integrity, and availability violations (C:H/I:H/A:H), as the attacker can read, potentially modify, or disrupt sensitive secret data across the cluster.
Mitigation involves upgrading to External Secrets Operator version 1.2.0 or later, where the `getSecretKey` function has been completely removed, with equivalent functionality achievable through safer templating methods that respect the operator's safeguards. As a workaround prior to upgrading, deploy a policy engine such as Kubernetes Network Policies, Kyverno, Kubewarden, or OPA/Gatekeeper to block the use of `getSecretKey` in any ExternalSecret resources. Official advisories and patches are detailed in the project's GitHub security advisory (GHSA-77v3-r3jw-j2v2), release notes for v1.2.0, and related pull request #3895.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-3404
Vulnerability details
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Vulnerability directly enables unauthorized cross-namespace secret retrieval via controller permissions (bypassing authorization), facilitating privilege escalation (T1068) and access to unsecured credentials/secrets (T1552).
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Directly mitigates the CVE by requiring timely patching of the External Secrets Operator to version 1.2.0 or later, where the exploitable `getSecretKey` function is fully removed.
Enforces least privilege on the external-secrets controller's roleBindings to restrict cross-namespace secret access, preventing exploitation even if the vulnerable function is invoked.
Establishes and enforces secure configuration settings using policy engines like Kyverno or OPA to block `getSecretKey` usage in ExternalSecret resources as a workaround.