GHSA-Q6GH-6V2R-HJV3: Cross-Origin Credential Leakage in Micronaut HTTP Client

The vulnerability affects the core HTTP client libraries of the Micronaut Framework, specifically io.micronaut:micronaut-http-client and io.micronaut:micronaut-http-client-core. These libraries provide Netty-based HTTP client implementations used widely in Micronaut microservices to execute outbound HTTP calls.

When configuring an application to use the default HTTP client, the framework automatically handles HTTP redirect status codes (such as 301, 302, 307, and 308). The client is designed to preserve request state and copy headers from the initial request onto the subsequent redirected request.

However, the client did not differentiate between same-origin and cross-origin redirect destinations. This behavior allowed sensitive session credentials, including HTTP Authorization tokens, Proxy-Authorization headers, and local session cookies, to be forwarded to untrusted, external third-party servers.

The root cause of this vulnerability lies in the implementation of the setRedirectHeaders method in the Netty-based HTTP client components (DefaultHttpClient and NettyHttpClient). Historically, the client utilized a static, hardcoded blocklist named REDIRECT_HEADER_BLOCKLIST to filter headers before dispatching a redirected request.

This static blocklist was defined as follows:

private static final HttpHeaders REDIRECT_HEADER_BLOCKLIST;
 
static {
    REDIRECT_HEADER_BLOCKLIST = new DefaultHttpHeaders();
    REDIRECT_HEADER_BLOCKLIST.add(HttpHeaderNames.HOST, "");
    REDIRECT_HEADER_BLOCKLIST.add(HttpHeaderNames.CONTENT_TYPE, "");
    REDIRECT_HEADER_BLOCKLIST.add(HttpHeaderNames.CONTENT_LENGTH, "");
    REDIRECT_HEADER_BLOCKLIST.add(HttpHeaderNames.TRANSFER_ENCODING, "");
    REDIRECT_HEADER_BLOCKLIST.add(HttpHeaderNames.CONNECTION, "");
}

The blocklist only targeted transport-level headers and body-related properties. When preparing the redirect request, the code copied all other original headers without verifying if the target destination host matched the origin of the initial request.

Because the client lacked origin-awareness during redirect processing, any application transmitting bearer tokens or session cookies to a trusted service would unknowingly send those exact same headers to an external server if the trusted service responded with a cross-origin redirect instruction.

To address this flaw, the Micronaut maintainers refactored the HTTP client configuration to categorize and separate filtered headers based on the context of the redirect.

Specifically, the fix introduced class fields to track three separate groups of headers:

1. redirectAlwaysFilteredHeaders: Headers that are stripped regardless of redirect context (e.g., Host, Connection).
2. redirectAdditionalNonPreserveBodyFilteredHeaders: Headers stripped specifically when the HTTP redirect method does not preserve the request body (e.g., Content-Length, Content-Type).
3. redirectCrossOriginFilteredHeaders: High-sensitivity headers that must be stripped exclusively on cross-origin redirects (e.g., Authorization, Proxy-Authorization, Cookie).

The following code comparison details the implementation changes:

// Vulnerable Implementation
private void setRedirectHeaders(@Nullable io.micronaut.http.HttpRequest<?> request, 
                                MutableHttpRequest<Object> redirectRequest) {
    if (request != null) {
        for (Map.Entry<String, List<String>> originalHeader : request.getHeaders()) {
            if (!REDIRECT_HEADER_BLOCKLIST.contains(originalHeader.getKey())) {
                final List<String> originalHeaderValue = originalHeader.getValue();
                if (originalHeaderValue != null && !originalHeaderValue.isEmpty()) {
                    for (String value : originalHeaderValue) {
                        if (value != null) {
                            redirectRequest.header(originalHeader.getKey(), value);
                        } 
                    }
                } 
            }
        }
    }
}

