Azure AI Foundry nie wymagał poświadczeń do eskalacji uprawnień — CVE-2026-85889, CVSS 10.0

Microsoft ujawnił 17 września 2026 r., że Azure AI Foundry — platforma korporacyjna do budowania, wdrażania i zarządzania aplikacjami oraz agentami generatywnej sztucznej inteligencji, oferowana również pod nazwą Microsoft Foundry — zawierała lukę polegającą na braku uwierzytelniania, ocenioną na CVSS 10.0, czyli maksymalnie. Śledzona jako CVE-2026-85889 i sklasyfikowana jako CWE-306, brak uwierzytelniania dla funkcji krytycznej, pozwalała nieuprawnionemu napastnikowi dotrzeć do funkcji backendu przez sieć i eskalować uprawnienia bez poświadczeń i bez interakcji użytkownika — według biuletynu firmy Microsoft. Platforma jest hostowana w chmurze, więc poprawka została wdrożona w infrastrukturze samego Microsoftu i klienci nie musieli nic instalować; Microsoft twierdzi, że nie znalazł dowodów na jakiekolwiek wykorzystanie tej luki, a nie odnotowano z nią związanych szkód. Ten incydent to jedna z pozycji w the Orca AI Incident Archive, która zawiera pełny zapis wraz z cytowanymi źródłami, oceną istotności, oceną pewności i oznaczeniem sporności.

Co tak naprawdę mówi komunikat

Biuletyn Microsoft Security Response Centerjest krótki i niemal wszystkie opublikowane szczegóły tego błędu pochodzą właśnie z niego. Jego opis w całości brzmi: „Brak uwierzytelniania dla funkcji krytycznej w Azure AI Foundry pozwala nieautoryzowanemu napastnikowi podnieść uprawnienia w sieci”. Nie ma żadnych wersji, których dotyczy problem, ponieważ nie ma wersji: wpis MSRC dotyczący CVE-2026-85889 podaje najnowsze wydanie oprogramowania jako N/A i nie zawiera linków do aktualizacji ani pliku do pobrania, co jest typową formą biuletynu dla usługi prowadzonej przez sam Microsoft.

MSRC ocenia tę lukę jako krytyczną, z wynikiem podstawowym 10,0, dla wektora CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — możliwa do wykorzystania przez sieć, niska złożoność ataku, brak wymaganych uprawnień, brak interakcji użytkownika, zmieniony zakres oraz wysoki wpływ na poufność, integralność i dostępność. Wpis NVD, opublikowany 17 września 2026 r. i ostatnio zmodyfikowany 25 września, zawiera ten sam opis i przypisuje tę słabość do CWE-306. W polach „Exploited” i „Publicly Disclosed” firma Microsoft odnotowuje „Nie” i „Nie”.

Wadę wykrył Rémy Marot, którego uznano w relacji The Hacker News o ujawnieniu i wymieniono w notatce badawczej Cloud Security Alliance jako osobę, która zgłosiła ją odpowiedzialnie. Ta notatka, opublikowana 19 września 2026 r., jest jedynym źródłem w materiale, które analizuje to, co pomija komunikat doradczy, i traktuje tę lukę jako sedno historii.

10,0 i 9,8 — jedyny wskaźnik, w którym dwaj oceniający się nie zgadzają

Liczba podana w nagłówku nie jest jednomyślna. NVD pokazuje dwa wyniki CVSS 3.1 dla CVE-2026-85889, pochodzące od dwóch różnych oceniających, i różnią się one dokładnie jedną metryką. Wynik Microsoftu, zgłoszony jako źródło wtórne, to 10.0 przy AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Własny wynik główny NVD to 9.8 przy AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Wszystkie składniki są identyczne z wyjątkiem Scope.

Microsoft ocenia Scope jako Changed; główna ocena NVD pozostawia go jako Unchanged. Na tym polega cała różnica i nie jest to pedanteria. W CVSS 3.1 zakres Changed oznacza, że podatny komponent i komponent dotknięty skutkami podlegają różnym autorytetom bezpieczeństwa — że punkt zaczepienia atakującego i to, co ostatecznie kontroluje, znajdują się po przeciwnych stronach granicy. Ocena 10.0 to twierdzenie, że przekroczenie tej granicy jest celem tej luki. Ocena 9.8 NVD mówi to samo o wpływie — poufność, integralność i dostępność są ocenione jako High — nie twierdząc jednak, że granica została przekroczona. Obie oceny są Critical. Archiwum nie traktuje tej różnicy jako sporu o to, czy luka istniała albo została naprawiona, i czytelnik również nie powinien.

