SSRF w Azure MCP Server może spowodować wyciek tokenu tożsamości zarządzanej do adresu URL

Microsoft opublikował CVE-2026-26118 10 marca 2026 r.: lukę typu server-side request forgery w Azure MCP Server Tools, pakiecie, który pozwala agentom AI i klientom MCP działać na zasobach Azure w języku naturalnym. Atakujący, który może wchodzić w interakcję z agentem opartym na MCP, mógłby przesłać złośliwy URL w miejsce normalnego identyfikatora zasobu Azure; serwer wysłałby wtedy żądanie wychodzące na ten adres i, jak ujmuje to Microsoft, „może dołączyć swój token tożsamości zarządzanej” — przekazując wywołującemu poświadczenie, którego nigdy nie powinien był zobaczyć. Microsoft ocenił lukę na CVSS 8.8 i nadał jej ocenę Important, a pakiety zawierające poprawkę to 1.0.2 i 2.0.0-beta.17. W biuletynie nie odnotowano wykorzystania ani publicznego ujawnienia przed poprawką, nie odnotowano też żadnych rzeczywistych szkód z jej powodu. Ten incydent to jeden z wpisów w the Orca AI Incident Archive, który zawiera pełny zapis wraz z cytowanymi źródłami, oceną ważności i oceną pewności.

Co tak naprawdę mówi komunikat

Zapis Microsoft Security Response Center jest zwięzły, a niemal każdy opublikowany szczegół na temat tej luki pochodzi z niego albo z odpowiedzi Microsoftu na kilka pytań uzupełniających. Pełny opis: „Fałszowanie żądań po stronie serwera (ssrf) w Azure MCP Server umożliwia uprawnionemu atakującemu podniesienie uprawnień w sieci”. Rekord CVE zastrzegł identyfikator 11 lutego 2026 r. i upublicznił go 10 marca o 14:00 UTC; nota wydania Microsoftu oraz wpis NVD oba podają tę datę. NVD przeanalizował rekord i opublikował go o 18:18 UTC tego samego popołudnia. Jedyna nota regulatora znaleziona dla tego artykułu pochodziła z Maroka: jednostka maCERT należąca do DGSSI umieściła CVE-2026-26118 w biuletynie z dnia 11 marca 2026 r., wymieniając Azure MCP Server Tools wśród produktów, których dotyczy problem, na własnym poziomie ryzyka „Important”, bez odrębnej punktacji i ze wskazaniem do wydania Microsoftu.

Słabość jest mapowana na CWE-918, fałszowanie żądań po stronie serwera, a klasyfikacja wpływu to podniesienie uprawnień. Ocena bazowa Microsoftu wynosi 8,8 dla wektora CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, a ocena czasowa to 7,7 dla E:U/RL:O/RC:C — składnik E:U oznacza, że w momencie ustalania oceny Microsoft nie znał kodu wykorzystującego lukę, a RL:O oznacza, że dostępna była oficjalna poprawka. NVD podaje tę samą ocenę bazową i klasyfikuje ją jako wysoką; własna trzystopniowa skala Microsoftu określa ją jako ważną.

Dwa pola mają równie duże znaczenie jak wynik. Rekord Microsoftu wskazuje: Wykorzystana: Nie oraz Ujawniona publicznie: Nie. Rekord decyzyjny SSVC CISA dotyczący wpisu w NVD, z datą 5 marca 2026 r., zgadza się w kwestii wykorzystania — brak — oceniając jednocześnie wpływ techniczny jako całkowity, a automatyzację jako nie. Model FIRST EPSS oszacował prawdopodobieństwo wykorzystania w ciągu najbliższych 30 dni na około 1,0%, na poziomie 62,8. percentyla, w danych pobranych 3 listopada 2026 r. To luka, którą znaleziono i naprawiono, a nie taka, o której wiadomo, że została wykorzystana.

Jak identyfikator zasobu staje się żądaniem wychodzącym

Azure MCP Server to implementacja Model Context Protocol firmy Microsoft — interfejsu, którego agenci AI używają do wywoływania narzędzi. Jego narzędzia przyjmują parametry dostarczane przez agenta — nazwę konta magazynu, identyfikator subskrypcji, nazwę bazy danych — i przekształcają je w wywołania względem płaszczyzn zarządzania i danych Azure. Dokumentacja Microsoftu opisuje serwer jako uwierzytelniający się przez Entra ID przy użyciu „Twoich poświadczeń użytkownika Azure lub tożsamości zarządzanej”, przy czym dostęp jest ograniczony przez kontrolę dostępu opartą na rolach Azure.

