CVE-2026-47848

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 HTTP client and server, including the client used to open WebSocket connections.

An information exposure vulnerability (CVE-2026-47848) has been identified in the Reactor Netty HTTP client, which allows attackers to obtain credentials when a WebSocket handshake is redirected to a different origin. When the client has been configured to follow redirects, the Cookie, Authorization and Proxy-Authorization headers of the original handshake are sent on to the redirect target.

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.3.0 <1.3.7, >=1.1.0 <1.2.19, <1.0.53
• 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.50

Vulnerability Info

This Medium-severity vulnerability is found in the io.projectreactor.netty:reactor-netty-http package in multiple versions of Reactor Netty. When the HTTP client follows a redirect, HttpClientConnect prepares each new request in requestWithBody. For a redirect to a different origin, that method is meant to strip the Expect, Cookie, Authorization and Proxy-Authorization headers before the request is sent. WebSocket requests, however, return from the method before that code is reached:

ch.listener().onStateChange(ch, HttpClientState.REQUEST_PREPARED);
if (websocketClientSpec != null) {
	Mono<Void> result =
			Mono.fromRunnable(() -> ch.withWebsocketSupport(websocketClientSpec));
	if (handler != null) {
		result = result.thenEmpty(Mono.fromRunnable(() -> Flux.concat(handler.apply(ch, ch))));
	}
	return result;
}

Consumer<HttpClientRequest> consumer = null;
if (fromURI != null && !toURI.equals(fromURI)) {
	if (handler instanceof RedirectSendHandler) {
		headers.remove(HttpHeaderNames.EXPECT)
		       .remove(HttpHeaderNames.COOKIE)
		       .remove(HttpHeaderNames.AUTHORIZATION)
		       .remove(HttpHeaderNames.PROXY_AUTHORIZATION);
	}
	// ...
}

The WebSocket client operations do follow redirects: when the handshake response is a redirect rather than a 101 Switching Protocols, WebsocketClientOperations hands it back to HttpClientConnect, which replays the handshake against the Location target with the headers of the original request. An application that opens a WebSocket with followRedirect enabled and sends a session cookie or bearer token can therefore be led to deliver those credentials to any host that the original server, or an attacker able to influence its responses, redirects the handshake to.

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

• Yu Bao from PayPal Cyber Security Team (finder)
• Arpit Jain (finder)