CVE-2026-49336: Kiota HTTP Fetch Auth Bypass Vulnerability

CVE-2026-49336 Overview

CVE-2026-49336 affects @microsoft/kiota-http-fetchlibrary, the TypeScript HTTP middleware used by Kiota-generated API clients. The RedirectHandler is documented to strip Authorization and Cookie headers on cross-origin redirects, but the default scrubSensitiveHeaders callback performs case-sensitive property deletion against a headers object that has already been lower-cased upstream. The scrub becomes a no-op, and Bearer tokens or cookies are forwarded across 30x redirects to attacker-controlled hosts. The flaw is reachable with the default middleware chain and no custom configuration.

Critical Impact
Any Kiota-generated TypeScript SDK using BaseBearerTokenAuthenticationProvider leaks its Authorization header to an arbitrary cross-origin redirect target, enabling credential theft.

Affected Products

@microsoft/kiota-http-fetchlibrary version 1.0.0-preview.97
@microsoft/kiota-http-fetchlibrary versions 1.0.0-preview.98 through 1.0.0-preview.100
@microsoft/kiota-http-fetchlibrary version 1.0.0-preview.101

Discovery Timeline

2026-06-19 - CVE-2026-49336 published to NVD
2026-06-23 - Last updated in NVD database

Technical Details for CVE-2026-49336

Vulnerability Analysis

The defect is an information exposure caused by case-sensitive header matching, classified as [CWE-178] Improper Handling of Case Sensitivity. FetchRequestAdapter.getRequestFromRequestInformation normalizes header keys to lowercase before the request reaches the middleware chain. The RedirectHandler then attempts to remove sensitive headers using PascalCase property names such as headers.Authorization and headers.Cookie. Because no property with that exact casing exists on the object, delete silently succeeds without removing anything. When the HTTP client follows a 30x redirect to a different host or scheme, the original Authorization and Cookie headers travel with the new request.

Root Cause

The root cause is a mismatch between header key normalization and header scrubbing. The fetch adapter enforces lowercase keys, while the middleware assumes the original PascalCase keys are preserved. The scrubSensitiveHeaders callback never iterates over the existing keys with a case-insensitive comparison, so it cannot match authorization or cookie as actually stored.

Attack Vector

An attacker who controls or compromises an HTTP endpoint contacted by a Kiota-generated SDK can respond with a 30x redirect to an attacker-controlled host. The client follows the redirect and includes the Bearer token in the Authorization header. Suitable conditions include open-redirect bugs in upstream services, DNS or BGP hijacking of an API endpoint, or a malicious server that the SDK is configured to call. The attacker then captures the token and replays it against the original API.

typescript

// Patch from packages/http/fetch/src/middlewares/options/redirectHandlerOptions.ts
const originalUri = new URL(originalUrl);
const newUri = new URL(newUrl);

// Remove Authorization, Cookie, and Proxy-Authorization headers if the request's scheme or host changes.
// Header keys must be matched case-insensitively because FetchRequestAdapter.getRequestFromRequestInformation
// lower-cases every header key before the headers object reaches this middleware, so PascalCase
// property deletes such as `delete headers.Authorization` would otherwise be a no-op.
const isDifferentHostOrScheme =
    originalUri.host.toLowerCase() !== newUri.host.toLowerCase() ||
    originalUri.protocol.toLowerCase() !== newUri.protocol.toLowerCase();

if (isDifferentHostOrScheme) {
    for (const key of Object.keys(headers)) {
        const lower = key.toLowerCase();
        if (lower === "authorization" || lower === "cookie" || lower === "proxy-authorization") {
            delete headers[key];
        }
    }
}

Source: GitHub Commit 09f8bd9

Detection Methods for CVE-2026-49336

Indicators of Compromise

Outbound HTTPS requests from application hosts to unexpected domains shortly after legitimate API calls to Microsoft Graph or other Kiota-generated SDK targets.
HTTP 301, 302, 307, or 308 responses from upstream APIs that redirect to hosts outside the original API's apex domain.
Authentication logs showing token reuse from IP addresses that do not match the application's egress ranges.

Detection Strategies

Inventory Node.js and browser applications that depend on @microsoft/kiota-http-fetchlibrary between 1.0.0-preview.97 and 1.0.0-preview.101 via package-lock.json or SBOM analysis.
Inspect proxy or egress logs for redirect chains where the Location header points to a host different from the request host.
Correlate identity provider logs for Bearer token introductions from new client IPs after each affected SDK call.

Monitoring Recommendations

Alert on HTTP redirects from trusted API domains to untrusted destinations at the egress proxy.
Monitor for spikes in 30x responses originating from API providers consumed by Kiota SDKs.
Track package version drift in CI to flag deployments still pinned to vulnerable kiota-http-fetchlibrary preview builds.

How to Mitigate CVE-2026-49336

Immediate Actions Required

Upgrade @microsoft/kiota-http-fetchlibrary to version 1.0.0-preview.102 or later in all dependent applications.
Rotate any Bearer tokens, refresh tokens, and cookies that may have been transmitted by affected client builds.
Audit application logs and egress traffic for redirects to unexpected hosts during the exposure window.

Patch Information

Version 1.0.0-preview.102 patches the issue. The fix in pull request #2034 replaces the case-sensitive delete headers.Authorization and delete headers.Cookie statements with a loop that lowercases every header key and removes authorization, cookie, and proxy-authorization. Details are documented in GitHub Security Advisory GHSA-396q-4vc8-28x9 and the GitHub Commit Update.

Workarounds

Supply a custom scrubSensitiveHeaders callback in RedirectHandlerOptions that iterates Object.keys(headers) and deletes matches case-insensitively.
Disable automatic redirect following by setting the redirect handler's maxRedirects to 0 for clients that do not require it.
Restrict outbound HTTP egress from application workloads to an allow-list of expected API hostnames at the network layer.

bash

# Upgrade the vulnerable dependency
npm install @microsoft/kiota-http-fetchlibrary@1.0.0-preview.102

# Verify resolved version in the lockfile
npm ls @microsoft/kiota-http-fetchlibrary