CVE-2026-34984: External Secrets Operator DNS Leak Flaw

CVE-2026-34984 Overview

External Secrets Operator (ESO) is a Kubernetes operator that reads information from third-party secret management services and automatically injects the values as Kubernetes Secrets. A high-severity information disclosure vulnerability exists in versions 2.2.0 and below that allows attackers to exfiltrate secret material through DNS queries.

The vulnerability exists in runtime/template/v2/template.go where the v2 template engine removes env and expandenv from Sprig's TxtFuncMap() but leaves the getHostByName function accessible to user-controlled templates. Since ESO executes templates within the controller process, an attacker who can create or update templated ExternalSecret resources can invoke controller-side DNS lookups using secret-derived values. This creates a DNS exfiltration primitive, allowing fetched secret material to be leaked via DNS queries without requiring direct outbound network access from the attacker's workload.

Critical Impact

Secret material can be exfiltrated via DNS queries in environments where untrusted users can author templated ExternalSecret resources, bypassing traditional network security controls.

Affected Products

• External Secrets Operator versions 2.2.0 and below
• Kubernetes clusters running vulnerable ESO controller versions
• Environments where untrusted users can create or modify ExternalSecret resources

Discovery Timeline

• 2026-04-14 - CVE CVE-2026-34984 published to NVD
• 2026-04-14 - Last updated in NVD database

Technical Details for CVE-2026-34984

Vulnerability Analysis

This vulnerability represents a template injection weakness classified under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). The External Secrets Operator uses Sprig's template function map to provide templating capabilities for ExternalSecret resources. While security-conscious developers removed dangerous functions like env and expandenv from the available function map, the getHostByName function remained accessible.

The getHostByName function performs DNS resolution from within the controller process. An attacker can craft a malicious template that embeds secret values into DNS queries. Since DNS queries naturally traverse network boundaries and are often logged by DNS servers, this creates a covert channel for data exfiltration that bypasses traditional egress filtering controls.

Root Cause

The root cause is an incomplete security review of the Sprig template function map. When hardening the template engine, the developers correctly identified and removed env and expandenv as dangerous functions that could leak environment variables. However, the getHostByName function was overlooked. This function, while appearing benign for legitimate DNS lookups, can be weaponized to encode and transmit arbitrary data through DNS queries when combined with attacker-controlled template input that incorporates secret values.

Attack Vector

The attack requires network access and low privileges—specifically, the ability to create or update templated ExternalSecret resources within the Kubernetes cluster. An attacker constructs a malicious ExternalSecret template that:

1. Retrieves a secret value from the configured secret store
2. Encodes or embeds the secret value into a hostname string
3. Invokes getHostByName with this constructed hostname
4. The DNS query containing the secret data is sent to an attacker-controlled DNS server

This exfiltration technique is particularly effective because DNS traffic is often allowed through firewalls and the attacker doesn't need direct network access from their workload—the controller performs the DNS lookup.

 	sprigFuncs := sprig.TxtFuncMap()
 	delete(sprigFuncs, "env")
 	delete(sprigFuncs, "expandenv")
-
+	delete(sprigFuncs, "getHostByName")
 	maps.Copy(tplFuncs, sprigFuncs)
 	fs := pflag.NewFlagSet("template", pflag.ExitOnError)
 	fs.StringVar(&leftDelim, "template-left-delimiter", "{{", "templating left delimiter")

Source: GitHub Commit 6800989

The patch adds getHostByName to the list of deleted functions from the Sprig template function map, preventing its use in ExternalSecret templates and closing the DNS exfiltration vector.

Detection Methods for CVE-2026-34984

Indicators of Compromise

• Unusual DNS queries originating from the External Secrets Operator controller pod containing encoded data or suspicious hostnames
• ExternalSecret resources with templates containing getHostByName function calls
• DNS queries to external or unfamiliar DNS servers from the controller namespace
• Patterns of DNS queries that appear to encode base64 or hexadecimal data in subdomain labels

Detection Strategies

• Monitor DNS query logs from the ESO controller pod for anomalous patterns or queries to non-standard domains
• Implement Kubernetes admission controllers to scan ExternalSecret manifests for getHostByName usage in templates
• Deploy network policies to restrict DNS egress from the controller pod to known DNS servers only
• Use SIEM rules to correlate ExternalSecret creation events with subsequent unusual DNS activity

Monitoring Recommendations

• Enable verbose logging for the External Secrets Operator controller to capture template evaluation details
• Configure DNS query logging at the cluster or network level to track queries originating from controller pods
• Set up alerts for ExternalSecret resources created by non-administrative users that contain templating directives
• Monitor for bulk or rapid DNS queries from the ESO namespace which may indicate active exfiltration

How to Mitigate CVE-2026-34984

Immediate Actions Required

• Upgrade External Secrets Operator to version 2.3.0 or later immediately
• Audit existing ExternalSecret resources for any templates containing getHostByName function calls
• Review RBAC policies to restrict who can create or modify ExternalSecret resources
• Implement network policies to limit DNS egress from the ESO controller namespace

Patch Information

The vulnerability has been fixed in External Secrets Operator version 2.3.0. The patch removes the getHostByName function from the available Sprig template functions, preventing its use in ExternalSecret templates. Organizations should upgrade to this version or later to fully remediate the vulnerability.

For detailed patch information, see the GitHub Security Advisory GHSA-r2pg-r6h7-crf3 and the v2.3.0 Release.

Workarounds

• Restrict RBAC permissions for creating ExternalSecret resources to only trusted administrators until the patch is applied
• Implement Kubernetes admission webhooks (e.g., OPA Gatekeeper, Kyverno) to block ExternalSecret resources containing getHostByName in templates
• Apply network policies to prevent DNS queries from the ESO controller to external DNS servers
• Use read-only container file systems and strict securityContext settings to limit controller capabilities

# Configuration example
# Kyverno ClusterPolicy to block getHostByName in ExternalSecret templates
cat <<EOF | kubectl apply -f -
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-gethostbyname-externalsecrets
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: check-template-functions
    match:
      any:
      - resources:
          kinds:
          - ExternalSecret
    validate:
      message: "Templates containing getHostByName function are not allowed (CVE-2026-34984)"
      pattern:
        spec:
          target:
            template:
              data:
                "*": "!*getHostByName*"
EOF