“Krytycznej luki w SharePoincie nie ma w katalogu podatności wykorzystywanych w atakach” – napisaliśmy tak cztery dni temu. Sprawdziliśmy wtedy plik liczący 1665 pozycji. Ten sam plik ma dziś 1670 pozycji, a ta luka jest w nim od 18 sierpnia. Termin naprawy wyznaczono na 21 sierpnia. Zdanie trzeba więc odwołać, ale tylko w połowie, bo warunek postawiliśmy wtedy podwójny. Drugi człon się nie ziścił. Microsoft nadal ma w swoim wpisie wartość “nie” przy pytaniu o wykorzystanie luki w atakach. Dokumentu nie ruszał od 14 lipca. Rozjazd między dwiema instytucjami, który opisywaliśmy tydzień temu, nie tylko się nie domknął, ale pogłębił.
Cztery luki w katalogu CISA i wspólny termin 21 sierpnia
Agencja dopisała czwórkę jednego dnia i wszystkim wyznaczyła tę samą datę. W ogłoszeniu uzasadnia to jednym zwrotem: dowodami aktywnego wykorzystania.
- Microsoft SharePoint – słabe uwierzytelnianie, ta sama luka, o której pisaliśmy 15 sierpnia
- Apple macOS – błędne uwierzytelnianie w Udostępnianiu ekranu
- Broadcom VMware vCenter – przejście po ścieżkach katalogów prowadzące do wykonania kodu
- Microsoft IKE Service Extensions – podwójne zwolnienie pamięci, również z możliwością zdalnego wykonania kodu
Z tego zestawienia od razu wynikają dwie rzeczy. Po pierwsze, poprawki istnieją i to od dawna. Apple wydał swoją 6 sierpnia, w macOS Tahoe 26.6.1, Sequoia 15.7.9 i Sonoma 14.8.9. Poprawka na SharePointa jest z 14 lipca. Wpis do katalogu nie mówi więc “nie ma czym łatać”, tylko “przestań to odkładać”.
Po drugie, żaden z czterech wpisów nie wskazuje sprawcy. Pole opisujące powiązanie z kampanią wymuszającą okup ma we wszystkich czterech wartość “nieznane”. Zdanie o trwającym ataku na polskie firmy nie miałoby więc żadnej podstawy w dokumencie.
Czym różnią się dziś oceny CISA i Microsoftu
Sprawdziliśmy wpis producenta ponownie, tym samym sposobem co cztery dni temu. Pole mówiące o wykorzystaniu w atakach ma nadal wartość “nie”. Pole o ujawnieniu publicznym również. Data ostatniej zmiany dokumentu to wciąż 14 lipca, czyli dzień jego publikacji.
Zmieniła się natomiast ocena po stronie samej agencji, i to jest ta połowa warunku, która się ziściła. W polu, w którym CISA zapisuje swoją ocenę każdej podatności, 15 sierpnia stało “istnieje kod dowodzący”. Dziś w tym samym polu stoi “wykorzystanie aktywne”. Obok są dwie kolejne wartości: atak da się w pełni zautomatyzować, a napastnik przejmuje kontrolę całkowitą. Identyczny komplet mają pozostałe trzy pozycje z tej czwórki.
Dla czytelnika oznacza to coś prostszego, niż wygląda. Jedna instytucja zmieniła zdanie i zrobiła to na podstawie danych, których nie publikuje. Druga swojego dokumentu nie tknęła od miesiąca. Kto czeka na chwilę, w której obie powiedzą to samo, może czekać długo. Serwer stoi w tym czasie w internecie.
Dlaczego katalog CISA daje dziś trzy dni zamiast dwudziestu jeden
Trzydniowy termin wygląda dramatycznie i łatwo zrobić z niego nagłówek. Policzyliśmy go jednak na całym pliku katalogu i wychodzi coś odwrotnego.
W 2025 roku standardem było 21 dni: taki termin dostało 226 pozycji z 245. W 2026 rozkład jest inny. Trzy dni ma 78 wpisów, czternaście dni 61, a dawne 21 dni tylko 44. W samym sierpniu tego roku trzydniowy termin dostało trzynaście pozycji z czternastu.
Powód jest formalny i da się go przeczytać. Od 10 czerwca obowiązuje dyrektywa BOD 26-04, która uchyliła tę z listopada 2021 roku, czyli tę, która katalog powołała. Nowa liczy pilność z czterech zmiennych. Pyta, czy zasób jest wystawiony publicznie i czy luka jest w katalogu. Do tego dochodzi, czy atak da się w pełni zautomatyzować i czy napastnik przejmuje kontrolę częściową czy całkowitą. Wszystkie cztery luki mają trzy najwyższe oceny po stronie samej podatności. Czwarta odpowiedź zależy już od konkretnej firmy. Jeśli podatny system jest wystawiony publicznie, ten zestaw prowadzi do najkrótszego progu. To nie jest wyjątek zrobiony dla tych czterech pozycji.
Jedno nieporozumienie warto tu uprzedzić. Typowość trzydniowego progu nie znaczy, że ryzyko jest niskie. Znaczy tyle, że więcej luk trafia dziś do kategorii wymagającej najszybszej reakcji.
Przy okazji rzecz, którą trudno przeoczyć w dokumencie urzędowym. Wśród powodów skracania terminów dyrektywa wymienia wprost sztuczną inteligencję. Jej użycie może dodatkowo zawęzić czas między wydaniem poprawki a możliwym atakiem. Zdanie o kurczącym się oknie reakcji przestało być wyłącznie branżowym przeczuciem i trafiło do uzasadnienia wiążącej dyrektywy.
Dlaczego przed łataniem warto zabezpieczyć ślady, jeśli to możliwe
Ta część jest w polskich relacjach nieobecna, a jest najciekawsza. Opisując wcześniejsze wpisy do katalogu, zaznaczaliśmy, że treści samej dyrektywy nie czytaliśmy, bo strona odmawiała dostępu. Tym razem otworzyła się i okazuje się, że najkrótszy próg nie kończy się na łataniu.
Zapis, który towarzyszy trzydniowemu terminowi, znaczy dokładnie tyle. Trzeba wykonać naprawę w terminie i przeprowadzić analizę śledczą zasobu. Chodzi o ocenę, czy system został już przejęty. Wytyczne wykonawcze idą dalej i odwracają odruch, który wydaje się oczywisty. Zalecają, by tam, gdzie to możliwe, zebrać dowody przed zmianą albo naprawą systemu, bo łatanie potrafi zniszczyć ślady.
Trzy zastrzeżenia trzeba postawić wyraźnie, żeby nikt nie odczytał tego jako polecenia odkładania poprawki. Kolejność pochodzi z wytycznych wykonawczych i jest zaleceniem z zastrzeżeniem “jeśli to możliwe”. Zalecane, a nie obowiązkowe, są też czasy poszczególnych kroków tej analizy, co terminu naprawy w ogóle nie dotyczy. Cała dyrektywa wiąże wreszcie wyłącznie amerykańskie urzędy federalne cywilne. Polska firma nie ma z tego tytułu żadnego obowiązku prawnego. Ma za to gotowy opis postępowania, za który ktoś już zapłacił. Ta procedura zakłada jednak, że problem ma numer, wersję i łatkę. Bywa inaczej, co widać po historii agenta AI, który wykonał polecenie ukryte w logu.
Pierwsza Misja AI · Kodożercy
Zagrożenia AI rozumie ten, kto rozumie, jak ona działa
Kurs Pierwsza Misja AI ma osobną lekcję o ciemnej stronie sztucznej inteligencji: halucynacje, deepfake’i, manipulacja. Zanim zaczniesz się bać, zacznij rozumieć.
Poznaj pełny program →
Co z tym zrobić w polskiej firmie
Zadanie rozkłada się na trzy grupy i w każdej sprowadza się do porównania wersji.
Przy SharePoincie instalowanym na własnych serwerach wystarczy porównać numer kompilacji z wersją zawierającą poprawkę:
- edycja abonamentowa:
16.0.19725.20434 - SharePoint Server 2019:
16.0.10417.20175 - SharePoint Enterprise Server 2016:
16.0.5561.1001
Wszystko starsze jest podatne. Wersji z Microsoft 365 na liście podatnych produktów nie ma.
Przy komputerach Apple sprawdzenie zajmuje chwilę. Poprawka jest w macOS Tahoe 26.6.1, Sequoia 15.7.9 i Sonoma 14.8.9. Luka dotyczy Udostępniania ekranu i pozwala napastnikowi w tej samej sieci zalogować się bez poprawnych danych. Sprawdzenia wymaga każdy komputer z włączoną tą funkcją i niezałataną wersją systemu. W sieci współdzielonej z obcymi urządzeniami rzecz jest tym pilniejsza.
Przy vCenter i przy usłudze IKE od Microsoftu zasada jest ta sama, co przy wcześniejszych wpisach do katalogu. Najpierw wersja, potem dzienniki. Obie luki prowadzą według opisu agencji do wykonania kodu. W vCenter napastnikowi wystarczy dostęp sieciowy do serwera. Luka w usłudze IKE nie jest przy tym wyłącznie sprawą administratorów serwerów. Microsoft wymienia przy niej Windows Server od 2016 do 2025, ale również Windows 10 i Windows 11 w wielu wersjach.
Została jeszcze jedna możliwość, o której dyrektywa mówi wprost, a która rzadko pada w poradach. Wyjęcie systemu z publicznego internetu zmienia odpowiedź na pytanie o wystawienie zasobu. To samo w sobie wydłuża dopuszczalny termin. Odcięcie dostępu jest uznaną formą ograniczenia ryzyka, a nie tylko awaryjnym unikiem. Przesuwa jednak wyłącznie próg pilności, bo podatności nie usuwa i przed atakiem z sieci wewnętrznej nie chroni.
Najczęstsze pytania
Czy polska firma musi naprawić te luki do 21 sierpnia?
Nie. Katalog CISA to narzędzie amerykańskiej administracji, a termin wynika z tamtejszej dyrektywy i wiąże urzędy federalne cywilne. Polska firma nie ma z tego tytułu żadnego obowiązku prawnego. Data mówi natomiast, jak pilnie ocenia sprawę instytucja z dostępem do danych o atakach. Traktowanie jej jako własnego terminu jest rozsądne, ale to decyzja firmy, a nie przepis.
Czy wpis w katalogu dotyczy SharePointa w Microsoft 365?
Nie. Lista podatnych produktów obejmuje wyłącznie SharePointa instalowanego na własnych serwerach: edycję abonamentową, wersję 2019 i Enterprise Server 2016. Usługa w chmurze się na niej nie znalazła. W wielu firmach oba warianty działają jednak równolegle i wtedy sprawdzenia wymaga ten na własnym serwerze.
Podsumowanie
Cztery luki trafiły do katalogu 18 sierpnia ze wspólnym terminem 21 sierpnia. Jest wśród nich ta z SharePointa, o której cztery dni wcześniej pisaliśmy, że w katalogu jej nie ma. Warunek, od którego uzależnialiśmy wtedy zmianę oceny, spełnił się jednak tylko w połowie. Agencja zmieniła swoją ocenę na aktywne wykorzystanie. Microsoft nadal ma we wpisie “nie” i nie ruszał go od 14 lipca. Trzydniowy termin nie jest przy tym sygnałem wyjątkowej paniki. Od czerwcowej dyrektywy jest w tym katalogu najkrótszym progiem dla publicznie wystawionych systemów z tak ocenionymi lukami. Najbardziej praktyczna wskazówka leży zaś w wytycznych do niej i brzmi nieoczywiście. Tam, gdzie to możliwe, warto zebrać dowody przed łataniem, bo poprawka potrafi skasować ślady po kimś, kto wszedł wcześniej.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
