PowerDNS Authoritative CVE-2026-33611

Attacker must possess valid credentials and authorization to use the PowerDNS Authoritative REST API (PR:H in CVSS vector). The vulnerable code path is only triggered when creating or modifying HTTPS (type 65) or SVCB (type 64) DNS records via the REST API. The deployment must use LMDB as the backend storage engine; other storage backends (SQLite, MySQL, zone files) are not affected. REST API must be enabled in the PowerDNS configuration (not the default in minimal installs). The vulnerability does not require special network positioning, specific DNS configurations, or user interaction - only REST API access by an authenticated operator with record modification privileges.

CVSS 6.5 with network vector (AV:N), low complexity (AC:L), and high privilege requirement (PR:H) indicates moderate real-world risk, heavily mitigated by the high-privilege prerequisite. The vulnerability requires an authenticated operator with REST API access - not an unauthenticated remote attacker. EPSS score not provided, limiting probabilistic exploitation assessment. Exploitation is non-interactive (UI:N) and has bounded scope (S:U), affecting only the targeted service. The high-privilege gate significantly reduces risk compared to the raw CVSS score: only trusted operators can trigger this. However, the dual impact on integrity and availability (I:H/A:H) is serious - database corruption can render the authoritative server inoperable. No KEV status provided, no public POC identified. This is a privilege-abuse vulnerability rather than a remote escalation path; threat model centers on malicious or compromised operator accounts, not external attackers. Organizations without REST API exposure or with strict operator access controls face lower real risk.

A malicious or compromised operator with PowerDNS REST API credentials crafts an HTTP POST request to the API endpoint for creating HTTPS or SVCB records, embedding specially formatted invalid data in the record payload. The API server bypasses validation and writes the corrupted record directly to the LMDB database. Subsequent DNS queries fail or return corrupt data, potentially cascading to database index corruption that impacts all zone data stored in LMDB, forcing service restart or database rebuild.