CVE-2024-8418 is a denial of service flaw in aardvark-dns, the DNS server from the containers project. The NVD scores it 7.5 (High). One client that holds a TCP DNS connection open can make the server stop answering others. Red Hat's page says to upgrade to aardvark-dns 1.12.1 or later.
What's affected
Aardvark-dns is the authoritative DNS service that container networks use to resolve container names, most often alongside Podman and Netavark. The weakness is in how it handled TCP queries: they were processed one after another, so a single slow or idle connection blocked the rest.
The NVD record lists versions 1.12.0 and 1.12.1 in its affected configuration. Red Hat's CVE page, on the other hand, tells you to upgrade to 1.12.1 or higher. Those two statements do not fit together cleanly, so treat the version boundary with care. The upstream fix is pull request 503 ("coredns: work on tcp requests concurrently"), merged into the main branch on 2 September 2024, and the pull request page does not name the release that first shipped it. Confirm the exact package build you are running against the Red Hat errata RHSA-2025:7094 or the project's release tags.
Severity is also reported two ways. The NVD vector is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base score 7.5, High. Red Hat rates the issue Moderate, with the same CVSS 7.5 base score shown on its page.
How to check if you're exposed
Find out whether the binary is on the host and which version it is:
# RPM based systems
rpm -q aardvark-dns
# Debian and Ubuntu
dpkg -l | grep -i aardvark
# Any system, if the binary is on the path or in the Podman helper directory
/usr/libexec/podman/aardvark-dns --version
Then compare the result with the fixed build in the Red Hat errata. If your hosts run containers on a user defined bridge network under Podman, aardvark-dns is probably in use. Hosts that only use the default network or a different runtime may not run it at all.
Container images that bundle the binary are easy to miss. Scan images as well as hosts, for example with the free in-browser dependency scan at gold.safeguard.sh/scan.
What to do now
- Inventory every host and image that ships aardvark-dns, including build runners and developer machines.
- Update to the version named in your distribution's advisory. Red Hat says 1.12.1 or later; verify the exact build in RHSA-2025:7094.
- Restart the container networks or the services that use the DNS server so the new binary is loaded.
- Keep untrusted clients away from the container network DNS port. The advisory offers no workaround, so this is a general precaution and not a fix.
- Watch for DNS timeouts between containers that clear only after a restart. That symptom is what upstream issue 500 describes ("DNS Stops working after some time in bridge network").
Why it matters
The class is CWE-400, uncontrolled resource consumption. The server handled TCP requests on one network serially, so a caller could block it for a long time by opening a connection and sending little or no data. No credentials were needed, and the impact is availability only: nothing in the record suggests data theft or code execution.
The upstream change gives every TCP connection a 3 second timeout, allows one message per connection, and handles each accepted connection in its own task. That is the standard shape of a fix for this class of bug: bound how long any single client can hold a slot, and stop one client from serializing everyone else.
The record does not flag this CVE as known exploited, and the CISA Known Exploited Vulnerabilities flag is false. It still deserves attention because DNS failure inside a container network tends to look like an application outage, and it is slow to diagnose.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does an attacker need an account to trigger this?
No. The NVD vector shows no privileges and no user interaction, with network access. The attacker only needs to reach the DNS service over TCP.
Is a workaround available?
Red Hat's page gives no workaround and says to upgrade. Limiting who can reach the container network DNS port is sensible, but it is not a documented fix.
Sources
Last reviewed: 19 October 2026.
