Luka w autoryzacji 9,9 w Azure SRE Agent mogła pozwolić wywołującemu przejąć jego tożsamość

CVE-2026-62830 to luka polegająca na braku autoryzacji w Azure SRE Agent — opartym na AI agencie Microsoftu dla zespołów Azure odpowiedzialnych za niezawodność usług, który dokonuje triażu incydentów, odpytywania telemetrii i, jeśli został tak skonfigurowany, wykonuje działania naprawcze. Microsoft ujawnił ją w sierpniu 2026 r. i ocenił na 9,9 punktu w skali 10 — Krytyczny — w CVSS 3.1. Każda dzierżawa Azure uruchamiająca tego agenta znajdowała się w zakresie oddziaływania luki; archiwum incydentów nie odnotowuje potwierdzonej ofiary ani żadnego wykorzystania. Opis luki autorstwa Microsoftu to jedno zdanie: „Brak autoryzacji w Azure SRE Agent pozwala uprawnionemu atakującemu na podniesienie uprawnień w sieci”. Usługa została naprawiona po stronie serwera, a Microsoft twierdzi, że klienci nie mieli nic do załatania. Pełny wpis, wraz z przyznanymi ocenami ważności i pewności, znajduje się w Orca AI Incident Archive, obok sąsiednich incydentów z tej serii.

Co Microsoft opublikował, a co pominął

Wpis w Przewodniku po aktualizacjach zabezpieczeń firmy Microsoft dotyczący CVE-2026-62830 odnotowuje podniesienie uprawnień w Azure SRE Agent, słabość CWE-862 (Brak autoryzacji), wynik bazowy 9,9 i wynik czasowy 8,6. Wektor — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C — opisuje atak sieciowy wymagający jedynie niskich uprawnień i braku interakcji użytkownika, powodujący wysoki wpływ na poufność, integralność i dostępność. Firma Microsoft przypisuje odkrycie badaczowi bezpieczeństwa wtm z Offensi w sekcji podziękowań biuletynu.

Dwie części tego wektora niosą istotną informację. Metryka zakresu (scope) przyjmuje wartość Changed (S:C), którą dokumentacja metryk samego Microsoftu definiuje jako przypadek, w którym komponent podatny i komponent dotknięty są różne oraz zarządzane przez różne organy odpowiedzialne za bezpieczeństwo. Metryki czasowe to Unproven exploit code, Official fix i Confirmed, dlatego wynik czasowy jest niższy od bazowego.

FAQ biuletynu wyjaśnia, dlaczego istnieje ocena 9,9 bez linku do pobrania: „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”. Microsoft oznacza produkt jako usługę wyłącznie hostowaną, dlatego wpis nie zawiera numeru kompilacji ani zakresu wersji, których dotyczy problem.

Tabela podatności na wykorzystanie jest równie klarowna jak FAQ. Publicznie ujawniono: Nie. Wykorzystano: Nie. Ocena wykorzystania: Mniej prawdopodobne. Poradnik nie opisuje przepływu w imieniu (on-behalf-of), tożsamości zarządzanej ani runbooków. Nie podaje też zakresu wersji: CPE to produkt bez wersji, a jedyną wymienioną wersją objętą problemem jest myślnik. Wszystko, czego czytelnik chciałby się dowiedzieć o mechanizmie, musi pochodzić skądinąd, a tym skąd jest głównie wpis samego archiwum.

Czym jest agent i dlaczego to jego tożsamość jest celem, do którego warto dążyć

Azure SRE Agent nie jest chatbotem doczepionym do dashboardu. Dokumentacja Microsoftu dotycząca Azure SRE Agent opisuje agenta, który łączy się z zasobami Azure, narzędziami obserwowalności, platformami incydentów i repozytoriami kodu źródłowego, gromadzi sygnały, koreluje wdrożenia, proponuje środki łagodzące i — w zależności od trybu uruchomienia ustawionego przez klienta — wykonuje je. W trybie Review administrator zatwierdza działania zapisujące; w trybie Autonomous agent stosuje je bez oczekiwania. Jego zasięg rozszerzają skille i runbooki, operacje Azure CLI, niestandardowe agenty, narzędzia Python, łączniki MCP i hooki agenta.

Ta sama dokumentacja podaje fakt, który czyni CVE interesującym: „Agent uwierzytelnia się za pomocą tożsamości zarządzanej i działa w ramach kontroli dostępu opartej na rolach w Azure (RBAC)”. Tożsamość zarządzana to tożsamość Entra przypisana do usługi, a to, co może robić, jest dokładnie tym, co pozwalają jej przypisania ról. Autorytet agenta nie jest zatem właściwością kodu agenta, lecz ról powiązanych z tą tożsamością — czyli granicy, której brak kontroli autoryzacji nie zdołałby ochronić.

