Listen to this Post
The vulnerability arises from misconfigured Service Accounts in namespaces accessible to an attacker. A user with only the permission to create `ExternalSecret` resources can force the External Secrets Operator (ESO) to generate a standard Kubernetes `Secret` resource. This newly created `Secret` is then automatically populated by the Kubernetes API with a long-lived authentication token for a specified Service Account. Crucially, the attacker does not require direct `create` permissions on `TokenRequest` or `Secret` resources to trigger this behavior. The flaw hinges on the operator’s trust in user-supplied Service Account specifications within the `ExternalSecret` manifest. By crafting an `ExternalSecret` that references a target Service Account, the attacker can cause the operator to act as a confused deputy. The operator, using its own elevated privileges, then requests a token for the target account. Kubernetes generates the token and writes it into a `Secret` in the attacker’s namespace, which the attacker can then read. This token can be used to impersonate the target Service Account, potentially granting the attacker its permissions. The issue is mitigated by the fact that the attacker’s existing permissions are already close to those of the target account. However, it allows privilege escalation within the same namespace without needing specific `TokenRequest` access. The attack is limited without other misconfigurations, but it enables unauthorized impersonation of any Service Account in the accessible namespace. The root cause is that ESO does not adequately validate or restrict the combination of `ServiceAccount` references and token generation templates. The patch disallows this combination, specifically targeting the bootstrap token secret type. Workarounds include admission control to block malicious templates, disabling token generation via kube-controller-manager flags, or strict RBAC restrictions.
DailyCVE Form:
Platform: Kubernetes external-secrets
Version: 0.1.0 to 2.4.0
Vulnerability: Token craft/impersonation
Severity: Moderate
Date: 2026-01-20
Prediction: 2026-02-01
What Undercode Say:
Check for vulnerable ExternalSecret resources referencing ServiceAccounts
kubectl get externalsecret --all-namespaces -o json | jq '.items[] | select(.spec.secretStoreRef.kind == "ClusterSecretStore") | .metadata.name'
Simulate exploit: Create ExternalSecret to craft ServiceAccount token
cat <<EOF | kubectl apply -f -
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: token-craft-exploit
spec:
secretStoreRef:
kind: SecretStore
name: vault-backend
target:
name: crafted-token-secret
creationPolicy: Owner
data:
- secretKey: token
sourceRef:
serviceAccount:
name: target-service-account
namespace: victim-namespace
EOF
Monitor token creation
kubectl get secret crafted-token-secret -o jsonpath='{.data.token}' | base64 -d
Exploit:
1. Identify a namespace with accessible `create` permissions for ExternalSecret.
2. Craft an `ExternalSecret` manifest referencing a target Service Account (e.g., victim ServiceAccount).
3. Apply the manifest; ESO creates a `Secret` containing the target’s long-lived token.
4. Retrieve the token from the created `Secret` (requires `get` permission on Secret).
5. Use the token with `kubectl –token=
Protection from this CVE:
- Upgrade to a patched version (2.4.1 or later) where the insecure combination is disallowed.
- Implement admission webhooks (e.g., Kyverno, OPA) to reject `ExternalSecret` resources that reference `ServiceAccount` token generation.
- Remove the `–service-account-private-key-file` flag from kube-controller-manager to disable legacy token generation.
- Restrict RBAC: limit `create` permissions on `ExternalSecret` to only highly trusted users/service accounts.
- Audit existing `ExternalSecret` resources for suspicious `serviceAccount` references.
Impact:
An attacker with low privileges (only create ExternalSecret) can:
– Impersonate any Service Account in the same namespace.
– Bypass `TokenRequest` permission requirements.
– Gain additional privileges if the impersonated account has elevated roles (e.g., cluster-admin).
– Potentially compromise sensitive data or escalate to full cluster control in misconfigured environments.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
