DNSResolveQueueCFNet::performDNSLookup (Source/WebCore/platform/network/cf/DNSResolveQueueCFNet.cpp) performs WebCore’s asynchronous DNS prefetch/resolution using CFNetwork’s low-level nw_resolver API. Before the patch it configured the resolver’s parameters and privacy context (nw_context_set_privacy_level(…, nw_context_privacy_level_silent) and nw_parameters_set_context) and then created the resolver directly from the target endpoint via nw_resolver_create_with_endpoint(hostEndpoint, parameters). The invariant that must hold when iCloud Private Relay is enabled is that name resolution — like the connection itself — must be carried over the Private Relay proxy path rather than being sent as a plaintext query to the locally configured/default DNS servers. Creating a resolver directly from an endpoint apparently does not run the network path evaluation that decides how (and through which proxy/interface) traffic should egress, so the DNS query could be issued outside the Private Relay tunnel, exposing the hostnames being resolved to the local network / ISP even though Private Relay was on.

The fix inserts an explicit path-evaluation step: it creates an nw_path_evaluator for the endpoint with the same parameters (nw_path_create_evaluator_for_endpoint), copies the resulting nw_path (nw_path_evaluator_copy_path), and then builds the resolver from that path (nw_resolver_create_with_path(path)). Resolving over the evaluated path makes the query honor the Private Relay routing/proxy decision, restoring the invariant that DNS is tunneled with the rest of the connection. The companion change in Source/WebCore/PAL/pal/spi/cf/CFNetworkSPI.h merely declares the newly used SPI (the nw_path_evaluator object type and the three functions), which is a prerequisite for calling them and not itself a bug. That the pre-patch path leaked queries is grounded in the CVE description and the direction of the fix; the precise internal reason nw_resolver_create_with_endpoint skips proxy routing is an inference about CFNetwork behavior, not something the diff itself spells out.

This is an information-disclosure/privacy bug, not a memory-safety issue: the leaked primitive is the set of hostnames the victim resolves, visible to a passive on-path observer (local network, Wi-Fi operator, or ISP) even though Private Relay is engaged. It runs in the process that performs WebCore DNS resolution (the networking path, effectively the Network/UI side of resolution rather than a WebContent memory bug) and yields no control-flow influence, no crash, and no path toward RCE. Realistic escalation is limited to deanonymization, browsing-history inference, and targeting/censorship based on the observed queries. Severity is medium because it silently undermines a privacy guarantee users opt into, but exposure is bounded to metadata rather than content or code execution.