// Patched Implementation
private void setRedirectHeaders(@Nullable io.micronaut.http.HttpRequest<?> request,
                                MutableHttpRequest<Object> redirectRequest,
                                boolean preserveBody) {
    if (request == null) {
        return;
    }
    boolean sameOrigin;
    try {
        // Determine if the redirect destination is the same origin
        sameOrigin = new RequestKey(this, request.getUri())
            .equals(new RequestKey(this, redirectRequest.getUri()));
    } catch (Exception e) {
        sameOrigin = false;
    }
    
    // Resolve blocklist based on destination origin alignment
    DefaultHttpHeaders headersToBlock = resolveRedirectFilteredHeaders(!sameOrigin, preserveBody);
    for (Map.Entry<String, List<String>> originalHeader : request.getHeaders()) {
        String headerName = originalHeader.getKey();
        if (headersToBlock.contains(headerName)) {
            continue;
        }
        // Copy non-filtered headers securely...
    }
}

The logic relies on RequestKey equality to perform the origin check. If the origins do not match, !sameOrigin evaluates to true, forcing the retrieval and addition of the redirectCrossOriginFilteredHeaders to the active blocklist, which effectively prevents the leakage of sensitive credential headers.

An attacker can exploit this vulnerability through several vectors. The most direct approach is leveraging an open redirect vulnerability on a trusted target API, or compromising a trusted host to redirect traffic to an attacker-controlled endpoint.

Step-by-Step Exploitation Workflow:

1. The Micronaut client initiates an authenticated HTTP request containing an OAuth bearer token in the Authorization header to https://trusted-service.com/api.

2. The server at trusted-service.com yields a 302 Found response containing a Location header that points to https://attacker-controlled-site.com/log.

3. The vulnerable HTTP client receives the 302 response. Because it does not recognize https://attacker-controlled-site.com as cross-origin, it creates a new request and retains the original Authorization header containing the bearer token.

4. The client dispatches the request to the attacker's server, which logs all incoming HTTP request headers and captures the active token.

The impact of this vulnerability is rated as High severity. The leakage of sensitive transport credentials allows remote attackers to perform full session hijacking, account takeover, or unauthorized downstream operations.

Because many corporate enterprise architectures utilize centralized identity providers, OAuth 2.0 bearer tokens, or JWTs, a single compromised token can grant access to a wide array of connected backend services. If the vulnerable client is configured to communicate with internal microservices, the leaked credentials can enable lateral movement across internal network boundaries.

Furthermore, if the application runs within a cloud infrastructure and queries metadata services using custom tokens, a cross-origin redirect triggered by external input can lead to cloud-level privilege escalation.

While the official patches systematically block default authentication headers (Authorization, Proxy-Authorization, and Cookie), security teams must evaluate and manage residual risks related to custom authorization schemes.

Many API architectures use non-standard, custom HTTP headers to pass API keys or JWT tokens (e.g., X-Api-Key, X-Auth-Token, or X-Access-Token). The default patched implementation does not include these custom headers in the default redirectCrossOriginFilteredHeaders blocklist.

Consequently, applications using custom security headers remain vulnerable to credential leakage during cross-origin redirects unless developers explicitly configure the client to filter those specific custom header keys.

The definitive remediation is to upgrade the Micronaut framework dependencies to the patched versions.

Required Upgrades

• For Micronaut Core 3.x: Ensure the framework is upgraded to a version containing the fix in commit 64e539736b8168f201d868b02ace50fe14f57418.
• For Micronaut Core 4.x: Ensure the framework is upgraded to a version containing the fixes in commits 70cab4b44fbf985faba2846091f2356b5bd70719 and 9770328999f490bdfbb9e25addd45bf73d4a173a.

Temporary Workarounds and Configurations

If immediate dependency upgrades are not feasible, apply the following configurations to mitigate the risk:

1. Disable automatic redirect following on the HTTP client if the business logic does not strictly require it:

micronaut:
  http:
    client:
      follow-redirects: false

2. Explicitly define custom security headers to be filtered during cross-origin redirects in the application configuration file:

micronaut:
  http:
    client:
      redirect-cross-origin-filtered-headers:
        - "Authorization"
        - "Proxy-Authorization"
        - "Cookie"
        - "X-Api-Key"
        - "X-Auth-Token"