CVE-2026-47845

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-http module carries the Reactor Netty HTTP client and server.

An authorization bypass vulnerability (CVE-2026-47845) has been identified in the Reactor Netty HTTP server, which allows attackers to have their requests attributed to the proxy's address instead of their own when HAProxy Protocol is enabled. Applications that make access control, rate limiting or audit decisions based on the client address can then apply them to the wrong address.

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-http
• 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-http
• Package manager: Maven
• Fixed in:
  • OSS Reactor Netty 1.3.7
  • NES for Reactor Netty v1.0.51

Vulnerability Info

This Medium-severity vulnerability is found in the io.projectreactor.netty:reactor-netty-http package in multiple versions of Reactor Netty. It only applies when the HTTP server is configured to use HAProxy Protocol.

When HAProxy Protocol is enabled, HAProxyMessageReader decodes the PROXY header that the proxy sends at the start of each connection and stores the original client address in the REMOTE_ADDRESS_FROM_PROXY_PROTOCOL attribute of the connection channel. The HTTP handlers later look that address up through resolveRemoteAddressFromProxyProtocol, which reads the attribute with getAndSet(null):

@Nullable
static SocketAddress resolveRemoteAddressFromProxyProtocol(Channel channel) {
        if (HAProxyMessageReader.isProxyProtocolAvailable()) {
                return channel.attr(REMOTE_ADDRESS_FROM_PROXY_PROTOCOL).getAndSet(null);
        }

        return null;
}

The read is destructive: the first caller receives the client address and the attribute is cleared for everyone after it. Over HTTP/1.1, HttpTrafficHandler resolves the address once per connection, so this goes unnoticed. Over HTTP/2, however, Http2StreamBridgeServerHandler is created per stream and resolves the address again on the shared parent connection channel, falling back to the TCP peer address when nothing is returned:

if (remoteAddress == null) {
        remoteAddress =
                        Optional.ofNullable(HAProxyMessageReader.resolveRemoteAddressFromProxyProtocol(ctx.channel().parent()))
                                .orElse(ctx.channel().parent().remoteAddress());
}

The first HTTP/2 stream on a proxied connection gets the real client address. Every later stream on the same connection finds the attribute already cleared and is assigned the proxy's own address instead. That address then becomes the request's remote address in ConnectionInfo, which is what the application sees as the client address. A client that sends several requests over one HTTP/2 connection can therefore have its later requests attributed to the proxy, and IP-based allow lists, rate limits or audit logs evaluate the wrong address. Where the proxy's address is trusted, for example as an internal or allow-listed host, this lets an external client bypass IP-based access restrictions.

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.

Credits

• Sam Lightfoot (finder)