Łańcuch wyjaśniony

CVE-2026-55040 to obejście walidacji tokenów JWT, które pozwala zdalnemu, nieuwierzytelnionemu atakującemu podszyć się pod użytkownika lub administratora SharePoint. CVE-2026-63520 to osobny błąd w Business Connectivity Services SharePoint, niebezpieczna instancjacja typów .NET, która pozwala atakującemu zbudować własny łańcuch obiektów, by wykonać dowolne polecenia systemu operacyjnego z uprawnieniami konta usługi SharePoint. Żaden z tych dwóch błędów nie jest sam w sobie katastrofalny, ale badacz Rapid7 Stephen Fewer ujawnił oba firmie Microsoft jako jeden łańcuch już w maju, a razem dają nieuwierzytelnione zdalne wykonanie kodu przeciwko SharePoint Server Subscription Edition, SharePoint Server 2019 i SharePoint Enterprise Server 2016.

Microsoft naprawił obie połowy według różnych harmonogramów: CVE-2026-55040 pojawiła się wraz z Patch Tuesday z lipca 2026 roku, a CVE-2026-63520 nastąpiła miesiąc później, 11 sierpnia 2026 roku, wraz z aktualizacjami bazy wiedzy KB5002893, KB5002894, KB5002896, KB5002905 i KB5002906 dla różnych dotkniętych wersji produktu. Według Rapid7 nie ma jeszcze potwierdzonego wykorzystania pełnego łańcucha RCE w praktyce, ponieważ ujawnienie było skoordynowane. Dla pierwszej połowy sytuacja wygląda inaczej.

Dlaczego podział poprawki na dwa miesiące ma znaczenie

Rapid7 opublikowała szczegółową analizę techniczną wraz z proof-of-concept dla CVE-2026-55040, a firma wywiadu o zagrożeniach Defused twierdzi, że jej honeypoty SharePoint już zarejestrowały prawdziwych atakujących wykorzystujących ten publiczny proof-of-concept do obejścia uwierzytelniania, zaledwie kilka dni po jego publikacji. Sam Microsoft nie potwierdził jeszcze wykorzystania w praktyce, ale to, że niezależna sieć wykrywania przechwytuje realne próby, jest silnym sygnałem, że oportunistyczne skanowanie już się zaczęło.

Niewygodną częścią jest kalendarz. Ponieważ obie połowy łańcucha załatano w odstępie miesiąca, organizacja, która sumiennie zastosowała lipcową poprawkę, przez wiele tygodni wierzyła, że problem obejścia uwierzytelniania został zamknięty, podczas gdy druga, dopełniająca RCE połowa pozostawała niezałatana aż do 11 sierpnia. Każdy, kto nie zastosował jeszcze razem obu sierpniowych aktualizacji KB oraz lipcowej poprawki, prowadzi obecnie udokumentowaną, publicznie zademonstrowaną ścieżkę do nieuwierzytelnionego wykonania kodu na własnym serwerze SharePoint -- nie teoretyczną.

Co sprawdzić we własnym środowisku SharePoint

To jednoznacznie problem on-premises: SharePoint Online nie jest dotknięty, ale instalacje SharePoint Server 2016, 2019 i Subscription Edition są powszechne w europejskich i brytyjskich instytucjach publicznych, na uczelniach i w średnich firmach, które nigdy w pełni nie przeniosły się do chmury. Praktyczna lista kontrolna to potwierdzenie, że obie aktualizacje KB z lipca i sierpnia są zainstalowane razem, a nie tylko jedna z nich, ponieważ częściowa poprawka pozostawia łańcuch nienaruszony.

Warto też zastosować stałe zalecenie CISA niezależnie od stanu poprawek: nie wystawiać serwera SharePoint on-premises bezpośrednio do internetu, a tam, gdzie musi być dostępny, umieścić go za odwrotnym proxy warstwy 7 lub równoważnym mechanizmem kontroli na poziomie aplikacji, który potrafi filtrować rodzaj spreparowanych żądań, na których opiera się ten łańcuch. Skoro dla połowy łańcucha istnieje już działający, publiczny proof-of-concept, potraktujcie to w tym tygodniu jako aktywny incydent do obsługi, a nie rutynowy punkt w cyklu poprawek.

Czytaj dalej: Poprawka SharePoint, którą pominąłeś w maju, jest teraz pilna  |  Ransomware Gunra wykorzystuje luki Fortinet z 2025 roku