Administratorzy Microsoft SharePoint mają przed sobą konkretne zadanie: ustalić, czy jakiekolwiek lokalne systemy SharePoint Server nadal są narażone na CVE-2026-65660, a następnie zdecydować, czy należy traktować je wyłącznie jako niezałatane, czy również jako potencjalnie przejęte. To rozróżnienie ma znaczenie, ponieważ luka nie jest już tylko pozycją na liście comiesięcznych aktualizacji. Kanadyjskie władze informują o aktywnym wykorzystywaniu problemu, a doniesienia dotyczące bezpieczeństwa umieszczają go w bieżącym kontekście katalogu Known Exploited Vulnerabilities.

Firmowa serwerownia z ekranami monitoringu bezpieczeństwa pokazującymi stan poprawek i alerty reagowania na incydenty

Podatny produkt to SharePoint Server, a nie SharePoint Online w ramach Microsoft 365. Ten zakres pozwala uniknąć dwóch częstych błędów. Dzierżawa Microsoft 365 nie powinna zakładać, że każda usługa z nazwą SharePoint jest podatna na ten sam problem po stronie serwera. Z kolei organizacja prowadząca publicznie dostępny albo osiągalny wewnętrznie farmę SharePoint nie powinna uznawać, że migracja innych usług do chmury usuwa problem z jej środowiska. Pierwszym zadaniem jest poprawna inwentaryzacja zasobów. Drugim — ustalenie, czy instalacja poprawki wymaga także oceny możliwego naruszenia.

Co zostało potwierdzone

Kanadyjskie Centrum Cyberbezpieczeństwa opisuje CVE-2026-65660 jako niewłaściwą kontrolę generowania kodu, sklasyfikowaną pod oznaczeniem CWE-94. Centrum podaje, że luka dotyczy wielu wersji Microsoft SharePoint Server i może pozwolić uwierzytelnionemu napastnikowi na wykonanie dowolnego kodu na podatnym serwerze. W alercie z 24 września wskazano, że centrum wiedziało o aktywnym wykorzystywaniu luki i powiązało ją z opublikowanym 11 sierpnia 2026 r. biuletynem bezpieczeństwa Microsoftu.

To sformułowanie jest dla obrońców sieci bardziej użyteczne niż sama ocena krytyczności. Według kanadyjskiego alertu luka wymaga uwierzytelnionego napastnika, ale „uwierzytelniony” nie oznacza „zaufany administrator”. W środowisku przedsiębiorstwa napastnik może zdobyć lub nadużyć zwykłego konta, tożsamości usługi, nieaktualnych danych uwierzytelniających albo konta mającego dostęp do systemu współpracy, lecz nigdy nieprzeznaczonego do wykonywania kodu po stronie serwera. Ryzyko zależy więc od mechanizmów kontroli tożsamości, ekspozycji, granic uprawnień i stanu farmy — nie tylko od tego, czy ruch anonimowy jest dozwolony.

Materiały Microsoftu dotyczące aktualizacji bezpieczeństwa z września 2026 r. wymieniają SharePoint wśród produktów otrzymujących poprawki i odsyłają administratorów do dokumentacji aktualizacji SharePoint. Informacje o wydaniach SharePoint identyfikują aktualizację z 8 września dla SharePoint Server Subscription Edition jako KB5002908, w wersji 16.0.20326.20136. Microsoft podaje również, że aktualizacje SharePoint są kumulatywne: najnowsza odpowiednia aktualizacja zawiera wcześniej wydane poprawki dla danej linii produktu.

Wniosek operacyjny jest prosty: trzeba ustalić edycję i kompilację serwera, zainstalować aktualną obsługiwaną aktualizację kumulatywną albo zalecane przez producenta działanie naprawcze dla tej edycji, a następnie zweryfikować wynikową kompilację. Ogólny komunikat „Windows jest zaktualizowany” nie jest dowodem, że SharePoint został naprawiony. SharePoint ma własną ścieżkę serwisową, a farmy mogą obejmować więcej niż jedną rolę serwera lub więcej niż jedną wersję, przez co pojedyncze sprawdzenie w konsoli bywa mylące.

