CVE-2026-41715: Reactor Netty HTTP Redirect Credential Leakage Vulnerability

Technical summary

The vulnerability exists in Reactor Netty's HTTP client when handling redirect chains that transition from HTTPS to HTTP. Specifically, when an HTTP 3xx response directs the client to follow a Location header pointing to an unencrypted HTTP URL, credential material (typically in Authorization headers or cookies) is propagated to the insecure endpoint without sanitization. This violates the security model that credentials should not traverse unencrypted channels. The flaw is triggered only when the client's redirect-following feature is actively enabled via configuration. Affected versions span four release branches: 1.0.x (through 1.0.51), 1.1.x (through 1.1.35), 1.2.x (through 1.2.17), and 1.3.x (through 1.3.5).

Business impact

Organizations using Reactor Netty in applications that follow HTTP redirects face a credential exposure risk. If an attacker can influence the redirect target—either through network manipulation, DNS spoofing, or compromised intermediate systems—credentials will be exposed over plaintext HTTP. The impact varies by use case: backend-to-backend API communication is at higher risk than client-facing applications behind reverse proxies. Credential compromise can lead to unauthorized API access, data exfiltration, or lateral movement within service-to-service architectures. The blast radius depends on the sensitivity of the credentials and their scope (narrow API keys vs. broad service accounts).

Affected systems

Any system using Reactor Netty versions 1.0.0–1.0.51, 1.1.0–1.1.35, 1.2.0–1.2.17, or 1.3.0–1.3.5 is affected, provided that the HTTP client is configured to follow redirects. This includes Spring WebFlux-based applications and reactive services that depend on Reactor Netty as the underlying HTTP transport. Organizations should audit their dependency trees to identify transitive use of Reactor Netty and verify whether redirect-following is enabled in their client configurations.

Exploitability

The vulnerability requires two conditions: the application must use an affected version of Reactor Netty with redirect-following enabled, and an attacker must be able to influence the redirect target. Exploitability is rated as having low attack complexity because HTTP redirects are a normal part of web communication and can be triggered by legitimate service updates or network-level attacks. However, the attack does require user interaction (UI:R) in some contexts—the redirect must be initiated as part of a client request. In closed networks or scenarios where redirect targets are controlled and trusted, the risk is mitigated. Public-facing or dynamically-routed services are at higher risk.

Remediation

Upgrade Reactor Netty to a patched version released after the affected ranges. Users should consult the vendor advisory to identify the minimum patched versions for each release branch. Additionally, adopt defensive configuration practices: disable automatic redirect-following if not required by the application logic, or implement custom redirect policies that validate the target scheme and decline redirects to HTTP from HTTPS. Use credential scoping and short-lived tokens where possible to limit the impact of any exposure.

Patch guidance

Verify the patched version numbers in the official Project Reactor or Spring team advisory. Upgrade plans should be coordinated with your dependency management and release cycle. Testing should confirm that redirect behavior remains correct post-patch and that any custom redirect logic is compatible with the updated library. Prioritize this upgrade if your application handles sensitive API credentials or communicates with multiple backend services.

Detection guidance

Monitor HTTP client logs for redirect events, particularly those that transition from HTTPS to HTTP. Implement alerting on protocol downgrades in your application observability stack. Network-level detection can monitor for unencrypted transmission of Authorization headers using HTTPS-to-HTTP redirect chains. Log aggregation tools should flag instances where credentials appear in plaintext HTTP traffic. In application instrumentation, inspect HttpClientRequest events to identify configured redirect policies.

Why prioritize this

Although the CVSS score is 6.1 (MEDIUM), the vulnerability has practical relevance in microservice architectures where credential leakage can have downstream impacts. The issue is not exploited remotely by default (requires redirect-following to be enabled), which limits automatic worm propagation, but the consequences of exploitation—credential compromise—are serious. Organizations with high-value API credentials, multi-tier service meshes, or public-facing services should prioritize patching sooner; those with tightly controlled, trusted networks can accept a longer remediation window.

Risk score, explained

The CVSS 3.1 score of 6.1 reflects a MEDIUM severity. The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N indicates network-based attack surface (AV:N), low attack complexity (AC:L), no privilege requirement (PR:N), and user interaction (UI:R). The scope is changed (S:C) because credential exposure affects confidentiality and integrity of data in transit. Availability is not impacted (A:N). The score appropriately reflects that exploitation is possible but not automatic, and that impact is focused on credential confidentiality rather than system availability or integrity.

Frequently asked questions