CVE-2026-47844
Patch Available.
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
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-brave module adds Brave distributed tracing to the Reactor Netty HttpClient and HttpServer, recording a span for each request and response.
An information exposure vulnerability (CVE-2026-47844) has been identified in the Brave tracing integration of the Reactor Netty HTTP server, which allows exception details from one request to be attached to the tracing data of other, unrelated requests. This only happens when the server is configured with Brave tracing.
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-brave - 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-brave
- 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-http-brave package in multiple versions of Reactor Netty. When an HttpServer is decorated for tracing, TracingHttpServerDecorator.decorate() registers a single TracingMapHandle through mapHandle(...). That one instance wraps the handler of every connection and request the server processes, and it keeps the most recent error in an instance field:
static final class TracingMapHandle implements BiFunction<Mono<Void>, Connection, Mono<Void>> {
volatile Throwable throwable;
@Override
public Mono<Void> apply(Mono<Void> voidMono, Connection connection) {
HttpServerRequest braveRequest = connection.channel().attr(REQUEST_ATTR_KEY).get();
Span span = connection.channel().attr(SPAN_ATTR_KEY).get();
return voidMono.doFinally(sig -> {
// ...
HttpServerResponse braveResponse =
new DelegatingHttpResponse(response, braveRequest, throwable);
// ...
handler.handleSend(braveResponse, localSpan);
})
.doOnError(this::throwable)
// ...
}
void throwable(Throwable t) {
this.throwable = t;
}
}
When any request's handler fails, doOnError stores the exception in the shared throwable field, and nothing ever clears it. Every request that completes afterwards, including concurrent requests on other connections, reads that same field in doFinally and passes it to Brave as the error of its own response through DelegatingHttpResponse.error(). Brave then records the other request's exception on the unrelated request's server span. As a result, exception details from one client's request appear in the trace data of other requests, and successful requests are reported as failed.
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.