CVE-2026-22822: Critical External Secrets Operator Flaw Enabling Cross-Namespace Secret Theft

CVE-2026-22822 — External Secrets Operator Cross-Namespace Secret Disclosure

CVE: CVE-2026-22822
Affected Product: External Secrets Operator (ESO)
Severity: Critical
CVSS Score: 9.3 (Critical)
Exploitability: Easy for anyone who can submit a crafted manifest to a cluster where ESO has sufficient permissions
Public PoC: None publicly released
Official Patch / Upgrade Link: Provided below.

What This Vulnerability Is

External Secrets Operator is a Kubernetes extension that reads secrets from outside Kubernetes (like cloud secret managers) and creates Kubernetes Secret objects. A function called getSecretKey was added to the operator’s templating system so users could pull specific key values from an external secret.

Unfortunately, that function didn’t enforce the usual namespace restrictions. Because of the way the operator evaluated the template, an attacker or a misconfigured ExternalSecret manifest could tell ESO to fetch a secret from another namespace — one it should never have access to — and then create that secret in a different namespace.

In normal Kubernetes operations, namespaces create boundaries so that one team’s secrets are not visible to another team. This flaw bypassed that boundary.

How It Could Be Exploited

To take advantage of this weakness, an attacker needs the ability to create or modify an ExternalSecret resource in a cluster where External Secrets Operator runs with broad secret permissions.

A malicious manifest could include the unsafe getSecretKey helper in its template section. When ESO reconciles that manifest, it executes the template. Because getSecretKey does not enforce namespace scoping, it could fetch external secret values that belong to other teams or environments, and then materialize them as Kubernetes Secrets in the attacker’s namespace.

In simple terms:

Attacker submits an ExternalSecret object that uses getSecretKey.
ESO processes it and pulls data it shouldn’t.
ESO writes a new Secret into a namespace the attacker controls.

This results in full disclosure of confidential secret values from other namespaces.

There’s no public proof-of-concept code circulating, but it isn’t needed to understand that the mechanism itself inherently allowed secrets to be read improperly. Because the functionality was removed in the patch, anyone relying on it should upgrade immediately.

Why This Matters

Secrets often contain:

Database credentials
API keys
Cloud access tokens
Encryption secrets

If any of these leak, attackers can pivot deeper into infrastructure, move laterally across systems, or exfiltrate data.

A mistake in one manifest could expose critical credentials for the entire organization. Because ESO typically runs with permissions to read/write Kubernetes Secrets, misuse of this function can have far-reaching consequences.

Who Is At Risk

Clusters running vulnerable versions of External Secrets Operator (before the patch)
Teams that allow creation or modification of ExternalSecret objects by developers or CI systems
Environments with shared clusters where multiple teams work in separate namespaces

What You Should Do Now

1. Upgrade ESO Immediately

Update to a version that no longer contains getSecretKey. The safest and official upgrade path is described here:

🔗 https://github.com/advisories/GHSA-77v3-r3jw-j2v2

Install the fixed version according to your deployment method (Helm, OLM, kubectl apply, etc.).

2. Audit Existing ExternalSecrets

Look for any ExternalSecret that uses templating fields or contains unexpected keys in its spec. Remove or rewrite those manifests.

3. Tighten Permissions

Ensure ESO runs with the minimum permissions required. It should not have cluster-wide secret access unless absolutely necessary.

How to Detect Attempts or Abuse

There is no public exploit script, but you can detect suspicious activity using logs.

Kubernetes API Audit Log Monitoring

Watch for:

Creation of ExternalSecret objects with unusual or templated fields
Secrets created by the ESO service account in namespaces it normally shouldn’t act in
RoleBindings or ClusterRoleBindings that grant broad secret access to the operator

Splunk Detection Query

This Splunk query looks for suspicious ExternalSecret creations and secret writes by the ESO controller:

index=kube_audit_logs
(
    (
        verb="create"
        AND objectRef.resource="externalsecrets"
        AND requestObject="*getSecretKey*"
    )
    OR
    (
        verb="create"
        AND objectRef.resource="secrets"
        AND user="system:serviceaccount:*:external-secrets-controller"
        AND objectRef.namespace!=allowed_namespace_1
        AND objectRef.namespace!=allowed_namespace_2
    )
)
| stats count by user, objectRef.resource, objectRef.namespace, requestURI, responseStatus
| where count > 0

Customize allowed_namespace_1 / allowed_namespace_2 to match namespaces where ESO should legitimately run.

This query will surface:

API requests to create ExternalSecrets containing the unsafe function
Unexpected Secret creation events by the ESO controller

Kyverno Policy to Block Unsafe ExternalSecrets

If you use Kyverno, apply this policy to reject any ExternalSecret manifest that contains the unsafe getSecretKey function:

apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: block-unsafe-externalsecret
spec:
  validationFailureAction: enforce
  rules:
  - name: block-getsecretkey-usage
    match:
      resources:
        kinds:
        - ExternalSecret
    validate:
      message: "ExternalSecret uses unsafe templating function getSecretKey, which is not allowed."
      pattern:
        spec:
          template:
            # Reject if getSecretKey appears anywhere in template
            "{{getSecretKey}}": "?*"

Apply it with:

kubectl apply -f block-unsafe-externalsecret.yaml

This policy does not stop all misuse, but it stops the specific pattern that enabled the vulnerability.

Final Takeaway

A permissive templating function in External Secrets Operator allowed secrets to be fetched across namespaces.
There is no public exploit, but the mechanism itself broke isolation guarantees.
Patch the operator to the fixed version right now.
Tighten permissions and audit existing ExternalSecret configurations.
Use monitoring (Splunk or other SIEM) to detect unusual creation of ExternalSecrets or Secrets.
Use policy enforcement (Kyverno) to block unsafe configurations.