Insecure permissions in external-secrets v0.9.16 allows attackers to access sensitive data and escalate privileges by obtaining the service account's token.

Summary

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, as everything done with that templating function can be done in a different way while respecting our safeguards (for example, using sourceRef like explained here: https://github.com/external-secrets/external-secrets/issues/5690#issuecomment-3630977865)

Impact - Cross-namespace secret access: Attackers or misconfigured resources could retrieve secrets from namespaces other than the one intended. - privilege escalation: Unauthorized access to secrets could lead to privilege escalation, data exfiltration, or compromise of service accounts and credentials.

Resolution

We removed the incriminated templating function from our codebase. All users should upgrade to the latest version containing this fix.

Workarounds

Use a policy engine such as Kubernetes, Kyverno, Kubewarden, or OPA to prevent the usage of getSecretKey in any ExternalSecret resource.

Details

See also: - https://github.com/external-secrets/external-secrets/issues/5690 - https://github.com/external-secrets/external-secrets/pull/3895

Details The external-secrets has a deployment called default-external-secrets-cert-controller, which is bound with a same-name ClusterRole. This ClusterRole has "get/list" verbs of secrets resources(https://github.com/external-secrets/external-secrets/blob/main/deploy/charts/external-secrets/templates/cert-controller-rbac.yaml#L49). It also has path/update verb of validatingwebhookconfigurations resources(https://github.com/external-secrets/external-secrets/blob/main/deploy/charts/external-secrets/templates/cert-controller-rbac.yaml#L27). As a result, if a malicious user can access the worker node which has this deployment. he/she can: 1. For the "get/list secrets" permission, he/she can abuse the SA token of this deployment to retrieve or get ALL secrets in the whole cluster, including the cluster-admin secret if created. After that, he/she can abuse the cluster-admin secret to do whatever he/she likes to the whole cluster, resulting in a cluster-level privilege escalation.

2. For the patch/update verb of validatingwebhookconfigurations, the malicious user can abuse these permissions to get sensitive data or lanuch DoS attacks:

For the privilege escalation attack, by updating/patching a Webhook to make it listen to Secret update operations, the attacker can capture and log all data from requests attempting to update Secrets. More specifically, when a Secret is updated, this Webhook sends the request data to the logging-service, which can then log the content of the Secret. This way, an attacker could indirectly gain access to the full contents of the Secret.

For the DoS attack, by updating/patching a Webhook, and making it deny all Pod create and update requests, the attacker can prevent any new Pods from being created or existing Pods from being updated, resulting in a Denial of Service (DoS) attack.

PoC Please see the "Details" section

Impact Privilege escalation

Summary

The v2 template engine in runtime/template/v2/template.go imports Sprig’s TxtFuncMap() and removes env and expandenv, but leaves getHostByName available to user-controlled templates. Because ESO executes templates inside the controller process, an attacker who can create or update templated ExternalSecret resources can trigger controller-side DNS lookups using secret-derived values, creating a DNS exfiltration primitive.

Impact This is a confidentiality issue. In environments where untrusted or lower-trust users can author templated ExternalSecret resources and the controller can perform DNS resolution, fetched secret material can be exfiltrated through DNS without requiring direct outbound access from the attacker’s workload.