Wada polega na tym, że parametr, który powinien wskazywać zasób Azure, jest zamiast tego akceptowany jako URL. Wyjaśnienie samego Microsoftu: atakujący „może wykorzystać ten problem, wysyłając specjalnie spreparowane dane wejściowe do narzędzia serwera Azure Model Context Protocol (MCP), które przyjmuje parametry dostarczane przez użytkownika. Jeśli atakujący może wchodzić w interakcję z agentem opartym na MCP, może przesłać złośliwy URL zamiast zwykłego identyfikatora zasobu Azure”. Serwer następnie wysyła żądanie tam, gdzie mu nakazano, a nie tam, gdzie zamierzało je skierować narzędzie.

To, co zamienia uciążliwość w eskalację uprawnień, to to, co jest przenoszone wraz z żądaniem. Microsoft twierdzi, że żądanie wychodzące „może obejmować jego token tożsamości zarządzanej”, co pozwala atakującemu przechwycić ten token „bez konieczności posiadania dostępu administracyjnego”. Token tożsamości zarządzanej jest poświadczeniem typu bearer: każdy, kto go posiada, może przedstawić go usługom Azure, do których ta tożsamość jest upoważniona, aż do wygaśnięcia tokenu. Łagodząca połowa tego samego akapitu jest równie ważna — atakujący uzyskuje „uprawnienia powiązane z tożsamością zarządzaną serwera MCP” i, jak ujmuje to Microsoft, „nie uzyskuje szerszych uprawnień na poziomie dzierżawy ani uprawnień administratora; tylko te powiązane ze skompromitowaną tożsamością zarządzaną”. Zasięg rażenia jest taki, jaki ktoś przyznał tej tożsamości, co w praktyce często wykracza poza to, czego potrzebowało jedno narzędzie.

Microsoft nie podaje nazwy dotkniętego narzędzia ani parametru, a żadne źródło przejrzane na potrzeby tego artykułu również tego nie robi. To pominięcie samo w sobie jest szczegółem: biuletyn doradczy opisuje klasę narzędzi — takich, które przyjmują parametry dostarczone przez użytkownika i można je skłonić do pobrania adresu URL — a nie pojedynczy punkt końcowy.

Poprawka i pakiety, które ją zawierały

To nie była aktualizacja systemu Windows. Narzędzia Azure MCP Server są udostępniane jako pakiet NuGet dla platformy .NET, pakiet npm oraz pakiet Python w PyPI, a poprawka polega na podniesieniu wersji tego pakietu, którego używa dane wdrożenie. W biuletynie firmy Microsoft jako zakresy objęte problemem podano wersje od 1.0.0 do 1.0.2 (z wyłączeniem 1.0.2) oraz od 2.0.0-beta.1 do 2.0.0-beta.17 (z wyłączeniem 2.0.0-beta.17), we wszystkich dystrybucjach NuGet, npm i PyPI.

Daty w rejestrze npm pokazują, że poprawione kompilacje znajdowały się w rejestrze przed biuletynem bezpieczeństwa. Wersja 1.0.2 pakietu @azure/mcp została opublikowana 6 marca 2026 r., cztery dni przed upublicznieniem CVE; wersja 2.0.0-beta.17 została opublikowana 6 lutego 2026 r., pięć dni przed zarezerwowaniem przez Microsoft identyfikatora CVE i miesiąc przed pojawieniem się biuletynu. Niezależnie od tego, jaka była kolejność wewnątrz Microsoftu, poprawiony kod nie powstał w reakcji na dzień publikacji. NVD i baza biuletynów bezpieczeństwa GitHuba zgadzają się co do tych górnych granic. Różnią się nieznacznie na dolnym krańcu zakresu PyPI — NVD podaje 2.0.0-beta.1, biuletyn GitHuba podaje 2.0.0b14 — rozbieżność, którą oba rekordy noszą od publikacji i która wpływa tylko na to, jak daleko wstecz musi sięgać wdrożenie Pythona.

Sam biuletyn zaktualizowano 20 marca 2026 r., dziesięć dni po publikacji, dodając uwagę, że Microsoft „dodał produkty do tabeli Security Updates, które dokumentują różne metody pakowania stosowane do dostarczania Azure MCP Server Tools”. Innymi słowy, pierwsza wersja biuletynu wymieniała produkt, ale nie wszystkie kanały, przez które był dostarczany, co ma znaczenie, gdy środkiem zaradczym jest „aktualizacja pakietu”, a nie „instalacja tej KB”.

