7 maja 2026 Microsoft Security Response Center opublikowało doradztwo dotyczące CVE-2026-42826 — krytycznej podatności typu „information disclosure” w Azure DevOps, której twórcy chmury sami przypisali maksymalną możliwą ocenę CVSS 3.1 wynoszącą 10.0. To rzadkość, bo „dziesiątka” trafia się w roku zaledwie kilka razy i zazwyczaj dotyczy podatności typu RCE (zdalne wykonanie kodu). Tym razem mamy do czynienia z czystym wyciekiem informacji, ale parametry ataku są na tyle bolesne, że MSRC wrzuciło sprawę do najwyższej kategorii. Po stronie pozytywów — Microsoft zaznaczył, że klient nie musi nic robić, bo poprawka została wdrożona automatycznie po stronie chmury. Po stronie negatywów — to problem, który mógł być wykorzystany, zanim ktokolwiek się o nim dowiedział.
Anatomia podatności
CVE-2026-42826 to klasyczne CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor. Atakujący nie musi posiadać żadnych uprawnień ani konta w systemie ofiary, nie potrzebuje też interakcji użytkownika. Wystarczy, że ma dostęp sieciowy do instancji Azure DevOps, a może odczytać dane, do których normalnie wgląd ma wyłącznie zalogowany pracownik organizacji. Wektor ataku to sieć, złożoność niska, brak wymaganych przywilejów, brak interakcji użytkownika, wpływ na poufność oceniony jako wysoki.
Microsoft nie ujawnił publicznie szczegółów technicznych, co jest zgodne z polityką MSRC w przypadku usług hostowanych — zbyt dokładny opis zachęca napastników do prób na nieautoryzowanych instancjach. Oficjalne doradztwo wskazuje jednak, że problem dotyczył mechanizmu kontroli dostępu lub konfiguracji bezpiecznej, w którym dane organizacji mogły zostać udostępnione żądaniom z zewnątrz. W praktyce oznacza to, że treści typu kod źródłowy projektów, definicje pipeline’ów CI/CD, sekrety przechowywane w zmiennych, historie commitów oraz pliki tickets/work items teoretycznie mogły zostać odczytane przez nieuprawnioną stronę.
Dlaczego ocena CVSS to dziesięć
W systemie CVSS 3.1 maksymalną notę dostają podatności, które naruszają wszystkie trzy filary CIA (poufność, integralność, dostępność) na poziomie wysokim, atakowane są zdalnie i nie wymagają od atakującego żadnych warunków wstępnych. CVE-2026-42826 spełnia większość tych warunków bardzo agresywnie — zerowy próg wejścia, sieciowy wektor, niska złożoność. Wpływ na poufność jest oczywisty (dane wyciekają), wpływ na integralność i dostępność wynika tu prawdopodobnie z możliwości użycia uzyskanych informacji w dalszej fazie ataku, na przykład do podszywania się pod uprawnione tokeny lub przejmowania pipeline’ów.
W przypadku usługi SaaS o skali Azure DevOps rzeczywista powierzchnia ataku to dziesiątki tysięcy organizacji. Microsoft ma dane telemetryczne, więc mógł stwierdzić, czy podatność była aktywnie wykorzystywana — w opublikowanym doradztwie tej informacji jednak nie ma, co przy podatnościach „zero-click” jest dla wielu zespołów niepokojące.
Co oznacza „brak akcji wymaganej od klienta”
Microsoft zaznaczył, że poprawka została zaaplikowana po stronie infrastruktury chmurowej i administratorzy nie muszą instalować łatek ani aktualizować klientów. To zaleta usług SaaS — czas reakcji jest krótszy niż w on-premie, gdzie poprawka byłaby teraz dystrybuowana przez Patch Tuesday i wdrażana ręcznie przez tygodnie. Z drugiej strony nie zwalnia to administratorów z obowiązku audytu — jeżeli mieliście w swoim Azure DevOps wrażliwy kod, sekrety, klucze API albo dane klientów, warto przyjąć założenie, że w okresie podatności (do daty patcha włącznie) mogły zostać odczytane.
Co konkretnie zrobić
Najpierw rotacja sekretów — wszystkie tokeny dostępu, klucze API, hasła do baz danych, certyfikaty oraz Personal Access Tokens, które były przechowywane w zmiennych środowiskowych Azure DevOps, w skarbcach Variable Groups albo w kodzie pipeline’ów, należy traktować jak potencjalnie ujawnione i wymienić. To jest jednorazowy koszt operacyjny, ale ratuje tyłek, jeżeli okaże się za miesiąc, że ktoś jednak miał odczyt tych danych.
Po drugie, przejrzyjcie logi audytowe Azure DevOps z ostatnich tygodni i zwróćcie uwagę na nietypowe odczyty repozytoriów albo zapytania do API spoza znanych adresów IP organizacji. W panelu Auditing dostępne są filtry po kategoriach „Pipelines”, „Git” i „Project Collection” — to dobry punkt startowy.
Po trzecie, przejrzyjcie konfigurację bezpieczeństwa swoich projektów — czy włączone jest IP allowlisting, czy wymuszacie autoryzację OAuth/SAML zamiast PAT-ów, czy macie ustawione branch protection dla głównych gałęzi i wymagane review przed merge. Jeżeli wyciek faktycznie miał miejsce, zminimalizuje to konsekwencje również w przyszłości.
Po czwarte, dla zespołów obsługujących klientów — RODO. Jeżeli w Azure DevOps przechowujecie dane osobowe (nawet w issue trackerze albo dokumentacji projektowej), incydent w usłudze podmiotu przetwarzającego uruchamia obowiązek analizy ryzyka po waszej stronie. Microsoft nie potwierdził wprost, że dane wyciekły z waszej organizacji, ale brak potwierdzenia nie jest dowodem braku incydentu. Warto skonsultować się z inspektorem ochrony danych.
Podsumowanie
Krytyczne podatności w SaaS-ach narzędziowych nie zdarzają się codziennie, ale gdy się pojawiają, ich zasięg jest natychmiast globalny. CVE-2026-42826 to przypadek modelowy — wystarczy adres serwisu i sieć, żeby uzyskać dane, do których powinno się mieć ograniczony dostęp. Microsoft wykonał swoją część zadania, łatając błąd po cichu i bez wymagania działań od klientów, ale to nie zmienia faktu, że okno podatności było otwarte i każdy klient powinien teraz przyjąć założenie kompromitacji jako podstawowe — rotacja sekretów, audyt logów, wzmocnienie konfiguracji. To trzy ruchy, które kosztują tygodniówkę pracy administratora i potrafią uchronić organizację przed znacznie bardziej kosztownym incydentem za kilka miesięcy.
źródło: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-42826