CVE-2026-44503

What it actually does

The RedirectHandler middleware in Kiota Java HTTP clients follows HTTP 3xx redirects without clearing all sensitive request headers when the redirect destination changes host or scheme. Although the Authorization header is removed, Cookie, Proxy-Authorization, and application-defined custom headers may be resent to the redirect target. If an attacker can influence a request URL, control a redirecting endpoint, or intercept traffic in a position that can induce redirects, they may receive credentials, session tokens, API keys, tenant identifiers, or other secrets carried in those headers. The issue is primarily a confidentiality flaw; it does not directly provide code execution or data modification, but leaked headers may enable follow-on account, API, or service compromise.

Why it matters to the business

Applications using affected Kiota HTTP middleware may unintentionally disclose authentication material or sensitive business context to third-party or attacker-controlled servers during redirects. The operational risk depends on whether applications send cookies, proxy credentials, or custom secret-bearing headers through Kiota-generated clients and whether they follow redirects to untrusted destinations. EPSS is currently low and the issue is not listed in CISA KEV, but the impact of a successful leak can be high because exposed tokens or cookies may allow unauthorized access to downstream APIs or user sessions.

How an attack unfolds

An attacker first needs a way to cause a Kiota-based client to make a request that receives a redirect to an attacker-controlled host or to a less-trusted scheme. This may occur through user-supplied URLs, compromised or malicious upstream services, open redirects in trusted services, or network-level manipulation where redirects can be injected. The client sends a request containing sensitive headers such as Cookie, Proxy-Authorization, or custom API/session headers. When the server responds with a 3xx Location header pointing to the attacker-controlled destination, the vulnerable RedirectHandler follows the redirect and forwards those sensitive headers instead of stripping them. The attacker records the inbound request on the redirect target and extracts the leaked header values. The stolen material can then be replayed or used for additional attacks, subject to token scope, expiration, binding, and downstream service controls.

How to fix it

Upgrade Kiota and affected Kiota HTTP middleware packages to a version that strips all sensitive headers when following redirects across host or scheme boundaries. No fixed versions were provided in the input, so consult the official Microsoft Kiota advisories, package release notes, and dependency manifests for the corrected versions of com.microsoft.kiota:microsoft-kiota-http-okHttp and any other Kiota runtime packages in use. As compensating controls, disable automatic redirect following for requests carrying sensitive headers, manually validate redirect targets before replaying requests, allow-list trusted redirect destinations, strip Cookie, Proxy-Authorization, and custom secret-bearing headers before following cross-origin redirects, and avoid placing long-lived secrets in custom headers where possible. Rotate any credentials, cookies, or API tokens suspected of exposure.

How to confirm the fix worked

Confirm that all applications using Kiota-generated clients or Kiota HTTP middleware have been inventoried and upgraded to corrected package versions once available. Review dependency files such as Maven or Gradle manifests for com.microsoft.kiota:microsoft-kiota-http-okHttp version 1.9.0 or other affected Kiota packages. Perform a controlled test by configuring a trusted test endpoint to return a 302 redirect to a different host and sending a request with benign test values in Cookie, Proxy-Authorization, and representative custom headers. The fixed behavior should not forward those sensitive headers to the redirected host when the host or scheme changes. Also verify application configuration for redirect allow-lists or disabled automatic redirects on sensitive request paths.

Typical attack path

1. Identify an application or service that uses Kiota Java or another affected Kiota library with automatic redirect handling enabled.
2. Find or create a request flow where the Kiota client sends sensitive headers such as Cookie, Proxy-Authorization, or custom authentication/API headers.
3. Cause the initial request to receive a 3xx redirect to an attacker-controlled host, different domain, or changed scheme.
4. Allow the vulnerable client to automatically follow the redirect.
5. Capture the redirected request on the attacker-controlled endpoint and collect forwarded sensitive headers.
6. Replay or abuse the leaked credentials, cookies, proxy credentials, or tokens against the relevant service if they remain valid and are not otherwise bound or restricted.

How to detect it

To assess prior exploitation, review outbound proxy, egress firewall, DNS, HTTP client, API gateway, and application logs for Kiota-based services that followed HTTP 301, 302, 303, 307, or 308 redirects to unexpected external hosts or to a changed scheme. Focus on requests that originated from applications known to use Kiota and that included Cookie, Proxy-Authorization, or custom authentication headers before a redirect. Inspect server-side application logs, if available, for redirect responses with Location values pointing outside expected domains. In egress logs, correlate an initial request to a legitimate or expected endpoint followed immediately by a request from the same application host or service identity to a different host with the same path, method, or timing pattern. Look for requests to newly registered domains, raw IP addresses, unusual ports, HTTP instead of HTTPS, or domains not on an approved API allow-list. If full packet capture or HTTP header logging is available, search for sensitive headers being sent to non-approved destinations. Because no public exploit artifacts or named threat actors are provided, detection should be behavior-based rather than relying on fixed malware indicators.

• com.microsoft.kiota:microsoft-kiota-http-okHttp:1.9.0
• microsoft-kiota-http-okHttp-1.9.0.jar
• HTTP 301
• HTTP 302
• HTTP 303
• HTTP 307
• HTTP 308
• Location: http://
• Location: https://
• Proxy-Authorization:
• Cookie:

What your security team should do

• Inventory applications and services using Kiota libraries, especially com.microsoft.kiota:microsoft-kiota-http-okHttp v1.9.0.
• Prioritize systems that send cookies, proxy credentials, API keys, bearer-like custom headers, tenant secrets, or session material through Kiota clients.
• Upgrade to vendor-fixed Kiota package versions as soon as they are available and standardize dependency constraints to prevent reintroduction of vulnerable versions.
• Until patched, disable automatic redirect following or enforce a redirect allow-list for requests carrying sensitive headers.
• Search logs for outbound redirects from trusted API hosts to unexpected domains, IP addresses, or downgraded schemes.
• Rotate exposed or high-risk credentials if suspicious redirects or requests to untrusted redirect destinations are identified.
• Add regression tests ensuring sensitive headers are stripped on cross-host and cross-scheme redirects.
• Monitor vendor advisories because exploit maturity is currently reported as none, but exploitation may be simple where an attacker can influence redirect behavior.