Co nie jest ustalone

Kto to odkrył. Ani biuletyn firmy Microsoft, ani wpis w CVE.org nie podają nazwiska zgłaszającego; pole z podziękowaniami w CVE jest puste. Nie jest to jednak dowód, że nikogo nie uhonorowano prywatnie — jedynie że nie istnieje publiczne podziękowanie.

Jakiekolwiek wykorzystanie.Microsoft nie odnotowuje żadnego przypadku, ocena SSVC agencji CISA jest zbieżna, a żadne ze źródeł przeanalizowanych na potrzeby tego artykułu nie opisuje przejęcia tożsamości w rzeczywistym środowisku. Pole dotyczące rzeczywistych szkód w rekordzie ma wartość false, co jest z tym spójne. Niski wskaźnik EPSS to prognoza, a nie ustalenie, a brak zgłoszonego incydentu nie jest dowodem, że do żadnego nie doszło.

Czy publiczny exploit istnieje. To tutaj relacje dodatkowe się rozchodzą. Wpis z marca 2026 r. na blogu Blueinfy stwierdza, że istnieją „publiczne exploity proof-of-concept, takie jak te na GitHubie”, i ostrzega przed „szybką weaponizacją”, ale nie podaje linku, payloadu ani opisu krok po kroku i nie demonstruje luki. Zapis Microsoftu mówi, że podatność nie została publicznie ujawniona przed wydaniem poprawki. Wyszukiwanie w repozytoriach GitHub identyfikatora CVE w dniu 4 listopada 2026 r. zwróciło jedno repozytorium — laboratorium wykrywania Microsoft Sentinel opublikowane 17 marca 2026 r., a nie exploit — a strona podatności Mallory'ego stwierdza, że dwa kandydujące exploity zostały sprawdzone i odrzucone. Twierdzenie o działającym publicznym kodzie exploita jest, na podstawie dostępnych dowodów, niepoparte; twierdzenie, że nikt nie próbował, jest równie nieudowodnione.

Sposób przedstawienia sprawy.Strona w serwisie PolicyLayer, będącym witryną dostawcy podsumowującą incydenty, przedstawia CVE-2026-26118 jako nieuwierzytelniony łańcuch zdalnego wykonania kodu kończący się pełnym przejęciem dzierżawy, przypisując to imiennie wskazanemu badaczowi oraz demonstracji na RSAC 2026. Cytowane na tej stronie źródła mają w tytułach SSRF, jej daty nie zgadzają się z chronologią CVE, a ani biuletyn Microsoftu, ani relacja SecurityWeek z 10 marca nie opisują wykonania kodu. Ten artykuł przyjmuje wersję o SSRF i tokenie za tę ustaloną i nie powtarza ujęcia RCE.

Dlaczego to token, a nie żądanie, jest ustaleniem

Fałszowanie żądań po stronie serwera to jedna z najstarszych klas błędów w oprogramowaniu webowym i samo w sobie zwykle pozwala dotrzeć do systemów, do których atakujący nie może zaadresować bezpośrednio. To, co sprawia, że ten rekord warto zachować, to poświadczenie dołączone do żądania. Serwer MCP jest z założenia zdezorientowanym pełnomocnikiem: przechowuje tożsamość, aby agent mógł działać w imieniu użytkownika, a każdy parametr przekazywany przez agenta jest z punktu widzenia serwera tekstem, na który atakujący ma wpływ. Gdy jeden z tych parametrów staje się celem, a nie nazwą, pełnomocnik przenosi do celu własną autoryzację.

Dokumentacja Microsoftu doprecyzowuje, gdzie koncentruje się to ryzyko. Opisuje lokalny serwer jako „przeznaczony wyłącznie do użytku deweloperów w ramach Twojej organizacji”, jednocześnie osobno publikując przewodniki wdrożeniowe dla samodzielnie hostowanych serwerów zdalnych w Microsoft Foundry i Copilot Studio — czyli konfiguracji, w których zwykle używanym poświadczeniem jest tożsamość zarządzana, a nie własne logowanie dewelopera. Opisana w komunikacie ścieżka kradzieży tokena dotyczy konkretnie tożsamości zarządzanej. Nie stwierdza się w nim, że każda instalacja była narażona, ani nie podaje, ile ich było.

