Luka o maksymalnej ocenie 10.0 w skali CVSS (Common Vulnerability Scoring System — skala 0-10 oceniająca powagę luki) została zidentyfikowana w Microsoft Entra ID. Problem, oznaczony jako CVE-2026-42901 [^1], pozwala nieautoryzowanemu atakującemu na zdalną eskalację uprawnień w sieci [^2]. Dotyczy to każdej organizacji korzystającej z usług Microsoft 365 lub Azure, co w Polsce obejmuje dziesiątki tysięcy firm i instytucji publicznych.

Microsoft poinformował o załataniu luki po stronie serwera [^3]. Nie wymaga to instalacji aktualizacji przez administratorów, ale wymusza pilny audyt konfiguracji i logów w celu wykrycia potencjalnej kompromitacji.

TL;DR

  • Produkt: Microsoft Entra ID (dawniej Azure Active Directory).
  • Wektor: Błąd walidacji w roli Agent ID Administrator [^4] [^5], pozwalający na przejęcie dowolnej jednostki usługi (Service Principal) w organizacji.
  • Identyfikator: CVE-2026-42901 [^1], CVSS 10.0 (Krytyczna).
  • Wskaźniki naruszenia: Audyt logów pod kątem nieoczekiwanych zmian właściciela jednostek usługi oraz tworzenia nowych poświadczeń dla nich [^6].
  • Kogo dotyczy: Wszystkie organizacje korzystające z Microsoft Entra ID, w tym polskie firmy z sektora MŚP i enterprise, a także administracja publiczna.
  • Pierwszy ruch: Pilny audyt przypisań roli Agent ID Administrator [^7] i przegląd logów Entra ID w poszukiwaniu podejrzanej aktywności.

Wektor ataku

Źródłem problemu jest błąd w logice uprawnień roli administracyjnej. Luka, sklasyfikowana jako CWE-346 (Origin Validation Error — błąd walidacji pochodzenia) [^8], dotyczy roli o nazwie Agent ID Administrator w usłudze Microsoft Entra ID [^4]. Rola ta została zaprojektowana do zarządzania tożsamościami agentów AI [^9].

Źródła wskazują, że z powodu niewłaściwego zakresu dostępu, użytkownik z tą rolą mógł przejąć na własność dowolną jednostkę usługi (Service Principal) w całej dzierżawie (tenancie) [^5]. Jednostki usługi to tożsamości używane przez aplikacje do uzyskiwania dostępu do zasobów. Atakujący, wykorzystując tę lukę, mógł najpierw uzyskać niskouprzywilejowany dostęp, a następnie przypisać sobie rolę Agent ID Administrator.

Scenariusz ataku wygląda następująco:

  1. Atakujący uzyskuje uprawnienia do przypisania sobie roli Agent ID Administrator.
  2. Używa tych uprawnień, aby przejąć na własność wysoko uprzywilejowaną jednostkę usługi [^10], na przykład taką z dostępem do kluczowych zasobów chmurowych.
  3. Po przejęciu własności generuje dla niej nowe poświadczenia, takie jak klucz klienta (client secret) lub certyfikat [^11].
  4. Uwierzytelnia się jako ta jednostka usługi, dziedzicząc wszystkie jej uprawnienia w całej organizacji [^12].

Skuteczna eksploatacja nie wymaga interakcji ze strony użytkownika ani wcześniejszego uwierzytelnienia w docelowym systemie [^13]. Konsekwencje mogą obejmować pełne przejęcie potoków CI/CD, dostęp do danych przez Microsoft Graph API, kompromitację infrastruktury chmurowej, a w skrajnych przypadkach eskalację uprawnień do poziomu Administratora Globalnego [^14]. Może to prowadzić do całkowitego naruszenia poufności, integralności i dostępności danych [^15].

Wskaźniki kompromitacji

W tym przypadku wskaźniki kompromitacji (IoC — Indicators of Compromise) nie są typowymi hashami plików czy adresami IP. Kluczowe jest przeszukanie logów audytowych Entra ID w poszukiwaniu anomalii behawioralnych. Należy zwrócić uwagę na następujące zdarzenia:

  • Podejrzane przypisania roli: Każde przypisanie roli Agent ID Administrator do użytkownika, zwłaszcza jeśli nastąpiło w nietypowych godzinach lub dotyczy konta, które nie powinno zarządzać agentami AI [^7].
  • Zmiany właścicieli jednostek usługi: Wszelkie zdarzenia zmiany właściciela (ownership change) dla krytycznych jednostek usługi (Service Principals) [^6].
  • Tworzenie nowych poświadczeń: Zdarzenia wygenerowania nowych kluczy lub certyfikatów dla istniejących jednostek usługi, szczególnie jeśli nie było to częścią zaplanowanej rotacji kluczy [^6].

Zalecamy użycie zapytań w Microsoft Sentinel lub bezpośrednio w logach Entra ID do wyszukania tych wzorców aktywności. ## Co zrobić w 24-48h

Microsoft poinformował, że luka została w pełni załatana we wszystkich środowiskach chmurowych dnia 9 kwietnia 2026 roku [^16]. Działania po stronie administratorów powinny skupić się na weryfikacji i wzmocnieniu konfiguracji.

Krok 1: Audyt i weryfikacja (natychmiast)

  1. Przegląd ról: Przeprowadź pełny audyt kont z przypisaną rolą Agent ID Administrator. Należy usunąć to uprawnienie ze wszystkich kont, dla których nie jest ono absolutnie niezbędne [^7].
  2. Analiza logów: Przeszukaj logi audytowe Entra ID (w portalu Azure lub przez narzędzia SIEM) w poszukiwaniu wskaźników kompromitacji opisanych w poprzedniej sekcji [^6]. Skup się na ostatnich tygodniach.
  3. Identyfikacja ryzyka: Zidentyfikuj kluczowe jednostki usługi w swojej organizacji — te z najwyższymi uprawnieniami, np. do systemów finansowo-księgowych, baz danych klientów czy infrastruktury produkcyjnej. Potraktuj je priorytetowo w dalszych krokach.

Krok 2: Remediacja i wzmocnienie (w ciągu 48h)

  1. Rotacja poświadczeń: Dla wszystkich wrażliwych jednostek usługi, które mogły być celem ataku, należy przeprowadzić rotację poświadczeń (kluczy i certyfikatów) [^17].
  2. Zasada najmniejszych uprawnień: Zweryfikuj politykę nadawania uprawnień w organizacji. Ogranicz przypisywanie wysoko uprzywilejowanych ról tylko do niezbędnego personelu i na jak najkrótszy czas [^18].
  3. Wdrożenie PIM: Rekomendowanym podejściem jest wdrożenie usługi Privileged Identity Management (PIM) [^19]. PIM pozwala na aktywację ról uprzywilejowanych „na żądanie” (just-in-time), z wymogiem dodatkowego zatwierdzenia i na określony czas. Dla polskich firm, które muszą spełniać wymogi dyrektywy NIS2, jest to kluczowy mechanizm kontrolny.

Stosowanie się do powyższych zaleceń może pomóc w ograniczeniu ryzyka. Nie zastępuje to jednak pełnego audytu bezpieczeństwa ani konsultacji ze specjalistami w przypadku wykrycia incydentu.

Zobacz też