Dlaczego to problem reagowania na incydent, a nie tylko zgłoszenie aktualizacyjne

Zwykłe zgłoszenie aktualizacyjne pyta, czy poprawka została zainstalowana. Aktywnie wykorzystywana luka dodaje drugie pytanie: czy podatna usługa była używana przed pojawieniem się aktualizacji? Pomyślna instalacja zamyka znaną wadę oprogramowania, ale nie usuwa web shella, zaplanowanego zadania, skradzionych danych uwierzytelniających, zmienionej konfiguracji ani mechanizmu utrzymania dostępu, który napastnik mógł utworzyć wcześniej.

To rozróżnienie jest szczególnie istotne w przypadku SharePoint, ponieważ produkt znajduje się blisko cennych danych biznesowych i systemów tożsamości. Serwer może przechowywać dokumenty projektowe, indeksy wyszukiwania, dane przepływów pracy, integracje aplikacyjne oraz połączenia z bazami danych i magazynami plików. W wielu organizacjach ma także szeroki zasięg sieciowy, ponieważ oprogramowanie do współpracy wdrożono jako centralną usługę wewnętrzną. Napastnik, który uzyska wykonanie kodu na serwerze, nie musi od razu kraść każdego dokumentu. Serwer może posłużyć jako przyczółek do rozpoznania, pozyskania danych uwierzytelniających, ruchu bocznego albo powolnego dostępu do danych.

Wcześniejsze informacje Microsoftu o aktywnym wykorzystywaniu lokalnych luk SharePoint dostarczają istotnego kontekstu, ale nie dowodzą, że w przypadku CVE-2026-65660 działają ci sami napastnicy lub te same techniki. W tamtym przypadku z 2025 r. Microsoft opisał przejście od wykorzystania SharePoint wystawionego do internetu do wdrożenia web shella, rozpoznania, dostępu do danych uwierzytelniających, ruchu bocznego i aktywności ransomware. Historia ta jest powodem, by po remediacji zbadać środowisko, a nie podstawą do twierdzenia, że kampania z 2026 r. przebiega według identycznego łańcucha.

Obrońcy powinni oddzielać potwierdzone fakty od uzasadnionych hipotez. Potwierdzone jest to, że Kanadyjskie Centrum Cyberbezpieczeństwa informuje o aktywnym wykorzystywaniu CVE-2026-65660, problem dotyczy wielu wersji SharePoint Server, deklarowany wpływ obejmuje wykonanie dowolnego kodu przez uwierzytelnionego napastnika, a Microsoft opublikował aktualizacje bezpieczeństwa dla SharePoint. Źródła te nie potwierdzają natomiast tożsamości napastników, uniwersalnego ładunku po wykorzystaniu luki, liczby przejętych organizacji ani twierdzenia, że każdy wystawiony serwer został naruszony.

Które środowiska wymagają natychmiastowej uwagi

Zacznij od wszystkich samodzielnie utrzymywanych instancji SharePoint Server, także tych, których zespół aplikacyjny nie uznaje za „produkcyjne”. Farmy deweloperskie, testowe, odtwarzania awaryjnego, raportowe i udostępnione partnerom często zachowują prawdziwe dane uwierzytelniające, skopiowane dane albo trasy sieciowe, które czynią je atrakcyjnymi punktami pośrednimi. Inwentaryzacja obejmująca wyłącznie główną farmę nie wystarczy.

