| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The label decompression functionality in PowerDNS Recursor before 3.6.4 and 3.7.x before 3.7.3 and Authoritative (Auth) Server before 3.3.3 and 3.4.x before 3.4.5 allows remote attackers to cause a denial of service (CPU consumption or crash) via a request with a long name that refers to itself. NOTE: this vulnerability exists because of an incomplete fix for CVE-2015-1868. |
| PowerDNS Recursor before 3.6.2 does not limit delegation chaining, which allows remote attackers to cause a denial of service ("performance degradations") via a large or infinite number of referrals, as demonstrated by resolving domains hosted by ezdns.it. |
| PowerDNS (aka pdns) Authoritative Server before 3.4.10 allows remote attackers to cause a denial of service (backend CPU consumption) via a long qname. |
| PowerDNS (aka pdns) Authoritative Server before 3.4.10 does not properly handle a . (dot) inside labels, which allows remote attackers to cause a denial of service (backend CPU consumption) via a crafted DNS query. |
| PowerDNS (aka pdns) Authoritative Server before 4.0.1 allows remote primary DNS servers to cause a denial of service (memory exhaustion and secondary DNS server crash) via a large (1) AXFR or (2) IXFR response. |
| Unspecified vulnerability in PowerDNS Recursor (aka pdns_recursor) 3.6.x before 3.6.1 allows remote attackers to cause a denial of service (crash) via an unknown sequence of malformed packets. |
| The resolver in PowerDNS Recursor (aka pdns_recursor) 3.3 overwrites cached server names and TTL values in NS records during the processing of a response to an A record query, which allows remote attackers to trigger continued resolvability of revoked domain names via a "ghost domain names" attack. |
| common_startup.cc in PowerDNS (aka pdns) Authoritative Server before 2.9.22.5 and 3.x before 3.0.1 allows remote attackers to cause a denial of service (packet loop) via a crafted UDP DNS response. |
| PowerDNS Authoritative Server 4.5.0 before 4.5.1 allows anybody to crash the process by sending a specific query (QTYPE 65535) that causes an out-of-bounds exception. |
| An issue has been found in PowerDNS Recursor before 4.1.18, 4.2.x before 4.2.5, and 4.3.x before 4.3.5. A remote attacker can cause the cached records for a given name to be updated to the Bogus DNSSEC validation state, instead of their actual DNSSEC Secure state, via a DNS ANY query. This results in a denial of service for installation that always validate (dnssec=validate), and for clients requesting validation when on-demand validation is enabled (dnssec=process). |
| An issue was discovered in PowerDNS Authoritative through 4.3.0 when --enable-experimental-gss-tsig is used. A remote, unauthenticated attacker might be able to cause a double-free, leading to a crash or possibly arbitrary code execution. by sending crafted queries with a GSS-TSIG signature. |
| An issue was discovered in PowerDNS Authoritative through 4.3.0 when --enable-experimental-gss-tsig is used. A remote, unauthenticated attacker can cause a denial of service by sending crafted queries with a GSS-TSIG signature. |
| An issue was discovered in PowerDNS Authoritative through 4.3.0 when --enable-experimental-gss-tsig is used. A remote, unauthenticated attacker can trigger a race condition leading to a crash, or possibly arbitrary code execution, by sending crafted queries with a GSS-TSIG signature. |
| An issue has been found in PowerDNS Authoritative Server before 4.3.1 where an authorized user with the ability to insert crafted records into a zone might be able to leak the content of uninitialized memory. |
| In PowerDNS Recursor versions up to and including 4.3.1, 4.2.2 and 4.1.16, the ACL restricting access to the internal web server is not properly enforced. |
| An issue has been found in PowerDNS Recursor 4.1.0 through 4.3.0 where records in the answer section of a NXDOMAIN response lacking an SOA were not properly validated in SyncRes::processAnswer, allowing an attacker to bypass DNSSEC validation. |
| PowerDNS Recursor from 4.1.0 up to and including 4.3.0 does not sufficiently defend against amplification attacks. An issue in the DNS protocol has been found that allow malicious parties to use recursive DNS services to attack third party authoritative name servers. The attack uses a crafted reply by an authoritative name server to amplify the resulting traffic between the recursive and other authoritative name servers. Both types of service can suffer degraded performance as an effect. This is triggered by random subdomains in the NSDNAME in NS records. PowerDNS Recursor 4.1.16, 4.2.2 and 4.3.1 contain a mitigation to limit the impact of this DNS protocol issue. |
| An issue has been found in PowerDNS Recursor 4.1.0 up to and including 4.3.0. It allows an attacker (with enough privileges to change the system's hostname) to cause disclosure of uninitialized memory content via a stack-based out-of-bounds read. It only occurs on systems where gethostname() does not have '\0' termination of the returned string if the hostname is larger than the supplied buffer. (Linux systems are not affected because the buffer is always large enough. OpenBSD systems are not affected because the returned hostname always has '\0' termination.) Under some conditions, this issue can lead to the writing of one '\0' byte out-of-bounds on the stack, causing a denial of service or possibly arbitrary code execution. |
| A vulnerability was found in PowerDNS Authoritative Server before 4.0.7 and before 4.1.7. An insufficient validation of data coming from the user when building a HTTP request from a DNS query in the HTTP Connector of the Remote backend, allowing a remote user to cause a denial of service by making the server connect to an invalid endpoint, or possibly information disclosure by making the server connect to an internal endpoint and somehow extracting meaningful information about the response |
| An issue has been found in PowerDNS Recursor versions 4.1.x before 4.1.9 where records in the answer section of responses received from authoritative servers with the AA flag not set were not properly validated, allowing an attacker to bypass DNSSEC validation. |