Osobny artykuł techniczny, wpis HackTricks Cloud dotyczący podniesienia uprawnień w Azure SRE Agent, opisuje strukturalną wersję tego problemu bez powoływania się na CVE-2026-62830. Wymienia operacje w płaszczyźnie sterowania, które pozwalają wywołującemu sterować agentem — otwarcie wątku, zatwierdzenie proponowanej naprawy, ponowne powiązanie konfiguracji agenta, przekierowanie łącznika danych — i przedstawia wynik jako confused deputy: wywołujący nie potrzebuje uprawnień agenta, tylko sposobu, by zmusić agenta do ich użycia. Ten wpis nie dotyczy tego CVE i nie należy go odczytywać jako jego potwierdzenia. Jest przydatny z tego samego powodu co ocena: pokazuje, gdzie faktycznie spoczywają uprawnienia.

Mechanizm: co opisuje archiwum i co potwierdza dostawca

Wpis w archiwum opisuje tę lukę jako błąd w tym, co nazywa przepływem Scope-Changed OBO (on-behalf-of). Przepływ on-behalf-of to wymiana tokenów, w której jedna usługa wymienia poświadczenie wywołującego na token pozwalający jej wywołać usługę podrzędną jako ten wywołujący. Jeśli kontrola uprawnień podczas tej wymiany zakończy się niepowodzeniem, wywołanie podrzędne może awaryjnie przejść do zarządzanej tożsamości samego agenta ograniczonej do dzierżawy zamiast tożsamości wywołującego — podaje archiwum. Wywołujący z niskimi uprawnieniami, ale uwierzytelniony, odziedziczyłby wtedy uprawnienia podmiotu usługi agenta i mógłby modyfikować runbooki, telemetrię i infrastrukturę — nie tylko agenta, ale każdy zasób Azure, na którym tożsamość zarządzana ma przypisaną rolę.

Ten opis jest spójny ze wszystkim, co Microsoft opublikował, i nie znajduje się w tym, co Microsoft opublikował. Tekst dostawcy potwierdza trzy elementy: brakowało kontroli autoryzacji, wywołujący potrzebuje jedynie niskich uprawnień, a skutek przekracza granicę uprawnień bezpieczeństwa. Nie potwierdza on wymiany tokenów, dziedziczenia tożsamości ani przykładów runbooków i telemetrii. Wpis w archiwum jest źródłem tych elementów, a archiwum jest wtórnym zbiorem danych, a nie dostawcą.

Poszukiwanie niezależnych relacji natrafia na ten sam akapit w więcej niż jednym miejscu: nagłówek dotyczący przepływu OBO i promienia rażenia pojawia się w syndykacji na forkast.news oraz Yahoo Tech, między innymi. Syndykacja sprawia, że ta relacja to jedno źródło, a nie kilka. Żaden z serwisów przejrzanych na potrzeby tego artykułu nie opublikował własnej telemetrii, dowodu koncepcji ani reprodukcji mechanizmu.

Co jest ustalone, co jest opisane, a czego nigdy nie twierdzono

Archiwum przyznaje temu rekordowi ocenę A — dobrze udokumentowany, źródła pierwotne są zgodne — i nie oznacza go jako spornego. Nie odnotowuje żadnej szkody w świecie rzeczywistym. Ocena ta dotyczy kluczowych faktów rekordu, a te są zgodne w źródłach; nie jest to twierdzenie, że każde zdanie we wpisie zostało niezależnie odtworzone.

• Ustalone przez dostawcę. CVE-2026-62830 dotyczy Azure SRE Agent, jest sklasyfikowane jako CWE-862 brak autoryzacji, ma bazowy wynik CVSS 3.1 wynoszący 9,9 i wynik czasowy 8,6, nie wymagało żadnych działań klienta, nie zostało publicznie ujawnione i nie odnotowano jego wykorzystania.

• Potwierdzone przez niezależne doniesienia i wzbogacanie danych dotyczących bezpieczeństwa. Zestawienie Cisco Talos dotyczące Patch Tuesday ze sierpnia 2026 r. wymienia CVE z tą samą oceną 9.9 i tą samą słabością związaną z brakiem autoryzacji, a także umieszcza je w kategorii „mniej prawdopodobne” w ocenie wykorzystania przez Microsoft. Ocena SSVC CISA, zarejestrowana przez NVD, określa eksploatację jako brak, automatyzowalność jako nie, a wpływ techniczny jako całkowity. Wzbogacenie OpenCVE podaje wynik EPSS 0,00778 i odnotowuje, że CVE nie znajduje się w katalogu Known Exploited Vulnerabilities CISA.