Uwzględnij serwery znajdujące się za odwrotnymi proxy, modułami równoważenia ruchu, bramami VPN i brokerami dostępu prywatnego. Instancja nie staje się nieistotna tylko dlatego, że nie jest indeksowana przez publiczną wyszukiwarkę. Napastnik może wejść przez przejęte konto firmowe, inny naruszony system wewnętrzny, połączenie partnerskie albo ścieżkę zarządzania. Z drugiej strony sama obecność nasłuchującego interfejsu internetowego nie dowodzi podatności na tę konkretną lukę. Trzeba zweryfikować produkt, wersję, konfigurację i wskazówki producenta.

Podczas triage rozdziel SharePoint Server od SharePoint Online. W wytycznych Microsoftu z 2025 r. dotyczących wcześniejszych lokalnych luk SharePoint wyraźnie odróżniono SharePoint Server od SharePoint Online. Ta granica produktowa pozostaje ważnym sprawdzeniem administracyjnym, choć dokładną stosowalność CVE-2026-65660 należy ustalać na podstawie bieżącego alertu z 2026 r. i wskazówek serwisowych Microsoftu. Organizacja korzystająca wyłącznie z dzierżawy może nadal badać aktywność tożsamości lub aplikacji, ale nie powinna stosować planu naprawczego dla lokalnego serwera wobec usługi, której sama nie obsługuje.

Najbardziej użyteczne pola inwentaryzacji są proste: nazwa farmy, nazwy serwerów, edycja produktu, numer kompilacji, ekspozycja internetowa i wewnętrzna, ścieżka uwierzytelniania, właściciel, stan kopii zapasowych, ostatnia pomyślna aktualizacja oraz systemy, z którymi farma może się łączyć. Dodaj konta tożsamości używane przez usługi SharePoint i integracje. Taka lista zamienia ogólny komunikat bezpieczeństwa w ograniczony zestaw decyzji.

Praktyczne działania pierwszego dnia

1. Ustal zakres

Poproś właścicieli infrastruktury i aplikacji o autorytatywną listę farm SharePoint Server. Porównaj ją z systemami zarządzania punktami końcowymi, skanowaniem podatności, DNS, certyfikatami, konfiguracją odwrotnych proxy, rejestrami wirtualizacji oraz inwentaryzacją chmurową i kolokacyjną. Wyszukaj stare nazwy farm i hosty wyglądające na wycofane, które nadal odpowiadają w sieci. Jeśli zasobu nie można sklasyfikować, oznacz go jako nierozstrzygnięty, zamiast automatycznie uznawać za bezpieczny.

Zapisz kompilację na każdym istotnym serwerze. Dokumentacja aktualizacji SharePoint Microsoftu mówi, że poprawki są kumulatywne, lecz dokładny pakiet i obsługiwana ścieżka serwisowa zależą od edycji produktu. Dla każdej farmy udokumentuj dowody: zainstalowaną aktualizację, wynikową kompilację, czas instalacji, stan ponownego uruchomienia lub restartu usług oraz kontrolę poprawności po aktualizacji. Te informacje będą potrzebne także wtedy, gdy później trzeba będzie odizolować serwer albo odtworzyć go z kopii.

2. Zastosuj remediację producenta

Do wyboru właściwej aktualizacji użyj aktualnych wskazówek bezpieczeństwa Microsoftu i strony aktualizacji SharePoint. Dla SharePoint Server Subscription Edition Microsoft wymienia KB5002908 jako aktualizację z 8 września 2026 r., z kompilacją 16.0.20326.20136. To przydatny punkt odniesienia, ale przed wdrożeniem administrator powinien potwierdzić edycję produktu, późniejsze aktualizacje zastępujące ten pakiet oraz bieżące zalecenia Microsoftu.

Przetestuj aktualizację zgodnie ze zwykłą procedurą organizacji dla farm, jeśli można to zrobić bez przedłużania niebezpiecznej ekspozycji. Nie pozwól, by standardowe okno zmian stało się powodem pozostawienia podatnego serwera dostępnego z internetu przez kolejne dni. Jeśli systemu nie da się od razu zaktualizować, ogranicz ekspozycję przy użyciu środków zalecanych przez producenta i kontroli sieciowych, zawęź dostęp do zaufanych ścieżek administracyjnych oraz wyznacz konkretnego właściciela i termin. Kontrole kompensacyjne zmniejszają możliwość ataku, ale nie sprawiają, że wykorzystana luka znika.

