PowerDNS-Admin CVE-2026-119658

Requires an authenticated PowerDNS-Admin User-role account that is already authorized for at least one zone (PR:L); the attacker POSTs to the /domain/<authorized-zone>/update endpoint and supplies a JSON body 'domain' field naming a different secondary (Slave) zone, which the pre-patch code acted on instead of the URL-path zone. Exploitation is limited to deployments running PowerDNS-Admin through 2026.08.1, targets only secondary zones that support axfr-retrieve, and yields only a zone-refresh trigger plus an existence oracle - not record read/write; it is gated by needing valid credentials and access to one zone, so it is a cross-user/cross-tenant boundary bypass rather than unauthenticated access. Updating to the patched build (PR #1942) is the vendor fix.

This is a genuine but moderate-severity (CVSS 5.3) authorization/IDOR flaw, not a high-CVSS-but-low-real-risk item nor a top-priority emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L) correctly frames it as network-reachable and low-complexity but requiring privileges (PR:L) - exploitation is limited to accounts that already hold a valid PowerDNS-Admin User-role login with access to at least one zone, so it is a privileged-insider / cross-tenant boundary bypass rather than remote-unauthenticated compromise. Impact is bounded: the attacker cannot read or overwrite other users' record data, only force axfr-retrieve (secondary-zone refresh) on zones they do not control and use response differences as a zone-existence oracle. The vendor vector marks VC:N, yet the description explicitly states attackers can 'infer zone existence from differing responses,' which is a limited confidentiality/information-disclosure effect - this is a mild internal inconsistency, and I assess a low confidentiality impact rather than none. No CISA KEV listing is present and no EPSS score was supplied, so widespread or automated exploitation is not indicated; the vuln.today decision label is 'this_month' (routine prioritized patching), consistent with a privilege-required, limited-impact bug. A public PoC reference (hackmd write-up) exists but is not verified as working exploit code.

A low-privilege PowerDNS-Admin User who has been granted access to even a single secondary zone sends a POST to /domain/<their-authorized-zone>/update with a JSON body whose 'domain' field names a different user's secondary zone; the server authorizes the URL zone but then acts on the body-supplied zone, triggering an axfr-retrieve of the victim zone. By observing differing responses, the attacker determines whether arbitrary secondary zones exist. A public write-up describing the technique exists (hackmd), but it is not verified as working exploit code.