CVE-2026-26017: CoreDNS ACL Bypass via TOCTOU in Plugin Chain

CoreDNS is a modular DNS server widely used in cloud-native environments, particularly Kubernetes, where it serves as the cluster DNS provider. Its architecture relies on a chain of plugins (middleware) to process DNS queries sequentially. Each plugin inspects, modifies, or answers the query before passing it to the next plugin in the chain. The execution order is statically defined at compile time via a plugin.cfg file.

In versions prior to 1.14.2, the default configuration placed security enforcement plugins—specifically acl, firewall, and opa—earlier in the execution chain than the rewrite plugin. This ordering created a logical flaw: the authorization decision was based on the initial query name (Time-of-Check), while the actual resolution occurred on a modified query name (Time-of-Use) after the rewrite plugin had altered the request.

This discrepancy allows an attacker to exploit the rewrite rules to access restricted records. By crafting a DNS query for a domain that is permitted by the ACL but explicitly rewritten to a restricted domain (e.g., an internal service or sensitive infrastructure), the attacker can successfully resolve the restricted target, effectively bypassing the access control layer.

The root cause is a Time-of-Check Time-of-Use (TOCTOU) race condition (CWE-367) inherent in the static plugin ordering defined in plugin.cfg. In CoreDNS, the order of lines in plugin.cfg dictates the order of Handler registration in the compiled binary. The vulnerable configuration prioritized acl over rewrite.

The processing pipeline functioned as follows:

1. Authorization (Check): The acl plugin receives the dns.Msg structure. It inspects the Question section (QNAME) against its configured rules. If the QNAME matches an allow list (or fails to match a block list), the plugin calls next.ServeDNS() to pass control down the chain.
2. Mutation (Use): The rewrite plugin receives the request. It matches the QNAME against rewrite rules. If a match is found, it modifies the QNAME in place within the dns.Msg structure (e.g., changing public-proxy.example.com to admin-panel.internal).
3. Resolution: Backend plugins (like kubernetes, etcd, or file) receive the modified request. They resolve the new QNAME (admin-panel.internal) and return the IP address.

Because the acl plugin does not re-verify the request after it returns from the chain (or before the backend resolves it), the security context established at step 1 is invalid for the parameters used at step 3. The system effectively authorizes the alias but resolves the target.

The vulnerability is not a syntax error in Go code but a semantic error in the build configuration plugin.cfg. Below is a conceptual comparison of the vulnerable vs. fixed execution order.

Vulnerable Configuration (Conceptual)

The acl plugin runs before rewrite. The query passes the security check before it is transformed.

# plugin.cfg (Vulnerable)
 
# Security plugins execute first
acl:acl
firewall:firewall
 
# ... intermediary plugins ...
 
# Mutation plugins execute later
rewrite:rewrite
 
# Backend resolution
kubernetes:kubernetes
file:file

Fixed Configuration (CoreDNS v1.14.2)

The fix involves moving rewrite (and other normalization plugins like template) before the security plugins. This ensures that the ACL checks are applied to the final, normalized state of the query.

# plugin.cfg (Fixed)
 
# Mutation/Normalization executes first
rewrite:rewrite
 
# Security plugins execute on the transformed query
acl:acl
firewall:firewall
 
# Backend resolution
kubernetes:kubernetes
file:file

This reordering ensures that if rewrite changes public.com to private.internal, the acl plugin sees private.internal and correctly blocks the request based on the policy for the internal domain.

An attacker can exploit this vulnerability in environments where CoreDNS is configured with both ACLs (to restrict access to internal names) and Rewrites (to map external aliases to internal names). Consider a Kubernetes cluster where *.internal is restricted to authorized pods, but proxy.example.com is publicly resolvable and rewrites to db.internal.

Attack Steps:

1. Reconnaissance: The attacker identifies a rewrite rule. This might be known via open-source configuration repositories, leaked config maps, or inferred by observing DNS behavior.
2. Crafting the Query: The attacker sends a standard DNS query for the allowed alias: DIG @target-server proxy.example.com
3. Bypass Execution:
   • ACL Check: CoreDNS checks proxy.example.com. The ACL allows this public domain. Code: Allowed.
   • Rewrite: CoreDNS transforms proxy.example.com → db.internal.
   • Resolution: The kubernetes plugin looks up db.internal and finds the ClusterIP 10.96.0.50.
4. Result: The attacker receives the IP address of the restricted database service, bypassing the intended network segmentation.

The impact of this vulnerability is significant in multi-tenant or segmented network environments utilizing CoreDNS for service discovery.

Security Implications:

• Network Reconnaissance: Unprivileged users can enumerate internal infrastructure layout and service IP addresses.
• Access Control Bypass: In environments using DNS as a control plane (e.g., preventing access to admin.* services), this bypass renders those controls ineffective against aliased domains.
• Cloud Native Risk: In Kubernetes, this can facilitate lateral movement. If an attacker compromises a pod with limited DNS permissions, they can leverage this flaw to resolve addresses for sensitive services (like the API server or internal databases) that should be hidden from that pod's namespace.

Severity Metrics:

• CVSS v3.1: 7.7 (High). The vulnerability is network-accessible (AV:N), low complexity (AC:L), and requires low privileges (PR:L). The scope is changed (S:C) because the DNS server facilitates access to other components in the infrastructure.
• Confidentiality: High. The flaw directly leaks the existence and location of restricted resources.