3. Zachowaj dowody przed niepotrzebnymi zmianami

Jeśli istnieje jakakolwiek przesłanka, że doszło do wykorzystania luki, przed usuwaniem plików, przebudową serwerów, rotacją logów lub odtwarzaniem z kopii skoordynuj działania z zespołem reagowania na incydenty albo bezpieczeństwa. Zachowaj odpowiednią telemetrię systemu operacyjnego, IIS, SharePoint, uwierzytelniania, proxy, punktów końcowych i sieci, zgodnie z zasadami retencji oraz wymaganiami prawnymi organizacji. Zarejestruj bieżący stan serwera i dowody dotyczące aktualizacji.

Nie oznacza to opóźniania pilnego ograniczenia skutków. Chodzi o wybór działań containmentu, które zachowają możliwość ustalenia, co się wydarzyło. Jeśli farma wykazuje aktywność budzącą podejrzenia, odizoluj ją zgodnie z planem reagowania, dokumentując kolejne decyzje. Chaotyczne sprzątanie, które niszczy jedyne dowody pierwotnego dostępu, może uniemożliwić organizacji ustalenie, czy napastnik dotarł do innych systemów.

4. Szukaj oznak nieuprawnionego użycia

Przejrzyj zdarzenia uwierzytelniania pod kątem nietypowych kont, lokalizacji źródłowych, niemożliwej podróży, nowej aktywności kont usługowych, nieoczekiwanego podniesienia uprawnień administracyjnych oraz dostępu o porach niezgodnych ze zwykłym rytmem działania farmy. Skoreluj te zdarzenia z aktywnością SharePoint i IIS, detekcjami punktów końcowych, logami odwrotnego proxy oraz połączeniami sieciowymi. Pojedynczy nietypowy agent użytkownika lub żądanie nie wystarcza do ogłoszenia naruszenia; znacznie mocniejszy jest wzorzec widoczny jednocześnie w telemetrii tożsamości, sieci WWW, procesów i sieci.

Sprawdź nieoczekiwane pliki, zmiany w treści aplikacji internetowych, nieznane zestawy, nowe zadania zaplanowane, usługi, wpisy startowe, zmienioną konfigurację oraz procesy, które nie pasują do roli serwera. Zbadaj połączenia wychodzące z farmy, zwłaszcza do miejsc nieujętych w udokumentowanych integracjach. Przejrzyj uprzywilejowane konta i dane uwierzytelniające usług, które znajdowały się na serwerze w okresie ekspozycji.

Unikaj publikowania szczegółów wykorzystania luki i kopiowania niezweryfikowanych wskaźników do produkcyjnych reguł detekcji. Korzystaj ze wskaźników Microsoftu, CISA, krajowych agencji cyberbezpieczeństwa, zaufanego dostawcy zabezpieczeń albo sprawdzonego partnera reagowania na incydenty, a następnie weryfikuj je w lokalnym środowisku. Zbyt szeroka reguła może zakłócić usługę współpracy, a zbyt wąska stworzyć fałszywe poczucie bezpieczeństwa.

5. Rotuj dane uwierzytelniające na podstawie ekspozycji, nie przyzwyczajenia

Jeśli dochodzenie wskazuje, że serwer mógł zostać naruszony, przyjmij, że dane uwierzytelniające dostępne dla procesu lub hosta wymagają przeglądu. W pierwszej kolejności zajmij się tożsamościami usług SharePoint, kontami baz danych, integracjami aplikacyjnymi, kontami administratorów, certyfikatami, sekretami zapisanymi w konfiguracji oraz danymi uwierzytelniającymi, do których można było dotrzeć z tego samego serwera albo przez jego ścieżkę sieciową. Rotację skoordynuj tak, aby farma pozostała obsługiwana i aby nowe sekrety nie zostały natychmiast ujawnione na nadal przejętym hoście.

