PowerDNS Authoritative CVE-2026-42002

The affected server must have the GSS-TSIG feature explicitly enabled (used for Kerberos/GSSAPI-authenticated dynamic DNS updates and transfers); this is not a default PowerDNS Authoritative configuration, which sharply limits the exposed population. Exploitation further requires generating concurrent GSS-TSIG requests to trigger the locking race, so success depends on winning a timing window rather than a single deterministic request. Only versions 4.9.0-4.9.14 and 5.0.0-5.0.4 are affected; patched builds (4.9.15, 5.0.5) remove the condition. Authentication requirements are not fully confirmed from available data - the vendor vector states PR:N, but GSS-TSIG involves a Kerberos handshake, so whether a valid credential is needed to reach the vulnerable code should be verified with the vendor advisory.

The signals converge on a moderate, not urgent, priority. The vendor CVSS 3.1 base of 7.5 is driven purely by A:H (C:N/I:N) - a pure availability/DoS impact with network vector and no authentication or user interaction. However, EPSS is extremely low (0.02%), SSVC reports Exploitation: none, Automatable: no, Technical Impact: partial, and there is no POC or KEV listing, so real-world exploitation likelihood is currently low. Two data conflicts should be flagged: (1) the vendor vector marks AC:L, but a concurrency/locking race typically requires winning a timing window, which argues for AC:H and lowers realistic exploitability; (2) the intelligence tags label this 'Information Disclosure', yet the CVSS vector sets C:N - the authoritative impact per NVD/vendor is availability only, so treat the disclosure tag as unconfirmed and verify against the PowerDNS advisory. Overall this is a genuine but patchable DoS affecting only GSS-TSIG-enabled deployments, not a high-real-risk internet-wide threat.

An attacker who can reach a PowerDNS Authoritative server with GSS-TSIG enabled sends a burst of concurrent GSS-TSIG requests crafted to interleave and hit the unsynchronized locking window in the GSS context handling. Winning the race corrupts internal state and causes the daemon to crash or hang, denying DNS resolution for every zone the server is authoritative for. No public POC is currently identified, and the timing-dependent nature (likely AC:H) makes reliable triggering non-trivial.