CVE-2024-0874 CoreDNS CD Bit Cache Bug: Risks in Azure Linux and AKS

CoreDNS’s CVE-2024-0874 — a caching bug that can cause responses fetched with the DNS CD (Checking Disabled) flag to be stored and later served to queries missing that flag — is a real, practical risk for any environment that runs CoreDNS. The vulnerability was disclosed upstream in April 2024, fixed in CoreDNS releases, and tracked by distributors; Microsoft’s public advisory notes that Azure Linux has been identified as a product that includes the affected component and is potentially affected, but that attestation is product-scoped and not, by itself, proof that other Microsoft products are free of the code. (github.com)

Background / Overview​

CoreDNS is the de‑facto DNS server for Kubernetes and a common DNS resolver/caching component in cloud-native stacks. The bug assigned CVE‑2024‑0874 comes from CoreDNS’s cache behavior: when the query has the CD bit set (requests that the resolver not perform DNSSEC validation), CoreDNS could cache the resulting answer and later serve that same cached entry to queries that do not have the CD bit set — thereby returning an answer that should have been validated. The behavior violates DNSSEC expectations in RFC 4035 and can let an attacker, under some conditions, bypass DNSSEC protections for cached responses. (github.com)
Red Hat and several downstream trackers gave this issue a Medium severity (CVSS v3.1 ≈ 5.3). Upstream maintainer activity and a corrective pull request implemented separate cache keys (or separate caches) for CD and non‑CD queries to avoid mixing validated and unvalidated answers; fixed CoreDNS releases were published as part of the normal CoreDNS release process. (nvd.nist.gov)

---

What CVE‑2024‑0874 actually does — technically​

The CD bit and cache semantics​

• The CD (Checking Disabled) bit is a flag a DNS resolver can set in a query to ask an upstream validating resolver not to perform DNSSEC validation for that particular query.
• CoreDNS incorrectly used the same cache key for responses regardless of whether the CD bit was present, so a response obtained with CD set (and thus not validated) could be cached and later returned to a query that expected validation. This is primarily an integrity weakening rather than a code‑execution or remote takeover flaw, but the integrity impact can be material depending on the client and the attacker’s capabilities. (github.com)

Exploitability and impact profile​

• The vulnerability is network‑accessible and does not require privileges or user interaction, which increases practical exposure when CoreDNS is deployed as a public‑facing resolver or inside multi‑tenant clusters where attackers can issue queries. However, actual exploitation requires the attacker to control or influence queries to the resolver and timing to “prime” the cache with an unvalidated response and then observe or cause victim queries. The practical impact is context‑dependent: in many environments the risk is low, but in environments relying on DNSSEC for integrity where CoreDNS is an in‑path resolver, the risk is non‑negligible. (nvd.nist.gov)

---

Where CoreDNS appears in Microsoft’s cloud ecosystem​

It’s important to separate two different classes of products and artifacts:

• Product artifacts Microsoft ships (for example, the Azure Linux distribution images and kernel packages Microsoft builds and publishes).
• Managed services and customer workloads that run third‑party software (for example, AKS clusters that run CoreDNS as a Kubernetes addon or pods inside user clusters).

Microsoft’s public statement on the CVE specifically attests that Azure Linux was found to include the implicated open‑source library and is therefore potentially affected. That attestation reflects Microsoft’s product inventory for Azure Linux at the time of their VEX/CSAF publication; Microsoft has also said it will update the CVE record if additional Microsoft products are found to ship the component. That phrasing is a deliberate, product‑scoped inventory statement, not an exhaustive claim that no other Microsoft product could contain the same open‑source code. (msrc.microsoft.com)
At the same time, many Microsoft‑delivered services and images interact with CoreDNS in practice:

• Azure Kubernetes Service (AKS) uses CoreDNS as the default in‑cluster DNS provider. CoreDNS runs as pods in the kube‑system namespace and is how pods and services resolve in‑cluster names; AKS supports customizing and autoscaling CoreDNS and manages the lifecycle of the addon in managed clusters. For any customer running AKS, CoreDNS will be present inside the cluster unless explicitly replaced.
• Marketplace images, node images, and container host images shipped by Microsoft may include CoreDNS packages or run environments where CoreDNS appears as a container image — for example, images used as base for orchestrator nodes, or for lab and appliance images. Whether a given Microsoft image contains the vulnerable code depends on what packages were installed and what images were deployed.
• Other Microsoft Linux artifacts — the Windows Subsystem for Linux (WSL2) kernel, CBL‑Mariner artifacts, and specialized Azure host images — are separate builds and must be inventoried independently. Microsoft’s initial VEX rollout began with Azure Linux and is being expanded; absence of an attestation for WSL, CBL‑Mariner, or other artifacts is not a technical proof of absence of the vulnerable component.