Sama rotacja danych uwierzytelniających nie jest dowodem containmentu. Jeśli web shell albo inny mechanizm utrzymania dostępu nadal istnieje, napastnik może przechwycić nowe dane. Remediacja powinna łączyć czysty, obsługiwany stan oprogramowania z dochodzeniem dotyczącym serwera i punktów końcowych, zweryfikowanymi kopiami zapasowymi oraz decyzją, czy lepsza będzie przebudowa, czy odtworzenie systemu w miejscu.

Jak sprawdzić, czy remediacja zadziałała

Dobry zapis weryfikacyjny odpowiada na cztery osobne pytania. Po pierwsze, czy każdy właściwy serwer ma obsługiwaną i naprawioną kompilację? Po drugie, czy do podatnej usługi nadal można dotrzeć z jakiejkolwiek nieuprawnionej ścieżki sieciowej? Po trzecie, czy istnieją dowody wykorzystania luki przed aktualizacją? Po czwarte, czy w tym okresie ujawniono jakąś tożsamość, sekret albo system zależny?

Odpowiedź na pierwsze pytanie wynika z dowodów dotyczących kompilacji i aktualizacji. Drugą uzyskuje się przez sprawdzenie sieci i kontroli dostępu, a nie przez skan wykonany wyłącznie wobec publicznego interfejsu. Trzecia wymaga logów i badania hosta. Czwarta wymaga korelacji danych tożsamości, baz danych, udziałów plikowych, API i punktów końcowych. Traktowanie pierwszej odpowiedzi tak, jakby potwierdzała wszystkie cztery, jest najczęstszym błędem w pilnej reakcji na podatność.

Po aktualizacji przeprowadź kontrolowane sprawdzenie kondycji farmy: uwierzytelniania, wyszukiwania, aplikacji usługowych, przepływów pracy, integracji, zadań zaplanowanych, łączności z bazą danych i dostępu do dokumentów. Porównaj działanie ze znaną dobrą bazą. Obserwuj nowe błędy, nietypową aktywność procesów, ruch wychodzący i powtarzające się nieudane uwierzytelnienia. Utrzymuj wzmożony monitoring przez okres odpowiedni do zakresu logowania organizacji i czasu, przez jaki system mógł być wystawiony.

Jeśli dochodzenie nie znajdzie dowodów naruszenia, udokumentuj, dlaczego taki wniosek jest wiarygodny i jaka telemetria była dostępna. „Nie znaleziono dowodów” różni się od „znaleziono dowody braku naruszenia”. Jeśli logów brakowało albo okres retencji był zbyt krótki, zapisz to ograniczenie i potraktuj jego usunięcie jako priorytet przed kolejną podatnością o dużym wpływie.

Co incydent mówi o architekturze SharePoint

Bezpośrednią poprawką jest aktualizacja Microsoftu. Długoterminowa lekcja ma charakter architektoniczny: serwer współpracy nie powinien gromadzić zbędnego zaufania tylko dlatego, że odgrywa centralną rolę w pracy z dokumentami. Zmapuj tożsamości, bazy danych, systemy pamięci masowej, interfejsy API, sieci zarządzania oraz miejsca przechowywania kopii zapasowych, do których SharePoint może dotrzeć. Usuń nieużywane trasy i uprawnienia. Oddziel dostęp administracyjny od zwykłego dostępu użytkowników. Chroń konta usługowe, nadając im możliwie wąskie uprawnienia, i stosuj silne uwierzytelnianie administratorów.

