Podatność pod aktywnym atakiem

To nie jest teoretyczne ostrzeżenie; luka jest wykorzystywana właśnie teraz. 17 lipca 2026 amerykańska agencja cyberbezpieczeństwa CISA dodała CVE-2026-58644, krytyczną podatność Microsoft SharePoint Server, do swojego katalogu znanych wykorzystywanych podatności i nakazała cywilnym agencjom federalnym załatać ją do 19 lipca. Błąd to deserializacja niezaufanych danych o wadze 9,8 na 10, która pozwala atakującemu bez poświadczeń uruchomić dowolny kod na serwerze.

Nie jest odosobniony. Grupa luk SharePoint Server jest łączona w łańcuch na wolności, by omijać uwierzytelnianie, uzyskiwać zdalne wykonanie kodu i prowadzić dalszą aktywność. Samodzielnie hostowany SharePoint ma tu długą historię: od końca 2021 regulatorzy oznaczyli blisko tuzin jego podatności jako wykorzystywane w atakach, a większość z nich później użyto w ransomware.

Dlaczego samo łatanie cię nie uratuje

Niebezpieczne jest to, co atakujący zabierają, wchodząc. Podczas ataku kradną kryptograficzne klucze maszynowe serwera, sekrety, których SharePoint używa do podpisywania i weryfikowania tokenów przyznających dostęp. Gdy atakujący ma te klucze, może dowolnie fałszować ważne poświadczenia i może to robić wobec serwera, który już zaktualizowałeś.

To jest pułapka tego incydentu. Zastosowanie łatki Microsoftu zamyka dziurę, przez którą wszedł intruz, ale nic nie robi z kluczami, które już skopiował. Do załatanego, w pełni zaktualizowanego SharePoint Server nadal można wejść ze skradzionymi kluczami, i dlatego naprawa nie kończy się tu na łatce. Jeśli nie zrotujesz kluczy maszynowych, możesz uważać się za bezpiecznego, podczas gdy drzwi po cichu pozostają otwarte.

Kto jest naprawdę narażony

To problem on-premises, nie chmurowy. Podatność dotyczy samodzielnie hostowanego SharePoint Server, wersji, którą organizacja uruchamia na własnej infrastrukturze. SharePoint Online w Microsoft 365, usługa hostowana, nie jest celem tych konkretnych ataków. Ryzyko koncentruje się więc właśnie w instalacjach, które wiele europejskich firm średniej wielkości, organów publicznych, kancelarii prawnych i domów finansowych trzyma u siebie.

Często trzymają je u siebie z dobrych powodów: rezydencja danych, przepisy branżowe albo decyzja, by trzymać wrażliwe dokumenty na kontrolowanej przez siebie infrastrukturze. Ten wybór jest uzasadniony, ale oznacza też, że łatanie, rotacja kluczy i monitorowanie są w całości twoją odpowiedzialnością. Wygoda, którą dostawca chmury załatwiłby po cichu, jest on-premises zadaniem z twoim nazwiskiem i tykającym zegarem.

Co to oznacza w świetle przepisów UE

Amerykański termin cię nie wiąże, ale pilność tak. 19 lipca dotyczy amerykańskich agencji federalnych; europejski operator nie ma wobec niego obowiązku prawnego. Traktuj go raczej jako publiczny sygnał, jak szybko to się porusza, bo te same serwery i ten sam kod exploita nie zatrzymują się na granicy. Krajowe organy, jak niemiecki BSI i brytyjski NCSC, wydają własne ostrzeżenia dokładnie o tego rodzaju aktywnie wykorzystywanej luce.

W ramach NIS2, a dla podmiotów finansowych DORA, udane włamanie jest tu incydentem podlegającym zgłoszeniu z wąskimi terminami i odpowiedzialnością na poziomie zarządu. Repozytorium dokumentów pełne umów, danych osobowych i wewnętrznych zapisów to właśnie ten zasób, do ochrony którego te przepisy istnieją. Powolność w łataniu znanej, wykorzystywanej podatności to rodzaj zaniedbania, które regulator czyta jako niedbalstwo, nie pech.

Co robić teraz

Działaj po kolei i zakładaj najgorsze tam, gdzie nie możesz udowodnić inaczej. Natychmiast zastosuj aktualizacje SharePoint Server od Microsoftu, następnie zrotuj klucze maszynowe IIS, aby skradzione klucze stały się bezużyteczne. Poluj na oznaki naruszenia: nieoczekiwane web shelle, nieznane pliki w katalogach serwera, nowe lub zmienione klucze i zdarzenia uwierzytelniania, które nie pasują do twoich użytkowników. Zmniejsz powierzchnię ataku, wyprowadzając każdy wystawiony do internetu SharePoint z otwartej sieci tam, gdzie możesz.

Jeśli twój serwer był osiągalny i niezałatany w jakimkolwiek momencie od ujawnienia, potraktuj go jako naruszony i badaj na tej podstawie, zamiast liczyć, że został pominięty. Koszt założenia naruszenia, którego nie było, to kilka godzin przeglądu; koszt założenia bezpieczeństwa, którego nie było, to sam incydent.

Czytaj dalej: Jedenaście podpisanych bootloaderów omija Secure Boot  |  570 poprawek Windows w jeden dzień, dwie już wykorzystywane