CVE-2026-47843

Overview

Reactor Netty is the reactive networking layer of Project Reactor: it wraps Netty in a Reactive Streams API and supplies the non-blocking HTTP client and server that Spring WebFlux runs on. The reactor-netty-core module provides the transport primitives that clients such as TcpClient and HttpClient are built on, including the DNS name resolver configuration.

An incorrectly configured access control vulnerability (CVE-2026-47843) has been identified in the DNS resolver configuration of reactor-netty-core, which can cause a client to reuse a previously configured DNS resolver instead of the one it was given. When an application dynamically creates multiple clients that rely on different custom resolver configurations, traffic can be routed to unintended destinations.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects multiple versions of Reactor Netty.

Details

Module Info

• Product: Reactor Netty
• Affected packages: io.projectreactor.netty:reactor-netty-core
• Affected versions: <=1.0.52, >=1.1.0 <=1.2.18, >=1.3.0 <=1.3.6
• GitHub repository: https://github.com/reactor/reactor-netty
• Published packages: https://central.sonatype.com/artifact/io.projectreactor.netty/reactor-netty-core
• Package manager: Maven
• Fixed in:
  • OSS Reactor Netty 1.3.7
  • NES for Reactor Netty v1.0.51

Vulnerability Info

This Low-severity vulnerability is found in the io.projectreactor.netty:reactor-netty-core package in multiple versions of Reactor Netty. A client's DNS resolver is configured through ClientTransport#resolver(Consumer<NameResolverSpec>), which builds a new NameResolverProvider from the spec and compares it with the provider already held by the client configuration. If the two compare as equal, the method returns the existing client unchanged and keeps the existing resolver group:

public T resolver(Consumer<NameResolverProvider.NameResolverSpec> nameResolverSpec) {
	Objects.requireNonNull(nameResolverSpec, "nameResolverSpec");
	NameResolverProvider.Build builder = new NameResolverProvider.Build();
	nameResolverSpec.accept(builder);
	NameResolverProvider provider = builder.build();
	if (provider.equals(configuration().nameResolverProvider)) {
		@SuppressWarnings("unchecked")
		T dup = (T) this;
		return dup;
	}
	// ...
}

NameResolverProvider stores the HostsFileEntriesResolver set through NameResolverSpec#hostsFileEntriesResolver(...) and passes it to the Netty DnsNameResolverBuilder, but its equals and hashCode methods compare every other resolver setting and never consult that field:

NameResolverProvider that = (NameResolverProvider) o;
return completeOncePreferredResolved == that.completeOncePreferredResolved &&
		disableRecursionDesired == that.disableRecursionDesired &&
		// ...
		Objects.equals(resolveCache, that.resolveCache) &&
		Objects.equals(bindAddressSupplier, that.bindAddressSupplier) &&
		Objects.equals(searchDomains, that.searchDomains);

As a result, a resolver configuration that differs from the current one only in its HostsFileEntriesResolver is treated as identical. Reconfiguring a client through resolver(...) silently keeps the previously configured resolver. Independently created clients are affected as well: ClientTransport#runOn(...) obtains its resolver group from a shared cache that treats such providers as the same entry, so a second client receives the resolver group built for the first. In both cases host names are resolved with the old hosts file entries rather than the ones the application supplied, and connections can be made to hosts the application did not intend to reach.

Mitigation

Only recent versions of Reactor Netty are community-supported. Older release lines are End-of-Life and will not receive community updates addressing this issue.

Users of the affected components should apply one of the following mitigations:

• Upgrade Reactor Netty to a currently supported release containing the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.