LiveActive security incident?Get immediate response
CVE Record

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.

CriticalCVSS 9.3Not KEV-listedUpdated
Glexia's TakeAutomated analysiscritical

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.
  • Verify upgrade removed the vulnerable function.
Prepared
Confidence
high
Sources
7

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.

Open ATT&CK lookup
description · low confidence lookup

Container behavior lookup

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.

Open ATT&CK lookup
cve · low confidence lookup

CVE-2026-22822 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Critical
CVSS
9.3 (4.0)
Known Exploited
No
Published

Vector: 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

Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

ScoreVersionSeverityVectorExploitImpactSource
9.3CVSS 4.0CriticalCVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H——GitHub_M
8.8CVSS 3.1HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H26redhat-SADP

Vulnerability scoring details

Base CVSS 4.0 score

9.3Critical
CVSS 4.0 vector shape for CVE-2026-22822Attack VectorAttack ComplexityAttack RequirementsPrivileges RequiredUser InteractionVS ConfidentialityVS IntegrityVS AvailabilitySS ConfidentialitySS IntegritySS Availability

Vector: 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

Attack Vector
NetworkAdjacentLocalPhysical
Attack Complexity
LowHigh
Attack Requirements
NonePresent
Privileges Required
NoneLowHigh
User Interaction
NonePassiveActive
VS Confidentiality
HighLowNone
VS Integrity
HighLowNone
VS Availability
HighLowNone
SS Confidentiality
HighLowNone
SS Integrity
HighLowNone
SS Availability
HighLowNone

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. ADP timelineredhat-SADP

    Made public.

  3. CVE publishedCVE Program

    The CVE record was published.

  4. ADP timelineredhat-SADP

    Reported to Red Hat.

  5. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

ADP provider summaries

CISA-ADPCISA ADP Vulnrichment
other:ssvc
redhat-SADPexternal-secrets: External Secrets Operator: Cross-Namespace Secret Disclosure via `getSecretKey` Function
other:Red Hat severity ratingcvssV3_1
  • 2026-01-21T22:01:44.507Z: Reported to Red Hat.
  • 2026-01-21T21:22:05.249Z: Made public.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
external-secretsexternal-secrets>= 0.20.2, < 1.2.0Listed
Weakness

CWE details

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.