Trzeci oceniający poszedł dalej w kwestii konsekwencji, nie zmieniając punktacji. CISA – rekord decyzji SSVC dla tego CVE, opatrzony datą 18 września 2026 r., ustawia eksploatację na „brak”, automatyzowalność na „tak”, a wpływ techniczny na „całkowity”. Warto zatrzymać się przy środkowej wartości: luka nieuwierzytelniona, o niskiej złożoności i zmieniająca zakres jest z założenia automatyzowalna — nic w niej nie wymaga, by człowiek dostosowywał ją do każdego celu.

Poprawka, której żaden klient nie mógł zainstalować

Azure AI Foundry to usługa hostowana, więc CVE-2026-85889 nigdy nie miało poprawki sygnowanej nazwą klienta. Biuletyn MSRC nie zawiera artykułu o aktualizacji ani obejścia, a w swoim FAQ odpowiada na oczywiste pytanie: „Ta luka w zabezpieczeniach została już w pełni złagodzona przez Microsoft. Użytkownicy tej usługi nie muszą podejmować żadnych działań. Celem tego CVE jest zapewnienie większej przejrzystości”.

Nota Cloud Security Alliance opisuje ten sam stan rzeczy: remediację zastosowano w infrastrukturze Microsoftu, a „klienci nie mieli żadnej poprawki do zainstalowania ani nie musieli podejmować żadnych działań”. The Hacker News donosi, że Microsoft poinformował, iż w pełni złagodził problem w chmurze i że nie były wymagane żadne działania klientów. Własny rejestr Microsoftu oznacza „wymagane działanie klienta” jako fałsz. Jeśli chodzi o harmonogram, MSRC datuje swój komunikat doradczy na 17 września 2026 r.; nota CSA umieszcza komunikat doradczy i zakończoną remediację w okresie 17–18 września 2026 r.

To jest punkt, do którego notatka CSA wciąż powraca, i nie jest to krytyka inżynierii Microsoftu. Poprawka po stronie serwera jest szybka, kompletna i bezpłatna dla klienta. Jest jednak również niezauważalna z perspektywy klienta.

Czego Microsoft nie powiedział

Według Cloud Security Alliance komunikat nie podaje, kiedy wprowadzono podatność, a nota nie określa ilościowo okna ekspozycji. Microsoft nie ujawnia również, w jaki sposób można było dotrzeć do podatnej funkcji, jaki typ poświadczeń był zaangażowany, czy do jej wykorzystania potrzebne były identyfikatory specyficzne dla dzierżawy ani czy możliwy był dostęp między dzierżawami. To nie są luki w raportowaniu; to pytania, które — jak wyraźnie stwierdza nota CSA — Microsoft pozostawił otwarte, a pytanie o dostęp między dzierżawami wymienia jako istotne dla oceny ryzyka każdego klienta.

Wniosek, jaki nasuwa się z notatki, jest wąski i wart przedstawienia bez upiększeń: jeśli wykorzystanie następuje w całości po stronie serwera, może w ogóle nie być widoczne po stronie klienta. Administrator dzierżawy mógł nie mieć żadnego wiersza dziennika, na który mógłby spojrzeć, nawet gdyby jego projekty były sondowane. Zalecana przez CSA reakcja ma charakter retrospektywny — należy przejrzeć dzienniki aktywności Azure i ścieżki audytu AI Foundry z tygodni poprzedzających 17–18 września 2026 r. w poszukiwaniu nietypowych działań administracyjnych, zmian konfiguracji modeli lub agentów oraz anomalnego dostępu kont usługi, a także zapytać Microsoft bezpośrednio, czy dostęp między dzierżawami był technicznie możliwy.

Sam komunikat doradczy nie podaje ani nazwiska zgłaszającego, ani daty zgłoszenia luki, podobnie jak rekord NVD, więc odstęp między zgłoszeniem Marota a poprawką nie wynika z niczego w tym rekordzie.

Fala wokół niego

