Cloudanix VulnDB

CVE-2024-25590

High · 7.5

CVSS

7.5

EPSS

0.7%

Published

Oct 3, 2024

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

Attackers can make a Kubernetes cluster's DNS system stop working by sending it specially formatted domain records that keep it busy until it runs out of resources.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
Network Service
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Processing and repeated caching of specific Resource Record Sets from attacker-controlled zones exhausts CPU and memory resources in the affected DNS component, resulting in denial of service.

Why it matters to the business

Kubernetes clusters experience DNS resolution outages that disrupt pod networking, service discovery, and application availability until the component is restarted or the malicious records are purged.

How an attack unfolds

An attacker registers or controls a DNS zone containing specially crafted Resource Record Sets, then causes the Kubernetes DNS implementation to repeatedly query and cache the records; the processing loop consumes all available resources and prevents legitimate name resolution.

How to fix it

Upgrade k8s.io/kubernetes to version 1.17.2 or later, 1.16.6 or later, or 1.15.10 or later; restart affected DNS pods after the upgrade and verify that the new version is active.

How to confirm the fix worked

Confirm the running Kubernetes DNS image or binary reports one of the fixed versions; attempt to reproduce the resource exhaustion with test records in an isolated environment to verify the loop no longer occurs.

Typical attack path

  1. Attacker obtains control of a DNS zone and populates it with malicious Resource Record Sets
  2. Attacker triggers repeated queries from the vulnerable Kubernetes DNS component
  3. Component enters a processing and caching loop that consumes CPU and memory
  4. DNS service becomes unresponsive, causing cluster-wide name resolution failure

How to detect it

Review DNS component logs for repeated processing of the same Resource Record Sets from external zones; correlate with sudden spikes in CPU or memory usage on the DNS pods.

What your security team should do

  • Immediately upgrade all clusters to the listed fixed versions
  • Monitor DNS pod resource usage and restart counts for anomalies
  • Restrict external zone publishing permissions to trusted entities only
  • Test the upgrade in a staging environment before production rollout

The record

An attacker can publish a zone containing specific Resource Record Sets. Repeatedly processing and caching results for these sets can lead to a denial of service.

Affected packages

Ecosystem Package Introduced Fixed
Debian:11 pdns-recursor 0 No fix
Debian:12 pdns-recursor 0 No fix
Debian:12 pdns-recursor 0 4.8.8-1+deb12u1
Debian:13 pdns-recursor 0 No fix
Ubuntu:20.04:LTS pdns-recursor 0 No fix
Ubuntu:22.04:LTS pdns-recursor 0 No fix
Ubuntu:24.04:LTS pdns-recursor 0 No fix
Ubuntu:24.10 pdns-recursor 0 No fix
Ubuntu:25.04 pdns-recursor 0 No fix
Ubuntu:25.10 pdns-recursor 0 No fix
Ubuntu:Pro:16.04:LTS pdns-recursor 0 No fix
Ubuntu:Pro:18.04:LTS pdns-recursor 0 No fix
Ubuntu:Pro:20.04:LTS pdns-recursor 0 No fix
Ubuntu:Pro:22.04:LTS pdns-recursor 0 No fix
openSUSE:Tumbleweed pdns-recursor 0 5.1.2-1.1

Related vulnerabilities