SharePoint CVE-2026-58644: aktywne ataki i RCE

CVE-2026-58644 w lokalnych instalacjach Microsoft SharePoint Server jest aktywnie wykorzystywana. Podatność typu deserializacja niezaufanych danych pozwala nieuwierzytelnionemu napastnikowi wykonać kod przez sieć. Microsoft ocenił ją na 9,8 w CVSS 3.1, a CISA dodała ją 16 lipca 2026 roku do katalogu Known Exploited Vulnerabilities.

To przypadek, w którym aktualizacja i analiza kompromitacji muszą działać równolegle. Rekord NVD CVE-2026-58644 wskazuje exploitation: active, automatable: yes i technicalImpact: total. Termin wymagany przez CISA dla podmiotów objętych dyrektywą przypada na 19 lipca. Firmy spoza administracji federalnej również powinny potraktować ten termin jako mocny sygnał operacyjny, zwłaszcza gdy SharePoint jest dostępny z Internetu.

Najważniejsze fakty o CVE-2026-58644

Pole	Potwierdzona informacja
Produkt	Microsoft SharePoint Server on-premises
Klasa błędu	CWE-502 — deserializacja niezaufanych danych
Wektor	sieciowy, bez wymaganych uprawnień i interakcji użytkownika
Skutek	zdalne wykonanie kodu
CVSS 3.1	9,8 Critical według Microsoftu
Eksploatacja	aktywna według CISA-ADP
KEV	dodana 16 lipca 2026, termin 19 lipca 2026
Źródła	NVD, CISA KEV i MSRC

Nie należy mylić tej podatności z wcześniejszym ToolShell ani z innymi lipcowymi błędami SharePoint. Ten sam produkt może mieć wiele niezależnych ścieżek RCE. Wpis Microsoft July 2026: SharePoint i AD FS omawia szerszy kontekst bieżącego pakietu, natomiast tutaj skupiamy się wyłącznie na CVE-2026-58644, jej macierzy wersji i reagowaniu na potwierdzoną eksploatację.

Podatne produkty i progi wersji

Według danych przekazanych przez Microsoft do rekordu CVE problem dotyczy:

SharePoint Enterprise Server 2016 przed wersją 16.0.5556.1005;
SharePoint Server 2019 przed wersją 16.0.10417.20153;
SharePoint Server Subscription Edition przed wersją 16.0.19725.20384.

NVD pokazuje też własne wzbogacenie CPE, które dla Subscription Edition może prezentować inny próg kompilacji niż blok danych CNA. W takiej sytuacji źródłem wdrożeniowym powinien być aktualny biuletyn MSRC i dokumentacja konkretnego pakietu, nie ręcznie przepisana liczba z agregatora. Administrator musi potwierdzić, że zainstalowany pakiet jest przeznaczony dla właściwej edycji i że aktualizacja zakończyła się na każdym serwerze farmy.

SharePoint Online nie jest automatycznie objęty zakresem CVE dla produktu on-premises. Organizacja może jednak używać hybrydy: serwer lokalny, Web Application Proxy, reverse proxy, wyszukiwanie, integracje i synchronizację tożsamości. Inwentaryzacja musi rozróżnić usługę SaaS od własnych farm 2016, 2019 i Subscription Edition.

Dlaczego deserializacja prowadzi do wykonania kodu

Serializacja przekształca obiekt w format możliwy do zapisania lub przesłania. Deserializacja odtwarza obiekt po drugiej stronie. Jeśli aplikacja przyjmuje dane od niezaufanego klienta i pozwala środowisku uruchomić zachowanie związane z typem obiektu, napastnik może wpłynąć nie tylko na wartości, lecz także na przebieg wykonania.

CWE-502 obejmuje sytuacje, w których niezaufane dane są deserializowane bez wystarczającej walidacji, ograniczenia typów lub ochrony integralności. W środowisku .NET łańcuch może wykorzystywać dostępne klasy i metody do osiągnięcia niezamierzonej operacji. Nie trzeba przesyłać własnego pliku wykonywalnego jako pierwszego kroku; wystarczy skłonić serwer do zbudowania niebezpiecznego grafu obiektów.

Obrońca nie potrzebuje publicznego payloadu, aby ustalić ryzyko. Oficjalny wektor CVSS mówi: sieć, niska złożoność, brak uprawnień, brak interakcji i wysoki wpływ na poufność, integralność oraz dostępność. To uzasadnia najwyższy priorytet dla osiągalnych serwerów.

Dlaczego patch nie zamyka okresu ekspozycji

Poprawka usuwa bieżącą możliwość wykorzystania, ale nie usuwa kont, webshelli, zadań i poświadczeń pozostawionych wcześniej. Ponieważ CISA potwierdza aktywną eksploatację, każdą wystawioną podatną farmę należy traktować jak system wymagający triage, nie jak zwykły zaległy update.