CVE-2026-85889 nie był odosobnioną poprawką. Przewodnik po aktualizacjach zabezpieczeń firmy Microsoft wymienia 18 luk w zabezpieczeniach opublikowanych 17 września 2026 r., a bardziej informujący jest kształt tej grupy. Wszystkie 18 mają stopień krytyczny. Każda dotyczy usługi w chmurze. Wszystkie są odnotowane jako niewykorzystane i jako niewymagające żadnych działań ze strony klienta. Siedem z 18 ma ocenę 10,0 — Azure Billing, Microsoft Fabric, Azure AI Foundry, dwie w Azure Logic Apps, Azure Arc i Microsoft Container Registry.

Kontrast wewnątrz tej fali ma znaczenie przy odczytywaniu nagłówka. CVE-2026-85885, wstrzyknięcie poleceń w Microsoft 365 Copilot przy 9,9, ma ocenę PR:L — wymagane uprawnienia — a opis Microsoftu mówi „uwierzytelniony atakujący”. CVE-2026-85889 ma PR:N i mówi „nieuwierzytelniony atakujący”. Dwie luki w tym samym wydaniu, dwie oceny Krytyczne, a tylko jedna z nich wymagała, by atakujący posiadał poświadczenie przed rozpoczęciem. Trzecie znalezisko AI w grupie, CVE-2026-85917, to fałszowanie żądań po stronie serwera w Azure AI Foundry przy 7,5, ocenione przy niezmienionym zakresie i wpływie ograniczonym do poufności.

Co się zmieniło i co klient nadal może zatrzymać

Tym, co się zmieniło, jest luka: Microsoft raportuje, że została w pełni zmitygowana, a żaden klient nie ma nic do wdrożenia. Tym, co się nie zmieniło, jest rejestr, który klient może zachować. Zalecenia CSA obejmują zakres od natychmiastowych działań po strukturalne — potwierdź, że remediacja z września 2026 r. dotarła do tenanta; zachowaj i przejrzyj logi aktywności oraz ścieżki audytu AI Foundry z tygodni ją poprzedzających; segmentuj projekty AI Foundry według tenanta i obciążenia; stosuj zasadę najmniejszych uprawnień wobec użytkowników, jednostek usługi i tożsamości zarządzanych; ogranicz dane i poświadczenia, do których może uzyskać dostęp dowolny pojedynczy projekt; oraz scentralizuj alerty AI Foundry i Microsoft Defender for Cloud.

Jego rekomendacja strukturalna jest tą, która uogólnia się poza ten CVE: traktować płaszczyzny zarządzania AI w chmurze jako odrębną kategorię ryzyka stron trzecich, uwzględniać historię ujawniania luk przez dostawców w ocenach dostawców oraz wymagać umownych terminów powiadamiania i przejrzystości po incydencie w przypadku wad płaszczyzny kontrolnej. Żadne z tego nie było potrzebne, aby przetrwać CVE-2026-85889. To właśnie sprawiłoby, że następny byłby widoczny.

Jak archiwum klasyfikuje ten element?

Wpis jest sklasyfikowany jako podatność — taka, którą wykryto, a nie taka, o której wiadomo, że została wykorzystana. Jego pewność oznaczono jako A, co oznacza dobrze udokumentowaną, ze zgodnymi źródłami pierwotnymi, a wpis nie jest oznaczony jako sporny. Pole real-harm ma wartość false, a jego powiązanie z AI jest potwierdzone: dotknięty produkt to aplikacja i platforma agentowa oparta na generatywnej AI, a nie usługa chmurowa ogólnego przeznaczenia, która przypadkiem znajduje się w pobliżu takiej. Jego data jest zapisana z dokładnością do dnia, 17 września 2026 r., bez daty końcowej, ponieważ jest to pojedynczy punkt w czasie, a nie kampania.

Jedyne, czego same pola archiwum nie są w stanie oddać, to to, jak wielką częścią tej historii jest nieobecność. W platformie, której klienci korporacyjni używają do budowania i uruchamiania agentów, występuje luka w uwierzytelnianiu o maksymalnym stopniu ważności. Jest poprawka. Jest nazwisko badacza. Czego natomiast nie ma — nigdzie w biuletynie, wpisie NVD, nocie CSA ani w prasie branżowej — to stwierdzenia, że ktokolwiek próbował wykorzystać tę lukę, informacji, jak długo była osiągalna, ani sposobu, by klient mógł sprawdzić to samodzielnie.