PowerDNS Recursor CVE-2026-40012

ECS (EDNS Client Subnet) must be explicitly enabled in the PowerDNS Recursor configuration - this is not the default deployment state, meaning the majority of Recursor installations are unaffected by default. The specific triggering condition is the receipt of a DNS response from an authoritative server that carries an ECS scope prefix length of zero (a 'zero-scoped' answer), which is a normal authoritative server behavior for globally-valid answers. No authentication is required: once ECS is enabled, any client capable of sending DNS queries to the resolver can trigger the improper caching behavior. Exploitation is further limited to environments where an attacker can both influence what gets cached (by initiating queries) and observe what is returned from the cache (by issuing follow-up queries), requiring some degree of query visibility. The CVSS vector PR:N confirms no credential or session requirement once the ECS configuration condition is met.

The CVSS 3.1 base score of 5.3 (Medium) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N accurately reflects a remotely triggerable, unauthenticated information disclosure with limited confidentiality impact and no integrity or availability consequence. The most significant risk limiter is the non-default ECS configuration: organizations that have not explicitly enabled EDNS Client Subnet are entirely unaffected. EPSS data is not present in the available intelligence, so probabilistic exploitation likelihood cannot be quantified. The vulnerability is not in the CISA KEV catalog and no public proof-of-concept code has been identified, indicating no confirmed active exploitation at time of analysis. The practical impact is constrained: an attacker would need to craft DNS queries and observe returned cached responses to infer client subnet scoping information - this is an indirect, low-fidelity disclosure channel rather than direct exfiltration of sensitive data. For ISP and large enterprise deployments that do run ECS (where the technology provides the most operational value), the exposure surface is larger because the resolver handles queries from diverse client subnets, making the cache leakage between subnet cohorts more meaningful. Overall, this is a real but low-urgency finding: prioritize patching in ECS-enabled recursive resolvers operated at scale; non-ECS deployments can defer.

An attacker sends a series of DNS queries through an ECS-enabled PowerDNS Recursor - potentially from multiple source IP addresses representing different client subnets - and crafts queries for domains whose authoritative servers return zero-scoped ECS answers. Because the Recursor improperly stores these answers in the packet cache with ECS scope metadata, a subsequent query from a different client subnet may receive a cached response that exposes the ECS scope from a prior query, leaking partial subnet information about previous querying clients. No public proof-of-concept code has been identified, and the attack requires the ability to send DNS queries to the affected resolver and observe the returned responses.