Putting that another way: Azure Linux is the one Microsoft product Microsoft has publicly attested includes the library for this CVE; however, other Microsoft products or services that run containerized or packaged CoreDNS in customer‑facing workloads — notably AKS clusters — will also have CoreDNS present in operation. The attestation covers Azure Linux artifacts specifically and Microsoft’s public cadence is to expand VEX/CSAF coverage over time. (msrc.microsoft.com)

---

Is Azure Linux the only Microsoft product that could be affected?​

Short answer: No, not necessarily. Azure Linux is the only Microsoft product Microsoft has publicly attested (via CSAF/VEX) as including the component for CVE‑2024‑0874 at the time of their attestation, but that statement does not exclude other Microsoft‑shipped artifacts or services from containing the same open‑source code. Any Microsoft product that ships or runs CoreDNS — whether as a package, an image, or as a managed addon inside a service — is potentially in scope until verified by a vendor attestation or an artifact inspection. (msrc.microsoft.com)
Why that distinction matters:

• Microsoft’s CSAF/VEX rollout is phased; starting with Azure Linux makes sense because it’s the company’s canonical Linux distribution lineage to inventory. Microsoft explicitly promised to update CVE entries and VEX attestations if they find additional products that carry the component. That approach improves automation and reduces false positives for customers, but it also means product inventories expand over time.
• For managed services like AKS, CoreDNS is deployed into customer clusters as an operational component; Microsoft’s product attestation about the Azure Linux distribution is separate from the managed runtime components that exist inside a customer’s AKS cluster. An organization running AKS should therefore treat CoreDNS within their clusters as a surface to inspect and patch, independent of Microsoft’s product‑by‑product VEX statements.

---

Practical detection: how to know if you run the affected component​

If you manage cloud infrastructure or container platforms, these checks will quickly tell you whether CoreDNS is present and whether an affected version is running.

• Kubernetes / AKS
• Check for CoreDNS pods and image versions:
• kubectl get pods -n kube-system | grep coredns
• kubectl -n kube-system get deployment coredns -o yaml (inspect spec.template.spec.containers[].image and annotations)
• Inspect the CoreDNS image tag: many distributions publish images like coredns/coredns:1.11.x. If the image tag is older than the fixed release (or if the image digest matches a known vulnerable version), plan to update. AKS documentation explains how CoreDNS is configured and how to autoscale or replace it.
• Linux images and VM artifacts (Azure Linux, CBL‑Mariner, Marketplace images)
• Inspect installed packages (rpm / dpkg) or the image’s SBOM (where available). Microsoft’s CSAF/VEX attestations and distribution advisories will explicitly list affected package versions for Azure Linux artifacts. If you run Azure Linux images, follow Microsoft’s VEX/CSAF guidance and the distro’s package updates.
• Container registries and CI build pipelines
• Search registries for coredns images (by name/digest) used in deployments and CI manifests. Check Helm charts, Kustomize overlays and operators that may pull CoreDNS images.

If you cannot find CoreDNS running in any of the above places, you are likely not directly affected in that environment — but always confirm for each environment, node image and container image individually because CoreDNS commonly appears as a small pod/daemonset that is easy to overlook.

---

Remediation and mitigations — prioritized, actionable steps​

• Inventory first (fast triage)
• Identify every Kubernetes cluster (AKS and self‑managed) and run the detection checks above.
• Identify all Azure Linux images and any Microsoft‑supplied VM or container images you operate.
• Request Microsoft VEX/CSAF attestations for additional product SKUs if you require vendor confirmation for your specific artifacts.
• Apply the upstream fix
• Upgrade CoreDNS to a patched release. Upstream fixes were merged and fixed releases were published; many trackers and vendors recommend upgrading to a fixed release (CoreDNS 1.11.2 or later where the caching key behavior was corrected). If you run CoreDNS as a pod, update the coredns image in the kube‑system deployment and roll the update.
• For AKS (managed clusters)
• Follow AKS guidance for CoreDNS addon updates or replace the coredns deployment with a custom image that includes the patch. AKS also supports autoscaling CoreDNS — ensure your autoscaler is up to date and that CoreDNS pods are running an updated, patched image. Test in staging before rolling to production.
• For Azure Linux and Microsoft images
• Apply Microsoft’s Azure Linux package updates as they are released and monitor MSRC VEX/CSAF updates for the CVE to see which artifacts were declared “Known Affected” and which are “Fixed.” Microsoft has committed to updating the attestation if they find additional artifacts. (msrc.microsoft.com)
• Mitigations if you can’t immediately patch
• Short‑term: reduce the attack surface by limiting who can query resolvers (network ACLs, firewall rules), and avoid exposing resolvers to untrusted networks.
• Consider adding an upstream validating resolver before CoreDNS or configure CoreDNS with stricter caching policies while you apply updates (note: these are stop‑gap mitigations and may not fully eliminate the problem).
• Verify remediation
• After updating, validate that CoreDNS pods are running the patched images and that cache behavior is split on CD/no‑CD cases (functional tests can reproduce the original issue in a controlled test cluster). Upstream test reproducers and the GitHub issue contain helpful reproduction steps. (github.com)

