Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/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
Attacker must control or manipulate a cross-origin redirect target (non-trivial), justifying AC:H; impact is token disclosure only, so C:L with no I or A impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/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
Lifecycle Timeline
4DescriptionCVE.org
@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.
AnalysisAI
Credential leakage in @microsoft/kiota-http-fetchlibrary versions 1.0.0-preview.97 through 1.0.0-preview.101 causes Bearer tokens and session cookies to be forwarded to attacker-controlled cross-origin redirect destinations because the default RedirectHandler's header-scrubbing logic silently fails: FetchRequestAdapter lowercases all header keys before the middleware sees them, but scrubSensitiveHeaders performs PascalCase deletes (delete headers.Authorization), targeting keys that no longer exist. This flaw is present in the default middleware chain with no opt-in configuration required, affecting every kiota-generated TypeScript SDK - including Microsoft Graph clients - that uses BaseBearerTokenAuthenticationProvider or any auth provider that sets the Authorization header. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires the application to be running @microsoft/kiota-http-fetchlibrary in the default middleware chain (MiddlewareFactory.getDefaultMiddlewares) without any custom RedirectHandlerOptions that override scrubSensitiveHeaders, and to use an authentication provider that sets the Authorization or Cookie request header - the typical configuration for all BaseBearerTokenAuthenticationProvider-based SDK clients. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 4.0 score of 5.5 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L) with E:P indicates a network-exploitable, low-complexity flaw with no privileges or user interaction required and confirmed proof-of-concept code. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An attacker registers a server at attacker.example.com and arranges for a kiota-targeted API endpoint to return a 301 redirect to their domain - achievable through an open redirect vulnerability in the API, a compromised upstream service, or a MITM position on the network path. The victim's kiota-generated TypeScript SDK, running its default middleware chain, follows the redirect and silently forwards the authorization: Bearer <token> header because the scrubSensitiveHeaders no-op leaves it intact. … |
| Remediation | Upgrade @microsoft/kiota-http-fetchlibrary to version 1.0.0-preview.102, which fixes the case-sensitivity bug in scrubSensitiveHeaders and also extends the scrub to cover proxy-authorization. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same weakness CWE-178 – Improper Handling of Case Sensitivity
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-38061
GHSA-396q-4vc8-28x9