CVE-2026-49336

@microsoft/kiota-http-fetchlibrary provides TypeScript libraries for Kiota-generated API clients. In versions 1.0.0-preview.97 through 1.0.0-preview.101, @microsoft/kiota-http-fetchlibrary's RedirectHandler is documented as stripping Authorization and Cookie from cross-origin redirect targets, but the default scrubSensitiveHeaders callback in RedirectHandlerOptions uses case-sensitive property deletion (delete headers.Authorization, delete headers.Cookie) on a headers object that FetchRequestAdapter.getRequestFromRequestInformation has already lower-cased. The delete therefore targets keys that do not exist, the scrub is a no-op, and any Bearer token or Cookie attached by a kiota-generated SDK is forwarded to an attacker-controlled host across a 30x redirect. This is reachable in the default middleware chain (MiddlewareFactory.getDefaultMiddlewares) with no custom configuration, and applies to every kiota-generated TypeScript SDK that uses BaseBearerTokenAuthenticationProvider or any other authentication provider that sets the Authorization request header. Version 1.0.0-preview.102 patches the issue.

@microsoft/kiota-http-fetchlibrary provides TypeScript libraries for Kiota-generated API clients. In versions 1.0.0-preview.97 through 1.0.0-preview.101, @microsoft/kiota-http-fetchlibrary's RedirectHandler is documented as stripping Authorization and Cookie from cross-origin redirect targets, but the default scrubSensitiveHeaders callback in RedirectHandlerOptions uses case-sensitive property deletion (delete headers.Authorization, delete headers.Cookie) on a headers object that FetchRequestAdapter.getRequestFromRequestInformation has already lower-cased. The delete therefore targets keys that do not exist, the scrub is a no-op, and any Bearer token or Cookie attached by a kiota-generated SDK is forwarded to an attacker-controlled host across a 30x redirect. This is reachable in the default middleware chain (MiddlewareFactory.getDefaultMiddlewares) with no custom configuration, and applies to every kiota-generated TypeScript SDK that uses BaseBearerTokenAuthenticationProvider or any other authentication provider that sets the Authorization request header. Version 1.0.0-preview.102 patches the issue.

Summary

@microsoft/kiota-http-fetchlibrary's RedirectHandler is documented as stripping Authorization and Cookie from cross-origin redirect targets, but the default scrubSensitiveHeaders callback in RedirectHandlerOptions uses case-sensitive property deletion (delete headers.Authorization, delete headers.Cookie) on a headers object that FetchRequestAdapter.getRequestFromRequestInformation has already lower-cased. The delete therefore targets keys that do not exist, the scrub is a no-op, and any Bearer token or Cookie attached by a kiota-generated SDK is forwarded to an attacker-controlled host across a 30x redirect.

This is reachable in the default middleware chain (MiddlewareFactory.getDefaultMiddlewares) with no custom configuration, and applies to every kiota-generated TypeScript SDK that uses BaseBearerTokenAuthenticationProvider or any other authentication provider that sets the Authorization request header.

Affected versions

@microsoft/kiota-http-fetchlibrary >= 1.0.0-preview.97 (the release that introduced the defaultScrubSensitiveHeaders callback, commit 74886cc4, tagged 2026-02-27) up to and including 1.0.0-preview.101 (latest at filing). The bug was verified end-to-end against the version published on npm: 1.0.0-preview.100.

The case-mismatch primitive (lowercasing in the request adapter) predates the scrub itself — FetchRequestAdapter.getRequestFromRequestInformation has lower-cased header keys via toLocaleLowerCase() since commit d612bac2 (2022-12-09). When the scrub was added in 2026-02 it inherited the mismatch.

Impact

• Bearer token leak across origin. When a kiota-generated SDK calls a server that the SDK trusts (Microsoft Graph, an internal API, any OAuth2 resource server) and that server returns an HTTP redirect to a different host, the Authorization: Bearer <token> header issued by the auth provider is sent in cleartext to the redirect target. The redirect target can be controlled by:
  • An attacker who can corrupt or MITM a single 30x response from the legitimate host (downgrade-on-redirect amplifier).
  • An attacker who has temporarily compromised a low-trust endpoint of the upstream API and can issue 302 responses (e.g. a public profile-image URL on Graph that returns 302 to attacker-controlled storage).
  • An attacker who can persuade the kiota-using application to call an attacker-chosen base URL that returns 302 to the attacker (a confused-deputy SSRF-style abuse where the application proxies a user-supplied URL through a kiota-built client).
• Session cookie leak across origin. If the application or generated SDK attaches a Cookie header, the same primitive forwards it to the redirect target.
• No user interaction required. The default middleware chain is in effect; the application does not need to opt in to the bug.

Vulnerable code

The two pieces that combine into the bug.

1. Headers are lower-cased on the way out of the request adapter.

packages/http/fetch/src/fetchRequestAdapter.ts:529-532:

const headers: Record<string, string> | undefined = {};
requestInfo.headers?.forEach((_, key) => {
    headers[key.toString().toLocaleLowerCase()] = this.foldHeaderValue(requestInfo.headers.tryGetValue(key));
});

The headers object that flows into the middleware pipeline as fetchRequestInit.headers has every key lower-cased. So Authorization becomes authorization, Cookie becomes cookie.

2. The default redirect scrub deletes case-sensitive property names.

packages/http/fetch/src/middlewares/options/redirectHandlerOptions.ts:67-82:

private static readonly…

@microsoft/kiota-http-fetchlibrary provides TypeScript libraries for Kiota-generated API clients. In versions 1.0.0-preview.97 through 1.0.0-preview.101, @microsoft/kiota-http-fetchlibrary's RedirectHandler is documented as stripping Authorization and Cookie from cross-origin redirect targets, but the default scrubSensitiveHeaders callback in RedirectHandlerOptions uses case-sensitive property deletion (delete headers.Authorization, delete headers.Cookie) on a headers object that FetchRequestAdapter.getRequestFromRequestInformation has already lower-cased. The delete therefore targets keys that do not exist, the scrub is a no-op, and any Bearer token or Cookie attached by a kiota-generated SDK is forwarded to an attacker-controlled host across a 30x redirect. This is reachable in the default middleware chain (MiddlewareFactory.getDefaultMiddlewares) with no custom configuration, and applies to every kiota-generated TypeScript SDK that uses BaseBearerTokenAuthenticationProvider or any other authentication provider that sets the Authorization request header. Version 1.0.0-preview.102 patches the issue.

@microsoft/kiota-http-fetchlibrary provides TypeScript libraries for Kiota-generated API clients. In versions 1.0.0-preview.97 through 1.0.0-preview.101, @microsoft/kiota-http-fetchlibrary's RedirectHandler is documented as stripping Authorization and Cookie from cross-origin redirect targets, but the default scrubSensitiveHeaders callback in RedirectHandlerOptions uses case-sensitive property deletion (delete headers.Authorization, delete headers.Cookie) on a headers object that FetchRequestAdapter.getRequestFromRequestInformation has already lower-cased. The delete therefore targets keys that do not exist, the scrub is a no-op, and any Bearer token or Cookie attached by a kiota-generated SDK is forwarded to an attacker-controlled host across a 30x redirect. This is reachable in the default middleware chain (MiddlewareFactory.getDefaultMiddlewares) with no custom configuration, and applies to every kiota-generated TypeScript SDK that uses BaseBearerTokenAuthenticationProvider or any other authentication provider that sets the Authorization request header. Version 1.0.0-preview.102 patches the issue.

Summary

@microsoft/kiota-http-fetchlibrary's RedirectHandler is documented as stripping Authorization and Cookie from cross-origin redirect targets, but the default scrubSensitiveHeaders callback in RedirectHandlerOptions uses case-sensitive property deletion (delete headers.Authorization, delete headers.Cookie) on a headers object that FetchRequestAdapter.getRequestFromRequestInformation has already lower-cased. The delete therefore targets keys that do not exist, the scrub is a no-op, and any Bearer token or Cookie attached by a kiota-generated SDK is forwarded to an attacker-controlled host across a 30x redirect.

This is reachable in the default middleware chain (MiddlewareFactory.getDefaultMiddlewares) with no custom configuration, and applies to every kiota-generated TypeScript SDK that uses BaseBearerTokenAuthenticationProvider or any other authentication provider that sets the Authorization request header.

Affected versions

@microsoft/kiota-http-fetchlibrary >= 1.0.0-preview.97 (the release that introduced the defaultScrubSensitiveHeaders callback, commit 74886cc4, tagged 2026-02-27) up to and including 1.0.0-preview.101 (latest at filing). The bug was verified end-to-end against the version published on npm: 1.0.0-preview.100.

The case-mismatch primitive (lowercasing in the request adapter) predates the scrub itself — FetchRequestAdapter.getRequestFromRequestInformation has lower-cased header keys via toLocaleLowerCase() since commit d612bac2 (2022-12-09). When the scrub was added in 2026-02 it inherited the mismatch.

Impact

• Bearer token leak across origin. When a kiota-generated SDK calls a server that the SDK trusts (Microsoft Graph, an internal API, any OAuth2 resource server) and that server returns an HTTP redirect to a different host, the Authorization: Bearer <token> header issued by the auth provider is sent in cleartext to the redirect target. The redirect target can be controlled by:
  • An attacker who can corrupt or MITM a single 30x response from the legitimate host (downgrade-on-redirect amplifier).
  • An attacker who has temporarily compromised a low-trust endpoint of the upstream API and can issue 302 responses (e.g. a public profile-image URL on Graph that returns 302 to attacker-controlled storage).
  • An attacker who can persuade the kiota-using application to call an attacker-chosen base URL that returns 302 to the attacker (a confused-deputy SSRF-style abuse where the application proxies a user-supplied URL through a kiota-built client).
• Session cookie leak across origin. If the application or generated SDK attaches a Cookie header, the same primitive forwards it to the redirect target.
• No user interaction required. The default middleware chain is in effect; the application does not need to opt in to the bug.

Vulnerable code

The two pieces that combine into the bug.

1. Headers are lower-cased on the way out of the request adapter.

packages/http/fetch/src/fetchRequestAdapter.ts:529-532:

const headers: Record<string, string> | undefined = {};
requestInfo.headers?.forEach((_, key) => {
    headers[key.toString().toLocaleLowerCase()] = this.foldHeaderValue(requestInfo.headers.tryGetValue(key));
});

The headers object that flows into the middleware pipeline as fetchRequestInit.headers has every key lower-cased. So Authorization becomes authorization, Cookie becomes cookie.

2. The default redirect scrub deletes case-sensitive property names.

packages/http/fetch/src/middlewares/options/redirectHandlerOptions.ts:67-82:

private static readonly…