---

Why Microsoft’s attestation approach matters — strengths and limits​

Microsoft’s adoption of machine‑readable CSAF and VEX attestations is a material improvement in vendor transparency. The rollout — beginning with Azure Linux — gives customers machine‑friendly signals about which Microsoft artifacts include specific open‑source components and whether those artifacts are Known‑Affected, Fixed, or Under‑Investigation. That reduces noise for security teams and helps automate triage at scale.
That said, there are important caveats:

• Attestation is product‑scoped. A VEX file is an authoritative statement about the specific product artifact it covers — it does not automatically cover other binaries, container images, or service runtimes Microsoft produces unless they have also been inventoried and attested. Treat a “not mentioned” product as unknown, not as “safe.”
• Phased rollouts can create gaps. Vendor inventory projects usually progress in waves; customers must combine vendor attestations with their own artifact inspection and runtime telemetry rather than relying solely on vendor statements.

Bottom line: Microsoft’s pledge to publish CSAF/VEX is a win for defenders, but customers must still perform inventory, scanning and runtime checks to be sure every environment is covered.

---

Risk analysis — what defenders should prioritize​

• If you run Azure Linux images, treat Microsoft’s attestation as authoritative and patch accordingly: apply the Azure Linux updates and monitor the VEX/CSAF file for the CVE for the exact affected artifact identifiers and fix status. Microsoft expressly said it will update the CVE/VEX mapping if it finds additional affected products. (msrc.microsoft.com)
• If you run AKS or other Kubernetes environments, assume CoreDNS is present and take action to inventory and update your CoreDNS deployments. Managed services often expose CoreDNS to tenant queries and many customers run DNS‑facing workloads; remediation here should be a high priority.
• If you run third‑party or custom images derived from Microsoft artifacts (CBL‑Mariner derivatives, marketplace images, oven‑baked appliances), verify SBOMs and package inventories or request attestation from Microsoft if you need vendor confirmation.

---

Final assessment and recommendations​

CVE‑2024‑0874 is a medium‑severity integrity issue in CoreDNS that can materially weaken DNSSEC guarantees in affected deployments. The technical fix is straightforward and available upstream; the operational challenge is ensuring every environment that runs CoreDNS — whether in a managed service like AKS, an Azure Linux image, or an on‑premises cluster — is identified and updated.
Microsoft’s statement that Azure Linux is the product they have identified and attested as including the open‑source component is accurate as a product inventory statement and reflects their phased VEX rollout; however, that does not guarantee that no other Microsoft product contains the same code. Customers must therefore:

• Inventory Kubernetes clusters and check CoreDNS image versions (AKS clusters are an immediate, high‑value target for inspection).
• Patch CoreDNS to the fixed upstream release or apply vendor patches where CoreDNS is packaged by distributions.
• Use Microsoft’s CSAF/VEX attestations as authoritative signals for the products they cover, but combine vendor attestations with artifact inspection, SBOM analysis, and runtime telemetry for full coverage.

If you manage Azure Linux images, follow Microsoft’s package updates and VEX files for the exact artifact identifiers Microsoft lists as affected or fixed. If you operate AKS or other Kubernetes clusters, prioritize discovering and upgrading CoreDNS pods in every cluster you run. Treat the MSRC attestation as a useful piece of the puzzle — not the whole puzzle — and incorporate it into a broader, artifact‑centric vulnerability management workflow. (msrc.microsoft.com)

---

For security teams: begin with an inventory sweep for CoreDNS (kube‑system pods, container registry images, image SBOMs), confirm the running version against fixed versions, and schedule a rolling update for CoreDNS in all clusters. For Azure Linux operators: apply Microsoft’s published updates and monitor the MSRC VEX/CSAF entry for any expansion of the attestation to other Microsoft products. Above all, combine vendor attestations with concrete artifact checks — that is the defensible way to manage supply‑chain‑adjacent vulnerabilities like CVE‑2024‑0874. (github.com)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center