What is the CVSS score of CVE-2026-42002?

CVE-2026-42002 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.0%.

Which versions of PowerDNS Authoritative are affected by CVE-2026-42002?

PowerDNS Authoritative Server versions 4.9.0-4.9.14 and 5.0.0-5.0.4 contain a denial-of-service vulnerability that can crash or hang the DNS service when GSS-TSIG authentication is enabled.. A patch is available.

How to fix or mitigate CVE-2026-42002?

Within 24 hours, determine whether GSS-TSIG is enabled in your PowerDNS deployment by reviewing configuration files and system logs; if enabled, immediately escalate to infrastructure and security teams. Within 7 days, apply vendor patches (PowerDNS 4.9.15 for 4.9.x branch or 5.0.5 for 5.0.x branch) to all affected authoritative servers and conduct controlled testing in a non-production environment first. Within 30 days, complete deployment across all instances, validate DNS service stability post-patch, and document your GSS-TSIG configuration for future vulnerability assessments.

PowerDNS Authoritative CVE-2026-42002

EUVD-2026-31260 HIGH

Signal Handler Race Condition (CWE-364)

2026-05-21 OX

GHSA-vx6m-m9qv-88q3

Information Disclosure Powerdns Authoritative

7.5

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

5.9 MEDIUM

Concurrency race needs a timing win so AC:H; reachable pre-auth over the network at PR:N; availability-only crash with no confidentiality or integrity impact.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

SUSE

5.9 MEDIUM

AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Primary rating from NVD.

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Updated

Jul 23, 2026 - 16:47 vuln.today

v3 (cvss_changed)

Analysis Updated

Jul 23, 2026 - 16:46 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jul 23, 2026 - 16:22 vuln.today

cvss_changed

Severity Changed

Jul 23, 2026 - 16:22 NVD

MEDIUM HIGH

CVSS changed

Jul 23, 2026 - 16:22 NVD

5.9 (MEDIUM) 7.5 (HIGH)

Patch available

May 21, 2026 - 11:01 EUVD

Analysis Generated

May 21, 2026 - 10:46 vuln.today

DescriptionNVD

Concurrency and locking defects in GSS-TSIG

AnalysisAI

Denial of service in PowerDNS Authoritative Server (4.9.0 before 4.9.15 and 5.0.0 before 5.0.5) arises from concurrency and locking defects in the GSS-TSIG code path, allowing a remote attacker to crash or hang the server (CVSS 7.5, availability-only impact). No public exploit identified at time of analysis, and EPSS is very low (0.02%, 6th percentile), with CISA's SSVC framework rating exploitation as 'none' and technical impact as 'partial'. Vendor patches are available, and exposure is limited to deployments that have the GSS-TSIG feature enabled.

Technical ContextAI

PowerDNS Authoritative is an open-source authoritative DNS server widely used by ISPs, registrars, and hosting providers (cpe:2.3:a:powerdns:authoritative). GSS-TSIG (RFC 3645) extends TSIG by using GSSAPI/Kerberos to authenticate dynamic DNS updates and zone transfers, requiring the server to negotiate and maintain security contexts across requests. The root cause maps to CWE-364 (race condition), reflecting flawed synchronization/locking around shared GSS-TSIG state when multiple requests are processed concurrently; improper locking of this shared context leads to inconsistent state and a server crash or hang rather than data corruption or disclosure.

RemediationAI

Vendor-released patch: upgrade to PowerDNS Authoritative 4.9.15 (for the 4.9.x branch) or 5.0.5 (for the 5.0.x branch) as documented in PowerDNS Advisory 2026-06 (https://docs.powerdns.com/authoritative/security-advisories/powerdns-advisory-powerdns-2026-06.html). Where immediate patching is not possible, the most effective compensating control is to disable GSS-TSIG if it is not required, since the defect is confined to that code path - the trade-off is loss of Kerberos-authenticated dynamic updates and zone transfers for any client that relies on it. If GSS-TSIG must remain enabled, restrict network reachability of the server's update/GSS-TSIG endpoint to trusted management networks via firewall ACLs and monitor for repeated crashes or service restarts, accepting that this narrows but does not eliminate exposure. Do not rely on TSIG-key secrecy alone, as the race is triggered during request handling rather than by content authorization.