CVE-2024-1931 is a high severity (CVSS 7.5) denial of service flaw in NLnet Labs Unbound 1.18.0 through 1.19.1. A code path that trims EDE records can loop forever. It needs the non-default option ede: yes. Unbound 1.19.2 fixes it, and ede: no avoids it.
What's affected
NLnet Labs lists Unbound 1.18.0 up to and including 1.19.1 as affected. Version 1.19.2 contains the patch. For older source builds in that range, the advisory publishes a patch file you can apply to the source tree, then rebuild and install.
The flaw can only be triggered when Unbound runs with the non-default setting ede: yes, replies with Extended DNS Error information on a positive answer, and the client's advertised buffer is smaller than the space those records need. NVD scores it 7.5 (High) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The NLnet Labs text I read gives no score of its own, so the sources do not disagree.
The record also lists Fedora 38, 39 and 40, and its references include Fedora, FreeBSD and NetApp notices, so distribution packages may carry backported fixes under different version numbers.
How to check if you're exposed
Run unbound -V to print the version of the binary on the host. If it reports 1.18.0 through 1.19.1, continue. On packaged installs, also ask the package manager, for example rpm -q unbound on Fedora family systems, and read your distribution's advisory, since a distribution may have patched without changing the upstream version string.
Then look at the configuration. Search your unbound.conf and any included files for the ede option. If it is absent or set to no, which is the default, this flaw cannot be triggered, though you should still upgrade. Keep a current inventory of where the component runs. A software bill of materials per application, refreshed on every build, turns a question like "do we run this anywhere" into a lookup instead of a week of email.
What to do now
- Find every Unbound resolver you run, including those inside appliances and containers.
- Upgrade to 1.19.2 or later, or install your distribution's patched package.
- If you cannot upgrade yet, set ede: no in the configuration and reload Unbound.
- If you build from source in the affected range, apply the patch NLnet Labs publishes and rebuild.
- Watch resolver health after the change, since a stuck resolver shows up as DNS timeouts for users.
Why it matters
The NVD class is CWE-835, a loop with an unreachable exit condition. Unbound 1.18.0 added a feature that removes EDE records from responses larger than the client's advertised buffer. Before removing all records it tries trimming their text fields. An unchecked condition in that trimming code meant the loop never ended.
A resolver stuck in a loop stops answering queries, and DNS is a dependency for nearly everything. Because the trigger is a network request that needs no authentication, availability is the whole impact, which matches the A:H and C:N, I:N in the vector. The narrow precondition keeps the real exposure small for default installs. It is also a good example of why optional features deserve the same review as defaults. The record's KEV flag is false, and no source I retrieved reports exploitation of this CVE in the wild. You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your projects pull in the affected component. Safeguard reachability analysis can then help you separate code paths that actually call the weak component from those that only list it.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I exposed if I run Unbound 1.19.1 with default settings?
The advisory says the issue can only be triggered with the non-default ede: yes option, so a default configuration cannot reach it. Upgrading is still recommended.
What is the quickest mitigation?
Set ede: no, or move to 1.19.2.
Sources
Last reviewed: 19 October 2026.
