CVE-2026-41715

What it actually does

Reactor Netty HTTP client can expose credentials when it is explicitly configured to follow redirects and receives a redirect from an HTTPS URL to an HTTP URL. In affected versions, sensitive request data such as authorization headers, cookies, tokens, or other credential-bearing headers may be forwarded across the downgrade redirect, allowing the insecure destination or an on-path observer to read them. The flaw affects Reactor Netty 1.0.0 through 1.0.51, 1.1.0 through 1.1.35, 1.2.0 through 1.2.17, and 1.3.0 through 1.3.5. The impact is primarily credential disclosure with possible follow-on unauthorized access depending on the privileges of the leaked credential.

Why it matters to the business

Applications using affected Reactor Netty clients may unintentionally send service credentials, API tokens, session cookies, or bearer tokens to an unencrypted endpoint if a redirect chain downgrades from HTTPS to HTTP. This can lead to unauthorized access to downstream services, data exposure, account takeover of service identities, and loss of trust in integrations. The current exploitation signal is low: EPSS is approximately 0.00172 with no meaningful 30-day increase, no known CISA KEV listing, no ransomware association, and no public exploit maturity reported; however, exposure can still be serious where high-value credentials are used in automated service-to-service calls.

How an attack unfolds

An attacker first needs a way to influence an HTTP request made by an application using the affected Reactor Netty HTTP client. This could be through an attacker-controlled URL, a compromised trusted endpoint, a malicious third-party integration, or any workflow where the application connects to a remote HTTPS endpoint that can return redirects. If the application has enabled automatic redirect following, the attacker responds to the original HTTPS request with a redirect such as an HTTP 301, 302, 303, 307, or 308 pointing to an insecure http:// endpoint. The vulnerable client follows the redirect and may carry credential-bearing headers or cookies from the original secure request to the insecure destination. The attacker then captures those credentials either by operating the HTTP destination or by observing traffic on the network path. The stolen credentials can then be replayed against APIs or services, subject to token scope, expiration, audience restrictions, and any additional authentication controls.

How to fix it

Upgrade Reactor Netty to a version outside the affected ranges. Affected branches are 1.0.0-1.0.51, 1.1.0-1.1.35, 1.2.0-1.2.17, and 1.3.0-1.3.5; use the first fixed or later maintenance release for the branch in use, such as 1.0.52+, 1.1.36+, 1.2.18+, or 1.3.6+ where available. If an immediate upgrade is not possible, disable automatic redirect following for clients that send credentials, block HTTPS-to-HTTP redirect downgrades, strip Authorization/Cookie/credential headers before following redirects, allowlist trusted redirect destinations, and prevent outbound cleartext HTTP where feasible. Rotate any credentials that may have been exposed through redirect-following clients, especially long-lived API keys or bearer tokens used in outbound integrations.

How to confirm the fix worked

Confirm dependency versions through build manifests, dependency trees, SBOMs, runtime classpaths, and deployed artifacts. Look for reactor-netty-http or reactor-netty-core versions in the affected ranges and verify they have been upgraded beyond the vulnerable branch versions. Review code and configuration for Reactor Netty HttpClient redirect behavior, especially followRedirect(true) or custom redirect handlers. Test representative outbound calls by returning a controlled HTTPS-to-HTTP redirect and confirm that the client either refuses the downgrade, strips sensitive headers, or no longer forwards credentials to the insecure endpoint. Validate egress controls by confirming applications cannot send credential-bearing requests over cleartext HTTP to untrusted destinations.

Typical attack path

1. Identify an application or integration that uses Reactor Netty HTTP client with automatic redirect following enabled.
2. Cause the application to make an outbound HTTPS request to an attacker-controlled, compromised, or redirect-capable endpoint.
3. Return an HTTP redirect from the secure HTTPS endpoint to an insecure http:// URL controlled or observable by the attacker.
4. Allow the affected client to follow the downgrade redirect while retaining sensitive headers, cookies, or tokens.
5. Capture leaked credentials at the HTTP endpoint or from network traffic.
6. Replay or abuse the exposed credentials to access downstream APIs, services, or data within the token’s permissions.

How to detect it

To determine whether exploitation already occurred, review outbound HTTP telemetry from applications using Reactor Netty, including application logs, reverse proxy logs, egress proxy logs, API gateway logs, web access logs for controlled redirect endpoints, DNS logs, and packet capture where available. Focus on sequences where an HTTPS request received a 3xx redirect with a Location header pointing to http://, followed by an outbound cleartext HTTP request to the redirected host. Pay particular attention to cleartext HTTP requests containing Authorization, Cookie, X-API-Key, Proxy-Authorization, or other credential-bearing headers. If header logging is not available, correlate redirect responses, destination changes from port 443 to port 80, and unusual outbound HTTP destinations shortly after application-initiated HTTPS calls. Investigate any unexpected external domains receiving cleartext HTTP from backend services. If leaked credentials are suspected, review downstream authentication logs for reuse of those tokens from unusual IP addresses, user agents, geographies, or services, and rotate affected credentials.

• reactor-netty-http-1.0.51.jar
• reactor-netty-http-1.1.35.jar
• reactor-netty-http-1.2.17.jar
• reactor-netty-http-1.3.5.jar
• reactor-netty-core-1.0.51.jar
• reactor-netty-core-1.1.35.jar
• reactor-netty-core-1.2.17.jar
• reactor-netty-core-1.3.5.jar
• followRedirect(true)
• Location: http://
• Authorization: Bearer
• Authorization: Basic
• Proxy-Authorization:
• Cookie:
• X-API-Key:
• http://

What your security team should do

• Inventory Java applications and services that include Reactor Netty, especially Spring WebClient, reactive gateways, service clients, and integration components that may use it transitively.
• Prioritize systems that send Authorization headers, cookies, API keys, OAuth tokens, or service credentials in outbound HTTP requests and have automatic redirect following enabled.
• Upgrade Reactor Netty beyond the affected ranges: 1.0.52+, 1.1.36+, 1.2.18+, or 1.3.6+ where available for the maintained branch.
• Disable or restrict automatic redirect following for credentialed requests, and enforce a policy that blocks HTTPS-to-HTTP redirect downgrades.
• Search proxy, load balancer, application, and egress logs for recent credential-bearing requests sent to http:// destinations after a prior HTTPS redirect.
• Rotate credentials that may have been transmitted over cleartext HTTP or to unexpected redirect destinations.
• Add automated dependency scanning and policy checks to prevent reintroduction of affected Reactor Netty versions.
• Because EPSS is currently low and the CVE is not in KEV, prioritize based on credential sensitivity and internet-facing integration exposure rather than broad emergency patching alone.