| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Buffer overflow in innd 2.2.2 allows remote attackers to execute arbitrary commands via a cancel request containing a long message ID. |
| Denial of Service vulnerabilities in BIND 4.9 and BIND 8 Releases via CNAME record and zone transfer. |
| The resolver in glibc 2.1.3 uses predictable IDs, which allows a local attacker to spoof DNS query results. |
| Command execution via shell metachars in INN daemon (innd) 1.5 using "newgroup" and "rmgroup" control messages, and others. |
| BIND 4 and BIND 8 allow remote attackers to access sensitive information such as environment variables. |
| Denial of Service vulnerability in BIND 8 Releases via maliciously formatted DNS messages. |
| BIND 4 (BIND4) and BIND 8 (BIND8), if used as a target forwarder, allows remote attackers to gain privileged access via a "Kashpureff-style DNS cache corruption" attack. |
| Denial of service in BIND named via consuming more than "fdmax" file descriptors. |
| An "incorrect assumption" in the authvalidated validator function in BIND 9.3.0, when DNSSEC is enabled, allows remote attackers to cause a denial of service (named server exit) via crafted DNS packets that cause an internal consistency test (self-check) to fail. |
| Format string vulnerabilities in the logging routines for dynamic DNS code (print.c) of ISC DHCP daemon (DHCPD) 3 to 3.0.1rc8, with the NSUPDATE option enabled, allow remote malicious DNS servers to execute arbitrary code via format strings in a DNS server response. |
| Buffer overflow in innfeed for ISC InterNetNews (INN) before 2.3.0 allows local users in the "news" group to gain privileges via a long -c command line argument. |
| Format string vulnerability in the log functions in dhcpd for dhcp 2.x allows remote DNS servers to execute arbitrary code via certain DNS messages, a different vulnerability than CVE-2002-0702. |
| Remote access in AIX innd 1.5.1, using control messages. |
| Under certain circumstances, BIND is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache.
This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1. |
| If an unauthenticated user sends a large amount of data to the Stork UI, it may cause memory and disk use problems for the system running the Stork server.
This issue affects Stork versions 1.0.0 through 2.3.0. |
| When an incoming DNS protocol message includes a Transaction Signature (TSIG), BIND always checks it. If the TSIG contains an invalid value in the algorithm field, BIND immediately aborts with an assertion failure.
This issue affects BIND 9 versions 9.20.0 through 9.20.8 and 9.21.0 through 9.21.7. |
| A malicious client can send many DNS messages over TCP, potentially causing the server to become unstable while the attack is in progress. The server may recover after the attack ceases. Use of ACLs will not mitigate the attack.
This issue affects BIND 9 versions 9.18.1 through 9.18.27, 9.19.0 through 9.19.24, and 9.18.11-S1 through 9.18.27-S1. |
| Client queries that trigger serving stale data and that also require lookups in local authoritative zone data may result in an assertion failure.
This issue affects BIND 9 versions 9.16.13 through 9.16.50, 9.18.0 through 9.18.27, 9.19.0 through 9.19.24, 9.11.33-S1 through 9.11.37-S1, 9.16.13-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.27-S1. |
| If a `named` caching resolver is configured with `serve-stale-enable` `yes`, and with `stale-answer-client-timeout` set to `0` (the only allowable value other than `disabled`), and if the resolver, in the process of resolving a query, encounters a CNAME chain involving a specific combination of cached or authoritative records, the daemon will abort with an assertion failure.
This issue affects BIND 9 versions 9.20.0 through 9.20.10, 9.21.0 through 9.21.9, and 9.20.9-S1 through 9.20.10-S1. |
| If a DHCPv4 client sends a request with some specific options, and Kea fails to find an appropriate subnet for the client, the `kea-dhcp4` process will abort with an assertion failure. This happens only if the client request is unicast directly to Kea; broadcast messages do not cause the problem.
This issue affects Kea versions 2.7.1 through 2.7.9, 3.0.0, and 3.1.0. |