Ogólna lekcja to ta, której Standard Weryfikacji Bezpieczeństwa AI OWASP używa obecnie tego przypadku, by jej nauczać. Rozdział AISVS poświęcony orkiestracji wymienia CVE-2026-26118 wśród swoich omawianych przykładów i wyciąga wniosek, że „parametry narzędzi MCP należy traktować jako kontrolowane przez atakującego, a wychodzące żądania z serwerów MCP muszą przechodzić przez te same zasady ruchu wychodzącego i pochodzenia, jakich oczekuje się od każdego innego wejścia/wyjścia sterowanego przez agenta”. To zalecenie dotyczące mechanizmów kontrolnych, a nie ustalenie na temat tego incydentu, ale jest to najbardziej konkretna odpowiedź, jaką ktokolwiek opublikował na pytanie, co powinno się zmienić.

Co się zmieniło po

Trzy rzeczy — i żadna z nich nie jest dramatyczna. Microsoft wydał poprawione pakiety we wszystkich trzech ekosystemach i zmienił komunikat doradczy, by je wskazać. Ekosystem informacji o zagrożeniach przyjął to po cichu: niski wynik EPSS i rekord NVD ostatnio zmodyfikowany 17 czerwca 2026 r. A społeczność zajmująca się standardami przyjęła to jako przypadek dydaktyczny, co stanowi wolniejszą i trwalszą formę reakcji niż poprawka.

Każdy, kto nadal uruchamia dotkniętą kompilację, musi zastosować te same mało efektowne środki zaradcze: przejść na wersję 1.0.2 lub nowszą w gałęzi stabilnej albo 2.0.0-beta.17 lub nowszą w gałęzi zapoznawczej — w każdym menedżerze pakietów, którego dotyczy wdrożenie. Poza tym logika samego biuletynu wskazuje na trzy mechanizmy kontroli: ograniczenie tego, z czym serwer może łączyć się na zewnątrz, przyznanie tożsamości zarządzanej wyłącznie ról, których faktycznie potrzebują jej narzędzia, oraz traktowanie każdego parametru narzędzia, który może stać się adresem URL, jako wrogich danych wejściowych. Żadna z nich nie jest wymagana, aby CVE-2026-26118 przetrwało. Każda zmniejszyłaby wartość kolejnej z nich dla atakującego.

Jak archiwum klasyfikuje ten element?

Rekord jest zapisany jako podatność — coś, co znaleziono, a nie coś, o czym wiadomo, że zostało wykorzystane — z oceną pewności A, co oznacza, że jest dobrze udokumentowany, a źródła pierwotne są zgodne, i nie jest oznaczony jako sporny. Jego pole real-harm ma wartość fałsz, a udział AI jest potwierdzony, ponieważ dotknięty produkt jest pomostem między agentem AI a płaszczyzną sterowania chmury, a nie usługą ogólnego przeznaczenia, która przypadkiem znajduje się w pobliżu. Data jest zapisana z dokładnością do dnia, 10 marca 2026 r., bez daty końcowej, ponieważ jest to pojedynczy punkt w czasie, a nie kampania. Region jest globalny, a flaga landmark ma wartość fałsz.

Jedno pole odczytuje się inaczej niż w opublikowanej punktacji. Poziom istotności w archiwum jest zapisany jako średni, według jego własnej skali; liczba publikowana zarówno przez Microsoft, jak i NVD wynosi 8.8, którą Microsoft określa jako Important, a NVD klasyfikuje jako High. Podsumowanie rekordu rozpoczyna się od tego 8.8, a rozbieżność wynika z różnicy w przypisaniu do kategorii, a nie w faktach.

To, czego nie potrafi oddać zapis, to jak wielka część tej historii jest nieobecnością. Istnieje luka, która przekazuje tożsamość w chmurze każdemu, kto poprosi o nią w niewłaściwym kształcie. Istnieje poprawka, wydana przed ogłoszeniem. Nie ma wskazanego odkrywcy, nazwanego narzędzia, potwierdzonego wykorzystania ani sposobu, by osoba z zewnątrz ustaliła, czy jakiekolwiek hostowane wdrożenie kiedykolwiek uruchamiało podatną kompilację, mając jednocześnie potężną tożsamość. Biuletyn jest precyzyjny co do tego, co robi luka, a milczy o niemal wszystkim innym — i to milczenie jest najbardziej użyteczną rzeczą, jaką można w nim zauważyć.