• Opisane, ale niepotwierdzone niezależnie. Awaria wymiany tokenów OBO, dziedziczenie tożsamości zarządzanej agenta oraz konsekwencje dla runbooka, telemetrii i infrastruktury pochodzą z wpisu w archiwum oraz z syndykowanych materiałów wtórnych. Komunikat doradczy Microsoftu nie wymienia ich. Są najbardziej użyteczną częścią tego zapisu i zarazem najmniej udokumentowaną jego częścią.

• Nigdzie nie ustalono. Brak wykorzystania, brak ofiary, brak publicznego proof of concept, brak numeru kompilacji i brak zakresu podatnych wersji. Wiersz dotyczący możliwości wykorzystania od Microsoftu — publicznie ujawniono: Nie, wykorzystano: Nie, mniej prawdopodobne — jest najbliższą istniejącą rzeczą do raportu statusu.

• Brak relacji w mediach głównego nurtu. Wyszukiwanie tej CVE w ogólnych mediach technologicznych i branżowych mediach bezpieczeństwa nie zwróciło żadnego artykułu z The Register, BleepingComputer, SecurityWeek ani Help Net Security. Jej publiczny ślad obejmuje komunikat dostawcy, bazy danych podatności, podsumowanie Patch Tuesday i syndykowany artykuł. Jak na 9,9 to nietypowe, i jest to fakt dotyczący zapisu, a nie ocena ryzyka.

Poprawka i testy, które ją przetrwają

Ponieważ Azure SRE Agent jest usługą hostowaną, poprawka została zastosowana po stronie Microsoftu. Nie ma aktualizacji do zainstalowania, numeru kompilacji do porównania z inwentarzem ani sposobu, w jaki klient mógłby potwierdzić z zewnątrz, że dzierżawa była chroniona przed określoną datą. Stanowisko Microsoftu jest takie, że nie są wymagane żadne działania, i w odniesieniu do samej luki to stanowisko jest słuszne.

Wpis w archiwum dodaje wskazówki, których komunikat nie precyzuje: przeprowadzaj audyt przypisań tożsamości zarządzanych, weryfikuj RBAC pod kątem tego, czego agent faktycznie potrzebuje, oraz monitoruj nietypowe eskalacje uprawnień. Te wskazówki pochodzą z archiwum, a nie są cytatem z firmy Microsoft.

Praktyczna konsekwencja wynika raczej z architektury niż z jakiegokolwiek zalecenia źródła, więc należy traktować ją jako wnioskowanie. Jeśli uprawnienia agenta wynikają z jego przypisań ról, to trwałymi mechanizmami kontrolnymi są zakres tych przypisań oraz retencja logów płaszczyzny sterowania, które ujawniłyby ich użycie. Poprawka po stronie usługi zamyka ścieżkę; nie zawęża wstecz tożsamości zarządzanej, której przydzielono nadmierne uprawnienia, i nie pomoże organizacji, która nie przechowywała logów. Jedno i drugie to kwestie, którymi klient nadal zarządza po zamknięciu CVE.

Gdzie plasuje się w partii z sierpnia 2026 r.

Zestawienie Talosa sprawia, że porównanie jest nieuniknione. W tym miesiącu wymienia ono także CVE-2026-59118 w Copilot Cowork — podniesienie uprawnień przez niewłaściwą autoryzację ocenione na 9,3 — oraz CVE-2026-56162 w Azure SQL Database, podniesienie uprawnień ocenione na 10,0. Jedyną luką, którą Talos w tym miesiącu zgłasza jako wykorzystywaną w rzeczywistych warunkach, nie była żadna z tych dwóch: była to CVE-2026-68820 w Windows AFD for WinSock. Pozycje dotyczące produktów AI na liście Talosa to błędy autoryzacji i właśnie taki kształt ma ryzyko udokumentowane w tym rekordzie.

Nic z tego nie sprawia, że CVE-2026-62830 jest naruszeniem. To CVE dotyczące przejrzystości dla usługi, która została już poprawiona, opublikowane, aby klienci mogli zobaczyć, co było nie tak, i sprawdzić własne konfiguracje. Wartością tego wpisu jest pytanie konfiguracyjne, które pozostawia — do czego tożsamość agenta mogła mieć dostęp i czy ktokolwiek zauważyłby, że jest używana — a nie łatka do zaplanowania.