CVE-2026-42002: GSS-TSIG Race Condition Vulnerability

CVE-2026-42002 Overview

CVE-2026-42002 is a concurrency and locking defect in the GSS-TSIG (Generic Security Service - Transaction Signature) implementation within PowerDNS. The flaw allows a network-based attacker to trigger a race condition that disrupts service availability on affected DNS deployments. Successful exploitation results in denial of service against the DNS service. Confidentiality and integrity are not impacted, but availability degradation can interrupt authoritative DNS resolution for downstream consumers. The attack complexity is high, requiring precise timing to win the race window. No authentication or user interaction is needed. See the PowerDNS Security Advisory for vendor details.

Critical Impact
Remote attackers can trigger a denial of service against PowerDNS deployments using GSS-TSIG by exploiting concurrency defects, disrupting authoritative DNS resolution.

Affected Products

PowerDNS Authoritative Server (deployments using GSS-TSIG)
See vendor advisory for exact affected versions
Refer to the PowerDNS Security Advisory for fixed releases

Discovery Timeline

2026-05-21 - CVE-2026-42002 published to NVD
2026-05-21 - Last updated in NVD database

Technical Details for CVE-2026-42002

Vulnerability Analysis

The vulnerability resides in the GSS-TSIG handling code path of PowerDNS. GSS-TSIG extends standard TSIG by using GSS-API for authenticated DNS transactions, commonly with Active Directory environments. The implementation contains concurrency and locking defects that surface when multiple GSS-TSIG operations execute in parallel. An attacker can deliver crafted DNS messages that race protected state, triggering inconsistent access to shared structures. The outcome is a process crash or hang that interrupts DNS service. Because GSS-TSIG is exposed over the network, no privileges or user interaction are required to reach the vulnerable code path. The attack window is narrow, which raises complexity but does not preclude exploitation.

Root Cause

The root cause is improper synchronization around shared GSS-TSIG context state. Locks either do not cover all critical sections or are released before dependent operations complete. This race condition [CWE-362] allows concurrent requests to corrupt or invalidate state used by the authentication routine, causing the worker to fault.

Attack Vector

The attack vector is network-based. An unauthenticated remote attacker sends concurrent GSS-TSIG-signed or GSS-TSIG-bound DNS messages to an authoritative PowerDNS server. By timing the requests to overlap inside the unprotected critical section, the attacker forces the race and produces denial of service. Refer to the PowerDNS Security Advisory for protocol-level specifics.

Detection Methods for CVE-2026-42002

Indicators of Compromise

Unexpected crashes, restarts, or worker process terminations in PowerDNS authoritative server logs
Spikes in concurrent GSS-TSIG-authenticated DNS update or query traffic from one or few source addresses
Repeated TSIG/GSS-TSIG validation errors followed by service interruption
DNS service availability gaps reported by monitoring while CPU or thread counts spike

Detection Strategies

Monitor PowerDNS process supervisor logs (systemd, container runtime) for abnormal restart frequency
Correlate DNS query telemetry with authentication errors tied to the GSS-TSIG code path
Inspect network captures for concurrent inbound DNS messages carrying TSIG records with GSS-TSIG algorithm names

Monitoring Recommendations

Enable verbose logging on the authoritative server for TSIG validation events
Track 5xx-equivalent DNS responses (SERVFAIL) and timeouts against authoritative zones
Alert on rapid concurrent GSS-TSIG requests from the same source within sub-second windows
Forward DNS server logs to a centralized analytics platform for cross-host correlation

How to Mitigate CVE-2026-42002

Immediate Actions Required

Apply the fixed PowerDNS release referenced in the PowerDNS Security Advisory
Restrict network access to the authoritative DNS service to known administrative sources where feasible
Disable GSS-TSIG on servers that do not require it
Place rate limits on inbound DNS traffic that carries TSIG records

Patch Information

PowerDNS has published fixed releases that address the concurrency and locking defects in the GSS-TSIG implementation. Operators should consult the PowerDNS Security Advisory for the exact version numbers and upgrade instructions applicable to their deployment.

Workarounds

Disable GSS-TSIG support in PowerDNS configuration if the feature is not required
Limit which clients can submit TSIG-signed updates using firewall ACLs
Front the authoritative server with a DNS proxy or load balancer that can filter or rate-limit suspicious GSS-TSIG traffic
Run the authoritative server under a supervisor that performs rapid restarts to limit downtime while patches are scheduled

bash

# Configuration example: disable GSS-TSIG when not required
# /etc/powerdns/pdns.conf
enable-gss-tsig=no
# Restart the service after editing
systemctl restart pdns