Sprawdź, jak szybko organizacja potrafi odpowiedzieć na podstawowe pytania: Gdzie znajdują się wszystkie farmy? Jaka kompilacja jest zainstalowana? Kto odpowiada za każdą farmę? Które konta mogą nią administrować? Jak długo przechowywane są odpowiednie logi? Czy można odizolować farmę bez wyłączenia wszystkich przepływów współpracy? Jeśli odpowiedzi wymagają tygodnia spotkań, ryzyko techniczne jest tylko częścią problemu. Sam proces reagowania również jest zależnością.

Opisana przez Microsoft kampania wykorzystująca SharePoint w 2025 r. pokazuje także, dlaczego aktualizowanie serwerów WWW, ochrona punktów końcowych, monitoring tożsamości i segmentacja sieci muszą działać razem. Nie należy oczekiwać, że pojedyncza kontrola wykryje każdy etap. Poprawka zamyka pierwotną wadę kodu. Logi aplikacji i proxy pomagają odtworzyć żądania. Telemetria punktów końcowych ujawnia podejrzane procesy i mechanizmy utrzymania dostępu. Logi tożsamości pokazują skradzione lub niewłaściwie użyte konta. Kontrole sieciowe ograniczają zasięg skutków. Kopie zapasowe dają możliwość odtworzenia, ale tylko wtedy, gdy są chronione przed tymi samymi danymi uwierzytelniającymi i ścieżkami co produkcja.

Pytania, które kierownictwo powinno zadać dziś

Liderzy bezpieczeństwa i infrastruktury nie potrzebują dramatycznego raportu; potrzebują precyzyjnych odpowiedzi. Czy organizacja korzysta z SharePoint Server, SharePoint Online, czy z obu produktów? Ile istnieje lokalnych farm, w tym systemów nieprodukcyjnych i odtwarzania awaryjnego? Które farmy były wystawione w okresie objętym bieżącym alertem? Jaka aktualizacja i jaka kompilacja chronią każdą farmę? Czy krajowa agencja cyberbezpieczeństwa informowała o wykorzystaniu luki? Jakie dowody przejrzano pod kątem naruszenia? Które dane uwierzytelniające i systemy zależne byłyby zagrożone, gdyby farma została przejęta?

Odpowiedzi powinny być powiązane z dowodami i właścicielami. „Skaner pokazuje zielony status” nie wystarczy, jeśli pominął farmę odłączoną od sieci. „Poprawka zainstalowała się pomyślnie” nie wystarczy, jeśli przed instalacją na serwerze występowała podejrzana aktywność. „Korzystamy z Microsoft 365” nie wystarczy, jeśli stary SharePoint Server nadal działa w centrum danych na potrzeby starszego przepływu pracy.

CVE-2026-65660 wymaga pilnego działania, ponieważ publicznie dostępne informacje przeszły od teoretycznej ekspozycji do świadomości aktywnego wykorzystywania. Właściwa reakcja powinna być metodyczna: ustal rzeczywisty wykaz serwerów, zastosuj odpowiednią remediację Microsoftu, zbadaj okres ekspozycji, zabezpiecz lub obróć dane uwierzytelniające, gdy jest to uzasadnione, i zachowaj wystarczająco dużo dowodów, by odróżnić naprawioną lukę od czystego środowiska. Taka kolejność ogranicza zarówno ryzyko techniczne, jak i możliwość, że pospieszny raport o poprawce ukryje większy incydent.

Źródła i podstawa opracowania

Artykuł opiera się na dokumentacji serwisowej Microsoftu dotyczącej SharePoint i materiałach o aktualizacjach bezpieczeństwa z września 2026 r., alercie Kanadyjskiego Centrum Cyberbezpieczeństwa dotyczącym CVE-2026-65660, programie CISA Known Exploited Vulnerabilities oraz wcześniejszym pierwszoplanowym raporcie Microsoftu o aktywnym wykorzystywaniu lokalnych luk SharePoint. Raport Microsoftu z 2025 r. służy jako kontekst planowania reakcji; nie jest przedstawiany jako dowód, że aktywność z 2026 r. ma tego samego sprawcę, ładunek lub łańcuch ataku.