Critical BIND 9 DNS Bug Lets Attackers Crash Servers Remotely—Patch Now

A remotely exploitable flaw in the widely used BIND 9 DNS server software can be triggered by a single client query, causing the named process to crash and knock entire networks offline. The vulnerability—tracked as CVE-2024-4076—earned a 7.5 severity score and was publicly disclosed on July 23, 2024 by the Internet Systems Consortium (ISC). It affects multiple versions in the 9.16, 9.18, and 9.19 branches, and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added it to its Known Exploited Vulnerabilities catalog.

What Actually Changed: The Bug in Plain English

BIND 9 supports a feature called serve-stale that lets the resolver return cached DNS records that have expired or are unreachable from upstream servers while it attempts a background refresh. This keeps name resolution working during brief outages. The flaw surfaces when a query simultaneously triggers serve-stale behavior and requires a lookup in the server’s local authoritative zone data. A logic error in that intersection causes an assertion failure, immediately terminating the named daemon.

“The vulnerability arises from a logic error in code paths that combine serving stale cached data with queries requiring local authoritative zone lookups,” the ISC advisory states. No authentication is needed; a remote attacker can send a crafted query and crash the server.

Affected Versions

Upstream BIND 9 versions are vulnerable in these ranges:

Operators running unsupported 9.16 versions must upgrade to a patched 9.18 or 9.20 release immediately. Many downstream Linux distributions, including Debian, Ubuntu, Red Hat, and SUSE, have issued their own security errata that map to these upstream fixes. Oracle Linux and others followed suit in the days after disclosure.

What It Means for You

For Home Users and Small Offices

The risk is lower but not zero. If you run a local DNS resolver—for example, a Raspberry Pi running Pi-hole with BIND as the upstream—and you have not updated in months, you are vulnerable. Unpatched consumer routers that embed BIND could also be affected, though most consumer gear uses dnsmasq or other lightweight resolvers. Check with your router manufacturer if you suspect BIND is in use, and apply any available firmware updates.

For IT Administrators and Enterprise Networks

This is a high-priority patching item. BIND powers a huge number of authoritative and recursive DNS servers inside enterprises, cloud environments, and ISPs. A single crash can bring down internal name resolution, break Active Directory, delay email, and disrupt access to web applications. Internet-facing recursive resolvers are the most exposed, but internal servers are still at risk from malicious insiders or compromised hosts.

“DNS is foundational; a crash in a named instance cascades through dependent services,” said a security engineer who works with large BIND deployments. “Even a few minutes of downtime during business hours can cause significant operational pain.”

If you use managed DNS through a third party, verify that your provider has patched. Many major providers updated quickly, but do not assume automatic coverage.

For Developers and Appliance Vendors

Check any container images, virtual appliances, or embedded devices that ship with BIND. Many IoT and networking products bundle older BIND versions that fall into the affected range. A device that runs a DNS cache for local network clients—such as a firewall or UTM appliance—may have named listening on the LAN interface. If you produce such devices, rebuild your firmware with the fixed libraries and push updates to customers.

How We Got Here: The Serve-Stale Trade-Off

Serve-stale was introduced to improve resilience. When a cache entry expires and the upstream server is unreachable, BIND can return the last-known good answer while trying to refresh in the background. This prevents client-side resolution failures during transient network blips. The feature gained traction after the 2016 Dyn DDoS attacks, when operators looked for ways to keep DNS working even when upstream infrastructure struggled.

But the feature added complexity to BIND’s query-processing code. CVE-2024-4076 is not a cryptographic vulnerability or a cache-poisoning bug; it is a logic error that slipped past testing. The ISC credited an external reporter for the discovery, though the researcher’s name was not immediately public.

BIND has a long history of assertion failures leading to denial-of-service. In 2023, CVE-2023-3341 and CVE-2023-4236 were similar bugs that caused crashes when parsing specific DNS responses. The industry has learned that even mature software can harbor flaws that are trivially weaponizable. This one is particularly dangerous because it can be triggered by a client query—meaning the attacker doesn’t need to control an upstream server or poison the cache, only send a single packet.

What to Do Now: Step-by-Step Guidance

1. Inventory Your BIND Instances (First 24 Hours)

Identify every named process in your infrastructure. Check VMs, containers, physical servers, and cloud instances. Use your configuration management tooling or run:

named -v

Compare the output against the version table above. Also check package managers: dpkg -l bind9, rpm -q bind, or equivalent.

2. Patch Immediately if You Run an Affected Version

• Upstream: Upgrade to BIND 9.18.28 or later, or 9.20.0 or later. If you are stuck on 9.16, you must migrate to a supported branch.
• Downstream: Apply your distribution’s security update. For example, Ubuntu users should run apt update && apt upgrade bind9. RHEL-based systems can use yum update bind. Restart named after the update.

3. If You Cannot Patch Right Away: Disable Serve-Stale

This mitigation eliminates the overlapping code path. Edit your named.conf and remove or set to off any serve-stale configurations. Specifically, ensure these options are not set to yes or a positive TTL:

serve-stale off;
max-stale-ttl 0;
stale-answer-client-timeout off;

Reload the configuration: rndc reconfig. Note that this will stop returning stale answers during upstream outages, potentially increasing client-side resolution failures. Weigh that against the risk of a crash.

4. Reduce Exposure with Access Controls

If your resolver must remain exposed, restrict which clients can query it. Use ACLs in BIND or firewall rules. For example:

acl trusted { 192.168.0.0/16; localhost; };
options {
    allow-query { trusted; };
    allow-recursion { trusted; };
};

This limits the attack surface to trusted networks only.

5. Verify and Monitor Post-Patch

After updating, monitor logs for assertion failures or unexpected terminations. Increase telemetry on DNS server health metrics. If using systemd, watch for: journalctl -u named -f. Ensure core dumps are disabled (they should be by default) to avoid filling disks during a crash event.

6. Harden Your DNS Architecture for the Long Term

• Incorporate BIND version checks into your vulnerability scanning and asset inventory.
• For appliances and embedded images, include DNS server binaries in your SBOM (Software Bill of Materials) so you can quickly identify exposure.
• Centralize DNS resolution where sensible and enforce egress filters so only approved resolvers reach external networks.
• Test serve-stale re-enablement after patching if your environment depends on it.

Outlook: The Patch Window and What Comes Next

ISC’s advisory noted that no public exploit code existed at the time of disclosure, and exploit prediction scores remain low. But don’t let that lull you. “The vulnerability is network-exploitable and trivially useful for denial-of-service,” said one threat analyst. “Assume attackers will add this to their toolkits as soon as they analyze the patch diff.”

CISA’s inclusion in the known exploited vulnerabilities list means federal agencies must patch within a mandated timeframe—often two weeks—and that timeline sets an informal bar for the private sector. Expect scanning for vulnerable BIND versions to increase in the coming days. Organizations that delay patching risk waking up to a crashed DNS server and a flood of support tickets.

The silver lining: the fix is a simple upgrade. Unlike some complex vulnerabilities that require architectural changes, this one is solved by a routine software update. For most teams, the biggest challenge will be finding all the places BIND lurks in their infrastructure—but that same challenge is also a chance to tighten DNS hygiene for the next advisory.