Zespół powinien odpowiedzieć na cztery pytania:

Czy serwer był podatny w okresie, gdy ataki były aktywne?
Z jakich sieci i przez jakie proxy można było do niego dotrzeć?
Jakie logi oraz dane hosta zachowały się z tego okresu?
Czy istnieją oznaki wykonania kodu, utrzymania dostępu lub kradzieży sekretów?

Brak alarmu EDR nie jest dowodem braku włamania. Proces roboczy aplikacji może wykonywać legalne narzędzia systemowe, a napastnik może używać pamięci, istniejących kont i funkcji SharePoint. Potrzebna jest korelacja logów IIS, ULS, Windows, EDR, proxy, WAF oraz zmian w farmie.

Plan na pierwsze cztery godziny

Godzina 0–1: inwentaryzacja i ograniczenie ruchu

Znajdź wszystkie serwery farmy, węzły testowe, DR i stare publikacje. Odczytaj wersję z rzeczywistych binariów. Zapisz ścieżki Internet → CDN/WAF → reverse proxy → IIS → SharePoint. Jeżeli poprawka nie może być wdrożona natychmiast, ogranicz dostęp do zaufanych źródeł lub zdejmij publikację. Nie uruchamiaj publicznego PoC przeciw produkcji.

Godzina 1–2: zachowanie dowodów

Eksportuj logi IIS z pełnym URI, metodą, kodem odpowiedzi, adresem klienta i czasem. Zabezpiecz ULS, dzienniki PowerShell, Windows Security, Sysmon lub EDR, historię zmian plików, listę usług, zadań harmonogramu, kont lokalnych i członków grup uprzywilejowanych. Pobierz konfigurację farmy i spis rozwiązań bez modyfikowania podejrzanych artefaktów.

Godzina 2–3: poprawka i walidacja techniczna

Wdrażaj pakiet zgodnie z MSRC i procedurą SharePoint, uwzględniając wymagane kroki konfiguracji. Sprawdź każdy węzeł osobno. Sama obecność pakietu w systemie zarządzania aktualizacjami nie dowodzi, że binaria oraz schemat farmy osiągnęły oczekiwany stan.

Godzina 3–4: rozpoczęcie threat huntingu

Szukaj nietypowych żądań, procesów potomnych IIS, nowych plików w katalogach aplikacji, zmian web.config, nieznanych assembly, zadań, usług i kont. Zbadaj ruch wychodzący, dostęp do bazy, operacje na sekretach oraz logowania administratorów. Ustal okres analizy co najmniej od ostatniego potwierdzonego bezpiecznego stanu, nie tylko od daty publikacji CVE.

Dane, które warto skorelować

Źródło	Pytania analityczne
IIS i reverse proxy	nietypowe POST, wysokie kody 500, nowe agenty, źródła i ścieżki
ULS	wyjątki deserializacji, anomalie żądań, błędy ładowania typów i assembly
Windows/EDR	procesy potomne `w3wp.exe`, PowerShell, cmd, narzędzia transferu i archiwizacji
system plików	nowe lub zmienione ASPX, DLL, konfiguracje i artefakty w katalogach web
tożsamość	nowe konta, zmiany grup, logowania usług i administratorów
sieć	nowe połączenia wychodzące, DNS, tunele i ruch do rzadkich ASN
SQL	nietypowe zapytania, eksport danych, nowe loginy i zmiany uprawnień

Te hipotezy wynikają z potencjalnego skutku RCE, a nie są oficjalną listą IOC dla jednego narzędzia atakującego. Aktorzy mogą zmieniać post-exploitation. Stabilniejsze jest wykrywanie zachowania niż pojedynczej nazwy pliku. Wdrożenie można połączyć z detection engineering i ćwiczeniem tabletop reagowania na incydenty.

Poprawna kolejność izolacji i rotacji

Jeśli pojawia się dowód wykonania kodu, nie ograniczaj działań do usunięcia pliku. Odłącz podejrzany węzeł od ruchu, zachowaj obraz dysku i dane pamięci, a usługi przenieś na czysty, poprawiony system. Ustal, do jakich sekretów miała dostęp tożsamość puli aplikacyjnej i konta farmy.

Rotacja może objąć konta farmy, konta usług, poświadczenia baz danych, certyfikaty i sekrety integracji. Kolejność musi uwzględniać zależności, aby nie zniszczyć telemetrii i nie spowodować niekontrolowanej niedostępności. Jeżeli napastnik miał uprawnienia do zmiany konfiguracji, odbudowa z zaufanego źródła jest pewniejsza niż ręczne „czyszczenie” hosta.

