Is there a public PoC exploit available for EUVD-2026-38061?

Yes, a public proof-of-concept exploit is available for EUVD-2026-38061. Prioritise patching immediately. EPSS: 0.7%.

Is there a patch available for EUVD-2026-38061?

Yes, a patch is available for EUVD-2026-38061. Update the affected software to the latest version immediately.

kiota-http-fetchlibrary EUVD-2026-38061

Q: What is the CVSS score of EUVD-2026-38061?

EUVD-2026-38061 has a CVSS 4.0 base score of 5.5 (Medium). CVSS vector: 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. EPSS exploitation probability: 0.7%.

| CVE-2026-49336 MEDIUM

Improper Handling of Case Sensitivity (CWE-178)

2026-06-19 GitHub_M

GHSA-396q-4vc8-28x9

Information Disclosure Microsoft Kiota Typescript

5.5

CVSS 4.0 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

5.5 MEDIUM

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

vuln.today AI

3.7 LOW

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.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jun 19, 2026 - 21:02 EUVD

Source Code Evidence Fetched

Jun 19, 2026 - 19:04 vuln.today

Analysis Generated

Jun 19, 2026 - 19:04 vuln.today

CVE Published

Jun 19, 2026 - 18:19 cve.org

MEDIUM 5.5

DescriptionCVE.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. Proof-of-concept code exists (CVSS 4.0 E:P), and a vendor patch is available in version 1.0.0-preview.102; no active exploitation has been confirmed in the CISA KEV at time of analysis.

Technical ContextAI

The affected package is @microsoft/kiota-http-fetchlibrary, part of the kiota-typescript ecosystem (CPE: cpe:2.3:a:microsoft:kiota-typescript:*:*:*:*:*:*:*:*). The root cause is CWE-178 (Improper Handling of Case Sensitivity): FetchRequestAdapter.getRequestFromRequestInformation normalizes all HTTP request header keys to lowercase before the headers object reaches any middleware, so by the time RedirectHandler executes, the Authorization header is stored as authorization and Cookie as cookie. The default scrubSensitiveHeaders callback in RedirectHandlerOptions used static property deletion - delete headers.Authorization and delete headers.Cookie - which targets non-existent PascalCase keys, making the scrub a complete and silent no-op. The bug was introduced in this window of preview versions and is embedded in MiddlewareFactory.getDefaultMiddlewares, making it universally active in default SDK setups. The fix in commit 09f8bd9b replaces static deletes with a case-insensitive loop over Object.keys() matching against lowercased comparisons, and also extends coverage to proxy-authorization, which was previously unaddressed.

RemediationAI

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. The patch is detailed in commit 09f8bd9b34d68bf412a9b78f6ca7e7961ef14974 and the GitHub advisory at https://github.com/microsoft/kiota-typescript/security/advisories/GHSA-396q-4vc8-28x9. If an immediate upgrade is not feasible, a targeted workaround is to supply a custom scrubSensitiveHeaders callback in RedirectHandlerOptions that iterates header keys case-insensitively (replicating the fix locally) - this avoids disrupting redirect-dependent API flows while closing the exposure. A more disruptive but complete compensating control is to configure the middleware chain with maxRedirects: 0 to disable automatic redirect following entirely; this eliminates the leakage path but will break any API calls that depend on legitimate server-side redirects, requiring callers to handle redirects manually. Given the default-on exposure path, upgrading to 1.0.0-preview.102 is strongly preferred over workarounds.