CVE-2025-22227

What it actually does

This flaw can cause a Reactor Netty HTTP client to disclose credentials during specific chained redirect flows when automatic redirect following has been explicitly enabled. In affected scenarios, sensitive request credentials such as Authorization headers or similar authentication material intended for one origin may be forwarded to a different redirect target. The issue is remotely triggerable if an attacker can influence a URL the application requests or control a server that the application contacts, but exploitation depends on redirect handling being enabled and the affected redirect chain being reached.

Why it matters to the business

Applications using the affected HTTP client behavior may unintentionally send credentials to an attacker-controlled or untrusted endpoint, potentially allowing access to downstream APIs, services, or user data protected by those credentials. The current public risk signals are lower urgency than actively exploited internet-facing flaws: EPSS is low, there is no CISA KEV listing, and no known ransomware association was provided. However, the business impact can still be significant where service-to-service credentials, API tokens, or privileged bearer tokens are reused across systems. The listed affected Alpaquita stream package is fixed in linux-lts 6.6.58-r0.

How an attack unfolds

An attacker first needs a way to influence an outbound HTTP request made by an application using Reactor Netty, or to control a legitimate endpoint that the application contacts. The attacker returns a sequence of HTTP redirects rather than a normal response. Because the client has been configured to follow redirects automatically, it processes the redirect chain. In the vulnerable condition, credentials associated with the original request can be retained and sent on a later redirected request to a different origin. The attacker then receives the redirected request and captures the leaked credential from HTTP headers or other authentication material. The attacker may attempt to reuse the exposed credential against APIs, service endpoints, or internal integrations where the credential is valid.

How to fix it

Apply the vendor-fixed package or dependency version. For the listed Alpaquita stream package, update linux-lts to 6.6.58-r0 or later. For applications directly using Reactor Netty, upgrade to a Reactor Netty release containing the fix as provided by the relevant framework or distribution vendor. As a defense-in-depth measure, disable automatic redirect following unless it is strictly required. Where redirects are necessary, only follow redirects to allowlisted schemes, hosts, and domains. Ensure Authorization, Cookie, proxy-authentication, and other sensitive headers are stripped when a redirect crosses origin boundaries. Avoid placing long-lived or highly privileged credentials in outbound requests that may encounter redirects. Rotate credentials that may have been exposed through affected redirect flows.

How to confirm the fix worked

Confirm package and dependency versions using operating system package inventory, software composition analysis, or build manifests, and verify that the listed Alpaquita package is at linux-lts 6.6.58-r0 or later where applicable. Review application configuration for Reactor Netty HTTP clients with redirect following enabled. Validate the fix with a controlled test: send an authenticated request to a test endpoint that returns chained redirects to a different host, then confirm the final redirected request does not contain Authorization, Cookie, or other sensitive authentication headers. Check CI/CD dependency scans and runtime inventories to ensure no vulnerable Reactor Netty builds remain in deployed artifacts.

Typical attack path

1. Identify or induce an application workflow that makes outbound HTTP requests using Reactor Netty with automatic redirect following enabled.
2. Provide a URL or control an endpoint that the application will request.
3. Return a crafted chain of HTTP 3xx redirects that moves the client from the original trusted origin to an attacker-controlled or untrusted origin.
4. Rely on the vulnerable redirect handling behavior to cause credentials to be included in the redirected request.
5. Capture leaked credentials from the attacker-controlled HTTP server logs or request handler.
6. Attempt to reuse the captured credentials against services, APIs, or integrations where they are accepted.

How to detect it

This vulnerability may not leave a unique host artifact, so detection should focus on evidence of suspicious outbound redirect behavior and credential exposure. Review application logs, HTTP client debug logs, API gateway logs, outbound proxy logs, egress firewall logs, and DNS logs for sequences where an authenticated request receives multiple HTTP 3xx responses and then connects to a different host or domain. Look for Authorization, Cookie, Proxy-Authorization, or custom token headers appearing in requests to unexpected external domains after redirects. If full headers are not logged, correlate 301, 302, 303, 307, or 308 responses with subsequent outbound requests from the same application instance to new domains. Investigate any credential use from unfamiliar IP addresses or user agents shortly after suspicious redirect chains. If an attacker-controlled redirect endpoint is suspected, preserve outbound request metadata, DNS lookups, TLS SNI, proxy CONNECT events, and application traces around the time of the request. Named threat actor exploitation was not provided, and the CVE is not listed as KEV, so detection should be behavior-based rather than actor-specific.

• Authorization: Bearer
• Authorization: Basic
• Proxy-Authorization:
• Cookie:
• Set-Cookie:
• HTTP/1.1 301
• HTTP/1.1 302
• HTTP/1.1 303
• HTTP/1.1 307
• HTTP/1.1 308
• Location: http://
• Location: https://
• followRedirect
• followRedirects

What your security team should do

• Prioritize identifying applications and services that use Reactor Netty HTTP client with automatic redirect following enabled.
• Upgrade affected packages and dependencies, including linux-lts on Alpaquita stream to 6.6.58-r0 or later where applicable.
• Disable automatic redirect following by default and require explicit allowlists for redirect destinations where redirects are business-required.
• Add tests to prevent sensitive headers from being forwarded across cross-origin redirects.
• Rotate API tokens, bearer tokens, basic-auth credentials, and service credentials that may have been sent through untrusted redirect chains.
• Review outbound proxy, egress, and application logs for authenticated requests redirected to unexpected external domains.
• Monitor vendor advisories for exact Reactor Netty fixed versions used by application frameworks and downstream distributions.