Segmentuj serwery SharePoint od kontrolerów domeny, systemów zarządzania i stacji administratorów. Weryfikację takich ścieżek omawia pentest segmentacji sieci wewnętrznej. RCE na serwerze aplikacyjnym nie powinno automatycznie otwierać drogi do całej domeny.

Walidacja poprawki na całej farmie

Po wdrożeniu sprawdź:

wersję binariów na każdym serwerze 2016, 2019 lub Subscription Edition;
status usług, timer jobs, wyszukiwania i kolejek;
zakończenie wymaganych kroków konfiguracyjnych farmy;
działanie uwierzytelniania, uploadu, pobierania, wyszukiwania i integracji;
brak starego węzła w load balancerze, DR i puli automatyzacji;
kompletność logów po restarcie;
bezpieczny test negatywny podatnej klasy zachowania.

Zapisz identyfikator poprawki, wersję przed i po, czas odcięcia ekspozycji, osoby zatwierdzające oraz wynik threat huntingu. To tworzy dowód dla audytu i pozwala rozróżnić „pakiet wysłany” od „ryzyko zamknięte”. Praktykę tę rozwija proces zarządzania podatnościami.

Relacja z wcześniejszymi atakami na SharePoint

Zespoły mogą błędnie uznać, że wcześniejsze działania związane z ToolShell CVE-2025-53770 automatycznie chronią przed nową luką. WAF, IOC i skrypt sprawdzający poprzednią ścieżkę nie zastępują aktualizacji CVE-2026-58644. Mogą pomóc dzięki lepszej telemetrii, lecz mechanizm deserializacji i artefakty po wykorzystaniu mogą być inne.

Właśnie dlatego playbook powinien być oparty na klasach zachowania: nieoczekiwane wykonanie kodu przez worker IIS, zmiany plików, nowe tożsamości, dostęp do sekretów i ruch wychodzący. Sygnatura jednego payloadu szybko się starzeje.

Jak raportować stan bez fałszywego „brak IOC”

Raport dla kierownictwa powinien osobno pokazywać podatność, ekspozycję, kompletność telemetrii, znalezione anomalie i postęp naprawy. Zdanie „nie wykryto IOC” jest mylące, jeżeli ULS ma retencję dwóch dni, EDR został wdrożony po rozpoczęciu okresu ekspozycji albo reverse proxy nie loguje pełnego URI.

Lepszy zapis brzmi: „trzy z czterech węzłów były publicznie osiągalne; zachowano 30 dni IIS i 14 dni EDR; poprawkę potwierdzono na całej farmie; analiza kont i ruchu wychodzącego zakończona; brak danych ULS sprzed 10 lipca ogranicza pewność”. Dzięki temu odbiorca rozumie zarówno dowody, jak i luki w dowodach.

Nie zamykaj incydentu samym statusem pakietu. Kryteria zamknięcia powinny obejmować analizę okresu ekspozycji, decyzję o rotacji, potwierdzenie braku nieznanych artefaktów, odtworzone monitorowanie oraz akceptację resztkowej niepewności przez właściciela ryzyka.

Kryteria przywrócenia pełnego ruchu

Pełny ruch przywróć dopiero po spełnieniu jawnych kryteriów: wszystkie węzły mają poprawioną wersję, konfiguracja farmy zakończyła się prawidłowo, najważniejsze funkcje biznesowe przeszły testy, a telemetria z IIS, ULS i EDR ponownie dociera do systemu analitycznego. Osobno potwierdź, że load balancer, środowisko DR i automatyzacja nie wskazują na stary obraz.

Jeżeli threat hunting jeszcze trwa, właściciel ryzyka powinien znać zakres przeanalizowanych danych i brakujące okresy retencji. Przywrócenie dostępności nie oznacza automatycznie zamknięcia incydentu. Można wznowić usługę na czystej farmie, pozostawiając dochodzenie otwarte, pod warunkiem zachowania dowodów, kontroli rotacji i wzmożonego monitorowania nowych węzłów.

Decyzja dla kierownictwa

Publiczny, podatny SharePoint jest dziś incydentem wysokiego priorytetu. Właściciel techniczny odpowiada za poprawkę i dowody wersji. SOC odpowiada za analizę okresu ekspozycji. IAM i właściciele integracji przygotowują kontrolowaną rotację. Właściciel biznesowy akceptuje okno niedostępności lub ryzyko dalszej publikacji — z pełną informacją, że eksploatacja jest potwierdzona.

Potrzebujesz szybko zweryfikować farmę SharePoint po aktywnie wykorzystywanej luce? Skontaktuj się z BreachRoad — wykonamy bezpieczny przegląd ekspozycji, wersji, ścieżek ataku, logów i segmentacji oraz przygotujemy dowody zamknięcia ryzyka.