Reactor Netty EUVD-2026-66678

Exploitation requires the target application to instantiate multiple Reactor Netty HttpClient instances with differing DNS resolver configurations within the same runtime. This is not a default configuration - standard Spring WebClient usage typically employs a single shared client. The condition is limited to applications that explicitly construct heterogeneous multi-client setups. Attack complexity is high (AC:H) because the attacker cannot directly inject the faulty state; they can only potentially benefit if the application's DNS resolution is misdirected as a side effect of the bug. Authentication is not required (PR:N) from a network perspective, but the exploitation path is entirely dependent on the victim application's internal design choices. Platforms and JVM versions are not specified as additional constraints.

The CVSS 3.7 base score accurately reflects a low-severity issue. The AV:N/AC:H vector indicates the flaw is reachable over the network but requires high attack complexity - specifically, the uncommon deployment condition of multiple clients with differing DNS resolver configurations operating concurrently. PR:N confirms no authentication is required on the attacker's side, but this is somewhat misleading: the vulnerability manifests as a misconfiguration-propagation bug within the application layer, not a remotely injectable flaw in the traditional sense. The sole impact is I:L (limited integrity), meaning DNS resolution may be misdirected, potentially routing traffic to unintended endpoints. No confidentiality or availability impact is assessed. No KEV listing exists, no EPSS data was provided, and no POC is known. Real-world exploitability is constrained significantly by the requirement for the specific multi-client scenario, making this a low operational priority for most deployments unless the application explicitly constructs multiple WebClient instances with heterogeneous resolver configurations.

An application creates two Reactor Netty HttpClient instances - one configured to use an internal DNS resolver (e.g., resolving corp.internal names) and another configured to use a public resolver. Due to resolver reuse, requests from the second client are incorrectly routed through the first client's resolver, causing hostname resolution to fail or resolve to unintended addresses. No public exploit exists; triggering this requires an application architecture with the specific multi-client/multi-resolver pattern.