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
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.