Mar 6, 2026·5 min read·52 visits
CoreDNS < 1.14.2 evaluates ACLs before rewriting query names. Attackers can query an allowed domain that rewrites to a restricted internal domain, bypassing security controls.
A logical vulnerability in CoreDNS versions prior to 1.14.2 allows attackers to bypass access control lists (ACLs) via a Time-of-Check Time-of-Use (TOCTOU) flaw. The default plugin execution order processes security enforcement plugins (such as `acl`, `firewall`, and `opa`) before the `rewrite` plugin. Consequently, an attacker can query a permitted domain name that is subsequently rewritten to a restricted internal domain, bypassing the intended security policies and resolving the restricted target.
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:
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.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).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:fileFixed 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:fileThis 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:
DIG @target-server proxy.example.comproxy.example.com. The ACL allows this public domain. Code: Allowed.proxy.example.com → db.internal.kubernetes plugin looks up db.internal and finds the ClusterIP 10.96.0.50.The impact of this vulnerability is significant in multi-tenant or segmented network environments utilizing CoreDNS for service discovery.
Security Implications:
admin.* services), this bypass renders those controls ineffective against aliased domains.Severity Metrics:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
CoreDNS CoreDNS | < 1.14.2 | 1.14.2 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-367 (TOCTOU) |
| Attack Vector | Network |
| CVSS v3.1 | 7.7 (High) |
| Impact | ACL Bypass / Information Disclosure |
| Exploit Status | No Active Exploitation |
| Fixed Version | 1.14.2 |
An uncontrolled resource consumption vulnerability exists in the Scala-based http4s-blaze-server package of the http4s/blaze library. The vulnerability allows remote, unauthenticated attackers to cause an Out of Memory Error (OOM) and JVM crash by streaming a continuous sequence of small or empty WebSocket continuation frames with the FIN bit set to 0. This bypasses typical payload size checks because of the JVM's per-object allocation overhead, leading to rapid heap exhaustion with minimal network bandwidth.
A critical path traversal vulnerability has been identified in the OpenList Go-based backend package. The vulnerability exists within the batch rename handler because the application does not validate the source filename parameter before constructing filesystems paths. This omission allows authenticated users to escape their designated directory and rename files in sibling paths.
OpenList version 4.2.3 and prior is vulnerable to an authorization bypass and metadata leakage. When configured with the Bleve search engine backend, OpenList fails to perform separator-aware path matching when validating tenant containment. This allows authenticated users to access sibling directories sharing similar name prefixes. Furthermore, the search backend returns unfiltered global result counts, leaking existence verification data of unauthorized files via side-channel analysis.
An authorization bypass vulnerability in OpenList version 4.2.3 and below allows authenticated users to read arbitrary files outside of their designated base directories due to an insecure path prefix check using Go's standard strings.HasPrefix function.
A security policy bypass vulnerability exists in the AWS API MCP Server (awslabs-aws-api-mcp-server) from version 0.2.13 through 1.3.46. When the server fails to load the read-only operations index during startup (due to transient network failures, file permission issues, or other exceptions), it logs a warning but continues running in an insecure, degraded state. Under this condition, the security policy engine fails open, silently skipping all subsequent security checks and consent prompts for the lifetime of the process. This permits unauthorized mutating AWS CLI commands to execute via indirect prompt injection attacks.
An incomplete escaping vulnerability in the npm package 'shescape' allows unauthenticated users to trigger dynamic shell expansions, absolute path disclosure, and command block break-outs on Unix and Windows systems.