The vulnerability occurs when @microsoft/kiota-http-fetchlibrary fails to scrub sensitive authentication headers during cross‑origin redirects. The default case‑sensitive delete operations target header names that have already been lower‑cased, so the Authorization and Cookie headers survive the redirect. An attacker who controls the redirect target can receive the bearer token or cookie sent by a Kiota‑generated SDK, enabling credential theft or session hijacking. The flaw is not an execution or denial‑of‑service issue; it is an unintended disclosure of authentication information.

Microsoft’s Kiota TypeScript libraries are affected, specifically the cleanup logic in versions 1.0.0‑preview.97 through 1.0.0‑preview.101. Any Kiota‑generated SDK that utilizes the BaseBearerTokenAuthenticationProvider or otherwise sets the Authorization header, including those using cookie‑based authentication, falls under this scope. The issue is present in the default middleware chain and is fixed starting with version 1.0.0‑preview.102.

The CVSS score of 5.5 places the flaw in the Moderate range. No EPSS score is available, and the vulnerability is not listed in the CISA KEV. The attack vector is limited to application code that performs a fetch request to an attacker‑controlled host and receives a 30x redirect. Because the problematic code is enabled by default and requires no custom configuration, any application using these SDKs could be compromised if it makes cross‑origin redirects. The risk is therefore moderate but real for systems that might redirect requests to untrusted hosts.