A caching bug in CoreDNS, tracked as CVE-2024-0874, undermines DNSSEC validation and could expose cloud workloads to malicious redirection. Microsoft has identified Azure Linux as affected, but security researchers and the project’s own issue tracker make clear that the vulnerability extends to any environment running vulnerable CoreDNS versions—including Azure Kubernetes Service (AKS) clusters, where CoreDNS is the default DNS provider. The good news? Patches are available, and a few practical steps will show whether your systems need attention.

The Bug: When Cache Trumps Validation

CoreDNS uses a cache to speed up DNS lookups. When a query arrives with the CD (Checking Disabled) bit set—telling the resolver not to perform DNSSEC validation—the response was stored in the cache under the same key as a response fetched without that bit. Later, a query expecting DNSSEC protection could be served the unvalidated cached answer, effectively bypassing DNSSEC integrity checks.

This violates RFC 4035. It means an attacker who can inject a rogue response into the cache—for instance, by issuing a CD-tagged query first—could later redirect a victim to a malicious site, even in configurations that rely on DNSSEC for authenticity.

The technical impact is purely an integrity weakness. There’s no code execution or remote takeover. But the practical risk is real in any environment where CoreDNS acts as an in-path resolver for clients that expect DNSSEC validation. The vulnerability scored a 5.3 (Medium) on the CVSS v3.1 scale because it requires no privileges or user interaction and is network-accessible, though exploitation depends on timing and control over queries.

Upstream maintainers fixed the issue on April 26, 2024, by introducing separate cache keys for CD and non-CD queries. The patch landed in CoreDNS 1.11.2, and later releases include the fix. The original issue was reported on GitHub, where a detailed reproduction and discussion took place.

Who’s at Risk: It’s Not Just Azure Linux

On May 22, 2024, Microsoft’s Security Response Center (MSRC) published a CSAF/VEX advisory confirming that Azure Linux includes the vulnerable CoreDNS component. That attestation covers Azure Linux images and packages—it’s a precise, product-scoped statement.

But the advisory does not claim that other Microsoft products are immune. In fact, Microsoft explicitly says it will update the CVE record if additional affected products are discovered. That’s a deliberate choice: the VEX rollout began with Azure Linux, but the company’s own managed services and open‑source artifacts may also carry CoreDNS.

AKS is the most glaring example. Every AKS cluster deploys CoreDNS by default as the in‑cluster DNS server. It runs as a pod in the kube-system namespace and resolves all pod‑to‑service lookups. Unless an administrator has deliberately replaced it, CoreDNS is listening to queries from every workload in the cluster—including potentially untrusted tenants in a multi‑tenant setup.

Other Microsoft‑supplied artifacts could be affected too:
- Marketplace and node images: Linux VMs and container host images may ship CoreDNS packages or run CoreDNS as a sidecar.
- CBL‑Mariner derivatives: Code‑sharing means the same vulnerable component might appear in WSL2 kernels, specialized Azure host images, or lab appliances.
- Managed runtimes: Even when CoreDNS isn’t distributed as a package, it’s pulled as a container image during AKS node provisioning.

Absence from Microsoft’s current advisory isn’t proof of safety. It’s an invitation to inventory your own environments.

The Wider Cloud Picture

CoreDNS isn’t just a Microsoft concern. It’s the default DNS for Kubernetes everywhere—Red Hat OpenShift, Google Kubernetes Engine, Amazon EKS, and countless on‑premises clusters. Upstream fixes are available, but distribution‑specific patches and container image updates can lag. Red Hat, for instance, rated the same flaw as Medium severity and shipped fixes in their CoreDNS packages.

Microsoft’s phased approach to VEX attestations is a step forward. Machine‑readable security advisories let automated tools consume vulnerability data and reduce false positives. The CSAF document for CVE-2024-0874 clearly lists affected Azure Linux package identifiers. For Azure Linux operators, the advisory is authoritative: apply the listed package updates and the risk is mitigated.

For everyone else—especially AKS customers—the advisory is only a starting point. Microsoft’s VEX attestation doesn’t yet cover the CoreDNS images that run inside AKS clusters. That means the managed service’s own update mechanisms aren’t automatically triggered by the advisory. You must take manual action or await expanded coverage.

How to Check and Fix Your CoreDNS Deployments

Start with an inventory. The commands below will identify CoreDNS presence and version.

In any Kubernetes cluster (including AKS) 

kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl -n kube-system get deployment coredns -o yaml | grep image:

The output shows the CoreDNS image tag. Compare it against the fixed versions: 1.11.2 or later. If the image is older, you’re vulnerable.

On Azure Linux VMs or VM scale sets 

rpm -qa | grep coredns   # For RPM-based systems
dpkg -l | grep coredns   # For Debian/Ubuntu-based

Check the installed version against Microsoft’s advisory. For Azure Linux, the appropriate package update channel will deliver the fix automatically once it’s available; you can fetch it with tdnf update (for Azure Linux 3.0) or dnf update (for earlier versions).

In container registries

Scan your registries for CoreDNS images by name or digest. If you use Helm charts or custom manifests, look for references to coredns/coredns images. Update the tag to a patched release or pull a new digest.

Update AKS clusters

Microsoft documents the CoreDNS add‑on lifecycle for AKS. You can update the CoreDNS image through the Azure CLI or by editing the coredns deployment in the cluster. Test in a staging cluster first:

kubectl set image deployment/coredns -n kube-system coredns=coredns/coredns:1.11.2

AKS also supports autoscaling CoreDNS; ensure your autoscaler configuration is preserved after the update. For managed clusters, check whether Microsoft has released a new AKS node image that bundles a patched CoreDNS sidecar—though the primary fix is the pod image itself.

Mitigations if patching is delayed

  • Restrict network access: use firewall rules or Kubernetes NetworkPolicies to limit which pods can reach CoreDNS. Avoid exposing the CoreDNS service to untrusted networks.
  • Insert an upstream validating resolver: if your architecture allows, configure CoreDNS to forward to a resolver that performs strict DNSSEC validation. This won’t fix the cache poisoning, but it can catch invalid responses before they reach clients.
  • Reduce cache TTLs: temporarily lower the cache duration to shrink the window for exploitation. This is a stop‑gap, not a solution.

Verify the fix

After updating, run a functional test. The original GitHub issue includes a reproduction script: send a CD‑less query, then a CD‑tagged query for the same name, and verify that the cache doesn’t mix responses. A simple dig test in a test pod can confirm DNSSEC behavior.

What Comes Next

Microsoft’s VEX coverage will likely expand. The CSAF attestation engine is new, and the company has publicly committed to rolling out machine‑readable advisories for more of its open‑source artifacts. Keep an eye on the MSRC update guide for CVE-2024-0874; new product entries will appear there.

But waiting for an expanded advisory isn’t a strategy. CoreDNS will remain a critical DNS component in Kubernetes for the foreseeable future. As cloud‑native adoption grows, so does the attack surface of DNS infrastructure. CVE-2024-0874 is a medium‑severity flaw with a straightforward fix—it’s not the sort of bug that should linger in production clusters.

If you manage any environment running CoreDNS—whether on Azure Linux, AKS, or another platform—the time to inventory and upgrade is now. The upstream fix is tested and available, and the steps are well‑documented. Treat Microsoft’s advisory as a helpful signal, but don’t mistake its current scope for a clean bill of health for everything you run.