CVE-2026-41715 Overview
CVE-2026-41715 is a credential exposure vulnerability in the Reactor Netty HTTP client. The flaw occurs when the client follows HTTP redirects from a secure (HTTPS) endpoint to an insecure (HTTP) endpoint. In this scenario, authentication credentials attached to the original request can be forwarded to the redirect target in cleartext. The issue only affects applications that explicitly configure the HTTP client to follow redirects. The vulnerability is tracked under [CWE-522: Insufficiently Protected Credentials].
Critical Impact
Reactor Netty HTTP client may transmit authentication credentials over an unencrypted channel after following a redirect to an HTTP endpoint, enabling network attackers to intercept user credentials.
Affected Products
- Reactor Netty 1.0.0 through 1.0.51
- Reactor Netty 1.1.0 through 1.1.35
- Reactor Netty 1.2.0 through 1.2.17
- Reactor Netty 1.3.0 through 1.3.5
Discovery Timeline
- 2026-06-09 - CVE-2026-41715 published to NVD
- 2026-06-09 - Last updated in NVD database
Technical Details for CVE-2026-41715
Vulnerability Analysis
Reactor Netty is the reactive HTTP client and server library used by Spring WebFlux and other reactive Java applications. The vulnerability arises in the redirect-following logic of the HTTP client. When an application issues an authenticated request to an HTTPS URL and the server responds with a redirect (3xx status) to an HTTP URL, the client reissues the request to the new location while preserving the Authorization header and other credential-bearing headers. Because the follow-up request is sent over plaintext HTTP, the credentials traverse the network in cleartext.
The flaw requires user interaction in the sense that the attacker must induce a redirect chain that crosses scheme boundaries. The scope is changed because credentials intended for the original HTTPS host are disclosed to a different, lower-trust host.
Root Cause
The root cause is the absence of a downgrade check when constructing the follow-up request after a redirect. The client does not strip Authorization, cookie, or proxy-authentication headers when the redirect target uses a less secure scheme than the originating request. This violates the principle that credentials should not be transmitted over channels weaker than those for which they were issued.
Attack Vector
An attacker who controls or compromises a server reachable via the application's HTTP client can return a 301, 302, 307, or 308 redirect pointing to an attacker-controlled HTTP endpoint. If the original request carried an Authorization header or session cookie, those credentials are sent to the attacker's endpoint. An attacker positioned on the network path between the client and the HTTP redirect target can also passively capture credentials in transit. Exploitation requires the application to have enabled followRedirect(true) on its HttpClient instance.
No verified proof-of-concept code has been published. Refer to the Spring Security advisory for CVE-2026-41715 for technical details.
Detection Methods for CVE-2026-41715
Indicators of Compromise
- Outbound HTTP (port 80) traffic from Java application servers containing Authorization headers or session cookies.
- Unexpected 3xx redirect responses from upstream HTTPS services pointing to HTTP URLs on unrelated domains.
- Authentication failures or anomalous logins from IP addresses associated with redirect destinations rather than the intended API host.
Detection Strategies
- Inspect application dependency manifests (pom.xml, build.gradle) for reactor-netty-http versions within the affected ranges.
- Audit source code for calls to HttpClient.followRedirect(true) or followRedirect(BiPredicate) without a custom redirect filter that strips credentials.
- Use a network sensor or proxy to flag plaintext HTTP requests originating from services that should only communicate over TLS.
Monitoring Recommendations
- Forward egress proxy logs and TLS inspection logs to a centralized analytics platform and alert on Authorization headers observed on cleartext HTTP.
- Monitor for redirect chains that change scheme from https:// to http:// in HTTP client telemetry.
- Track Reactor Netty library versions across the build inventory to identify hosts still running vulnerable releases.
How to Mitigate CVE-2026-41715
Immediate Actions Required
- Upgrade Reactor Netty to a patched release: 1.0.52, 1.1.36, 1.2.18, or 1.3.6 or later, depending on the branch in use.
- Audit applications that set followRedirect(true) and disable automatic redirect following where it is not required.
- Rotate any static credentials or API tokens that may have been transmitted by services running affected versions.
Patch Information
The Reactor Netty maintainers have released fixed versions across all supported branches. Consult the Spring Security advisory for CVE-2026-41715 for the exact patched version corresponding to each affected branch and for backport guidance.
Workarounds
- Disable redirect following by configuring HttpClient.create().followRedirect(false) and handle redirects explicitly in application code.
- Provide a custom redirectRequestBiConsumer that removes Authorization, Cookie, and Proxy-Authorization headers before the follow-up request is issued.
- Enforce HTTPS-only egress at the network layer so downgrade redirects to HTTP fail before credentials are transmitted.
# Maven dependency override example - replace with the patched version for your branch
mvn versions:use-dep-version -Dincludes=io.projectreactor.netty:reactor-netty-http -DdepVersion=1.2.18 -DforceVersion=true
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

