CVE-2026-49336
ŚrednieCVSS 5.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 46 — wyżej niż 46% wszystkich znanych CVE
Streszczenie
W wersjach 1.0.0-preview.97 do 1.0.0-preview.101 biblioteka @microsoft/kiota-http-fetchlibrary niepoprawnie obsługuje nagłówki `Authorization` i `Cookie` w przypadku przekierowań między źródłami. Domyślna funkcja `scrubSensitiveHeaders` nie usuwa tych nagłówków, co pozwala na ich przekazywanie do złośliwych hostów.
Ocena ryzyka
Organizacje mogą być narażone na ataki, w których tokeny Bearer lub ciasteczka są przekazywane do kontrolowanych przez atakujących hostów, co może prowadzić do nieautoryzowanego dostępu do zasobów.
Rekomendacja
Zaleca się aktualizację biblioteki @microsoft/kiota-http-fetchlibrary do wersji 1.0.0-preview.102 lub nowszej, aby załatać tę podatność.
Oryginalny opis (angielski, źródło NVD)
@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.