CVE-2024-8508

What it actually does

Unbounded CPU consumption during name compression of very large RRsets in downstream DNS replies, allowing a single malicious upstream response to lock the resolver thread until packet processing completes.

Why it matters to the business

DNS resolution service becomes unavailable or severely degraded under sustained attack, disrupting all dependent applications, authentication, and network connectivity until the resolver is restarted or the attack stops.

How an attack unfolds

An attacker first creates or compromises a DNS zone containing records with extremely large RRsets, then issues queries through the target Unbound instance. Unbound fetches the malicious responses from upstream and enters an unbounded name-compression loop before replying, exhausting CPU and preventing service of other clients.

How to fix it

Upgrade nlnetlabs/unbound to version 1.21.1 or apply commit b7c61d7cc256d6a174e6179622c7fa968272c259. After upgrade, restart the service and verify the new hard limit on compression operations is active.

How to confirm the fix worked

Confirm running version is 1.21.1 or later via unbound -V. Perform load testing with queries that trigger large RRsets and verify CPU usage remains bounded and responses are either semi-compressed or truncated rather than causing long lockups.

Typical attack path

1. Attacker registers or takes control of a domain and populates it with records containing very large RRsets.
2. Attacker sends crafted queries to the victim Unbound resolver requesting those records.
3. Unbound contacts upstream authoritative servers, receives the oversized responses, and begins name compression.
4. Compression loop runs to completion without limit, holding the worker thread and starving other queries.
5. Repeated queries cause progressive CPU exhaustion leading to denial of service.

How to detect it

Correlate high sustained CPU on the Unbound process with incoming queries for domains known to host large RRsets. Examine resolver logs for repeated requests that produce unusually large or truncated responses and check system performance counters for worker-thread starvation.

What your security team should do

• Immediately schedule upgrade of all Unbound instances to 1.21.1.
• Place Unbound behind rate-limiting or query-filtering layers until patched.
• Monitor CPU utilization and queue depths on resolver hosts for early signs of resource exhaustion.
• Review and tighten upstream ACLs or response-size limits where operationally feasible.