CVE-2026-42876: External Secrets Operator Escalation Flaw

CVE-2026-42876 Overview

CVE-2026-42876 is an authorization flaw in the External Secrets Operator, a Kubernetes controller that reads values from third-party secret stores and injects them as Kubernetes Secrets. Versions prior to 2.4.1 fail to restrict the type of Secret an ExternalSecret resource can request. A user holding only create permission on ExternalSecret objects can instruct the operator to produce a Secret of type kubernetes.io/service-account-token. Kubernetes then automatically populates that Secret with a long-lived token for the referenced service account. The attacker effectively impersonates any service account in the namespace without ever holding TokenRequest or service account token creation rights. The issue is tracked under CWE-285: Improper Authorization and fixed in release 2.4.1.

Critical Impact

Authenticated namespace users can mint long-lived service account tokens and impersonate any service account in that namespace, bypassing native Kubernetes RBAC boundaries on TokenRequest and token-type Secrets.

Affected Products

• External Secrets Operator versions prior to 2.4.1
• Kubernetes clusters running the operator with namespace users granted create on ExternalSecret resources
• Multi-tenant clusters relying on the operator for secret synchronization

Discovery Timeline

• 2026-05-11 - CVE-2026-42876 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42876

Vulnerability Analysis

The External Secrets Operator reconciles ExternalSecret custom resources by fetching values from a configured backend and writing them into a Kubernetes Secret. Prior to version 2.4.1, the admission validator did not constrain the spec.target.template.type field of the generated Secret. An attacker submits an ExternalSecret with type: kubernetes.io/service-account-token and an annotation referencing a privileged service account in the same namespace. The operator creates the Secret with that type. The Kubernetes Token Controller observes the new token-type Secret and populates its data.token field with a non-expiring JWT bound to the referenced service account. The attacker then reads the Secret and uses the token to act as that service account against the API server.

Root Cause

The operator's webhook validator in apis/externalsecrets/v1/externalsecret_validator.go and the corresponding v1beta1 validator did not enforce a deny-list on Secret types that trigger automatic credential population by kube-controller-manager. The fix introduces corev1 type checks and rejects ExternalSecret resources that request corev1.SecretTypeServiceAccountToken. This represents a missing authorization check, classified as [CWE-285].

Attack Vector

The attack requires a low-privilege authenticated user inside a target namespace who can create ExternalSecret objects. No direct permission on TokenRequest, serviceaccounts/token, or Secrets of token type is needed. The user crafts an ExternalSecret whose target template declares kubernetes.io/service-account-token and references a high-privilege service account by name. After reconciliation, the user reads the resulting Secret and extracts the token.

// Patch excerpt: apis/externalsecrets/v1/externalsecret_validator.go
 	"context"
 	"errors"
 	"fmt"
+	"strings"
 
+	corev1 "k8s.io/api/core/v1"
 	"sigs.k8s.io/controller-runtime/pkg/webhook/admission"
 )

Source: external-secrets commit 4ddd240a

The patch imports corev1 so the validator can compare the requested Secret type against corev1.SecretTypeServiceAccountToken and reject the request before reconciliation. An identical change is applied to the v1beta1 validator.

Detection Methods for CVE-2026-42876

Indicators of Compromise

• ExternalSecret resources whose template specifies type: kubernetes.io/service-account-token.
• Newly created Secrets of type kubernetes.io/service-account-token carrying the kubernetes.io/service-account.name annotation but not owned by a ServiceAccount object.
• Audit log entries showing create on externalsecrets.external-secrets.io followed shortly by get on a Secret in the same namespace.
• API server activity using a service account token from a Secret that was synthesized by the operator rather than auto-mounted at pod start.

Detection Strategies

• Run Kubernetes audit policy at Metadata or higher and alert on ExternalSecret create events with embedded serviceAccountToken type strings.
• Compare Secrets of type kubernetes.io/service-account-token against their owning ServiceAccount references and flag mismatches.
• Hunt across cluster audit logs for service account token usage originating from IP addresses or user agents that do not match the workload that normally mounts that token.

Monitoring Recommendations

• Forward Kubernetes API server audit logs to a centralized analytics platform and retain ExternalSecret and Secret create events for correlation.
• Track the version of the External Secrets Operator deployed in every cluster and alert when versions below 2.4.1 are observed.
• Monitor RBAC bindings that grant create on externalsecrets.external-secrets.io and review whether those subjects also need indirect token issuance capability.

How to Mitigate CVE-2026-42876

Immediate Actions Required

• Upgrade the External Secrets Operator to version 2.4.1 or later in every cluster.
• Inventory existing Secrets of type kubernetes.io/service-account-token created since the operator was installed and rotate any tokens that were generated through an ExternalSecret.
• Restrict create permissions on ExternalSecret resources to trusted automation and remove broad namespace user grants until the upgrade is complete.
• Review service accounts in shared namespaces and tighten RBAC bindings so impersonation of privileged accounts has limited blast radius.

Patch Information

The fix is delivered in External Secrets Operator v2.4.1. The validator change in commit 4ddd240a rejects any ExternalSecret requesting a Secret of type kubernetes.io/service-account-token. Full technical details are documented in GHSA-fq7h-9x26-6j22.

Workarounds

• Deploy an admission policy using Kyverno or OPA Gatekeeper that denies ExternalSecret resources whose spec.target.template.type equals kubernetes.io/service-account-token.
• Use a ValidatingAdmissionPolicy to block creation of Secrets of type kubernetes.io/service-account-token outside of trusted controllers.
• Limit operator deployment to namespaces whose users are already trusted to issue service account tokens, eliminating the privilege boundary the bug crosses.

# Kyverno ClusterPolicy blocking service-account-token ExternalSecrets
kubectl apply -f - <<'EOF'
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: deny-eso-sa-token
spec:
  validationFailureAction: Enforce
  rules:
    - name: block-sa-token-type
      match:
        any:
          - resources:
              kinds:
                - ExternalSecret
      validate:
        message: "ExternalSecret may not create service-account-token Secrets"
        pattern:
          spec:
            target:
              template:
                type: "!kubernetes.io/service-account-token"
EOF