Biuletyn Threat Intelligence Nr 21: rekordowe liczby podatności wymuszają nowe podejście do aktualizacji

Podsumowanie

Wrześniowy Patch Tuesday Microsoftu ponownie ustanowił rekord: producent usunął blisko tysiąc podatności, w tym dwie luki aktywnie wykorzystywane w atakach. Krytyczne błędy usunęli również SAP i Fortinet. Z kolei Google w ciągu kilku dni załatał dwie kolejne podatności zero-day w silniku V8 przeglądarki Chrome.

Nie oznacza to jednak, że ryzyko wrasta proporcjonalnie do zwiększającego się wolumenu podatności. Liczba tych, które mogą rzeczywiście zagrozić organizacji, pozostaje na podobnym poziomie. Najważniejszym zadaniem nie jest zatem szczegółowa analiza każdej podatności, lecz zwiększenie wydajności procesu aktualizacji. Poprawki, które mogą być bezpiecznie wdrażane automatycznie, powinny być instalowane bez zwłoki. Decyzje o priorytetach należy pozostawić dla systemów wymagających testów, szczególnych okien serwisowych albo dodatkowych działań ograniczających ryzyko.

Microsoft usuwa blisko tysiąc podatności

We wrześniu Microsoft opublikował poprawki dla 974 podatności w swoich produktach. Największą grupę stanowią 723 luki w Windows, a kolejne dotyczą m.in. pakietu Office, SQL Server, Exchange, SharePoint, narzędzi programistycznych oraz usług Azure. Około 45% błędów umożliwia podniesienie uprawnień, 27% — zdalne wykonanie kodu, a 18% — ujawnienie informacji [1, 2].

Spośród wszystkich luk 113 sklasyfikowano jako krytyczne. Dziewięć z nich dotyczy usług chmurowych, takich jak Entra ID, Azure AI Language, Azure Cosmos DB, Microsoft Fabric, Copilot Studio i Power Automate. Microsoft wdrożył dla nich zabezpieczenia po swojej stronie i oznaczył je jako niewymagające działania klientów [1, 3]..

Istotne podatności

Najpilniejsze pozostają jednak dwie podatności ocenione jako „ważne”, które były wykorzystywane w atakach przed publikacją poprawek.

CVE-2026-81963 — CVSS 7,8 — błąd obsługi dowiązań w Windows Update Stack, pozwalający lokalnemu atakującemu z niskimi uprawnieniami uzyskać uprawnienia SYSTEM [4];

CVE-2026-85880 — CVSS 7,8 — przepełnienie bufora w Windows Advanced Local Procedure Call, umożliwiające ucieczkę z AppContainera i uzyskanie uprawnień SYSTEM bez dalszej interakcji użytkownika [5].

Obie luki służą do podniesienia uprawnień, dlatego wykorzystywane w ramach większych łańcuchów ataków. CISA wyznaczyła amerykańskim instytucjom federalnym termin wdrożenia poprawek na 22 września 2026 r [4, 5, 6].

W pakiecie znajdują się również liczne podatności zdalnego wykonania kodu w usługach sieciowych i komponentach Windows. Szczególną uwagę powinny otrzymać serwery DNS, DHCP, Remote Desktop Services, NFS, RRAS i Message Queuing oraz systemy Exchange i Skype for Business. Część luk może zostać wykorzystana zdalnie, bez uwierzytelnienia i bez działania użytkownika. Ich rzeczywiste znaczenie zależy przede wszystkim od tego, czy dana rola lub usługa jest uruchomiona i osiągalna z sieci.

Zalecane działania

Należy wdrożyć wrześniowe aktualizacje zbiorcze Windows oraz aktualizacje pozostałych używanych produktów Microsoftu. Pierwszeństwo powinny otrzymać systemy objęte dwiema aktywnie wykorzystywanymi lukami, serwery dostępne z Internetu, infrastruktura tożsamości oraz hosty świadczące wskazane usługi sieciowe. Po dystrybucji trzeba sprawdzić nie tylko przypisanie aktualizacji, lecz także jej faktyczną instalację. Szczególnie w przypadku laptopów, użytkownicy często nie uruchamiają ponownie urządzeń, jedynie je hibernując.

Uwaga dla administratorów: problematyczna KB5120998

Opcjonalna aktualizacja podglądowa KB5120998 dla Windows 11 24H2 i 25H2 powodowała na części urządzeń reset ustawień kursora, a na niektórych także zmianę tła pulpitu na czarne. Problem z ustawieniami myszy dotyczył instalacji Windows w językach innych niż angielski. Microsoft usunął oba błędy w aktualizacjach wydanych 8 września.

Chrome: dwie aktywnie wykorzystywane podatności V8 w ciągu kilku dni

Google dwukrotnie w ciągu kilku dni aktualizował Chrome z powodu podatności zero-day w V8: silniku odpowiedzialnym za wykonywanie kodu JavaScript i WebAssembly. CVE-2026-85046 — CVSS 8,8 umożliwia wykonanie kodu wewnątrz sndboxa przeglądarki po otwarciu spreparowanej strony [8, 9]. Kilka dni później Google usunął podobnie wykorzystywaną CVE-2026-87491, pozwalającą na zapis poza wyznaczonym obszarem pamięci i wykonanie kodu w sandboxie [10, 11].

Najnowsza wersja Chrome 153 usuwa łącznie 230 podatności, w tym pięć sklasyfikowanych jako krytyczne. Zaleca się aktualizację Chrome co najmniej do 153.0.8010.36/.37 w Windows i macOS albo 153.0.8010.36 w Linux. Poprawki powinny zostać wdrożone również w Edge, Brave, Operze, Vivaldi i innych przeglądarkach opartych na Chromium, gdy udostępnią je ich producenci.

Równolegle opisano nowe możliwości malware JSCeal, które wyszukuje dane profili wielu przeglądarek Chromium, kradnie hasła, tokeny OAuth i pliki cookie, a następnie może odtworzyć sesję użytkownika i ominąć ponowne uwierzytelnienie do konta Google [12]. JSCeal nie wykorzystuje opisanych podatności V8, ale pokazuje, dlaczego przejęcie procesu lub profilu przeglądarki może prowadzić bezpośrednio do utraty dostępu do kont i usług firmowych.

Dodatkowe rekomendacje

Aktualizacje przeglądarek powinny być wymuszane centralnie, z określonym maksymalnym terminem instalacji i wymuszeniem restsrtu.

Rekomendujemy również przeprowadzenie przeglądu przeglądarek dopuszczonych w organizacji oraz rzeczywiście zainstalowanych. Jeżeli użytkownik ma zainstalowanych kilka przeglądarek opartych na Chromium, a części z nich nie uruchamiał od miesięcy, automatyczna aktualizacja może nie zadziałać. Przestarzałe, zapomniane przeglądarki regularnie pojawiają się w wynikach audytów i skanów jako źródło wielu podatności.

SAP: krytyczna luka pozwala przejąć system bez uwierzytelnienia

We wrześniu SAP opublikował 19 nowych not bezpieczeństwa oraz jedną aktualizację wcześniejszej noty. Cztery podatności sklasyfikowano jako krytyczne. Najpoważniejsza, CVE-2026-44756 — CVSS 10,0, dotyczy obsługi SAP Extended Passport w jądrze SAP. Nieuwierzytelniony atakujący może przesłać spreparowane dane przez warstwę WWW, SAP GUI lub RFC, a następnie wykonać polecenia systemowe z uprawnieniami administracyjnymi SAP. Skutkiem może być dostęp do poświadczeń baz danych, aktywnych sesji i danych biznesowych, modyfikacja konfiguracji oraz przemieszczanie się do kolejnych systemów SAP [13].

Druga szczególnie istotna luka, CVE-2026-58240 — CVSS 9,8, dotyczy SAP NetWeaver Message Server i również może zostać wykorzystana przez sieć bez poświadczeń. Ponieważ podatny kod działa przed uwierzytelnieniem, zaostrzenie ról, polityk haseł lub zasad rozdziału obowiązków nie blokuje tego wektora ataku [13].

Zaleca się pilną inwentaryzację używanych wersji jądra i komponentów SAP oraz wdrożenie właściwych not bezpieczeństwa. W pierwszej kolejności należy aktualizować systemy osiągalne z Internetu i warstw pośrednich, a do czasu zakończenia prac ograniczyć ekspozycję sieciową i monitorować nietypowe żądania oraz polecenia uruchamiane przez procesy SAP.

Fortinet: podatności w monitoringu i dostępie uprzywilejowanym

Fortinet opublikował poprawki dla dziesięciu podatności w swoich produktach. CVE-2026-84390 — CVSS 9,6 w portalu FortiMonitorOnSight pozwala zdalnemu, nieuwierzytelnionemu atakującemu ominąć logowanie przy użyciu podrobionego lub ponownie wykorzystanego tokena JWT [14, 16]. CVE-2026-84388 – CVSS 9,1 w rozszerzeniu Fortinet Privileged Access Agent dla Chrome może natomiast umożliwić przekierowanie ruchu przeglądarki użytkownika, który odwiedzi złośliwą stronę [15, 16].

Usunięcie drugiej luki wymaga skoordynowanej aktualizacji dwóch komponentów: FortiPAM do wersji 1.9.1 lub 1.8.4 oraz rozszerzenia Chrome do wersji 8.0.1.123 lub nowszej. Sama aktualizacja jednego elementu nie zapewnia pełnej ochrony. Poprawki objęły również poważne błędy w FortiSandbox oraz portalu Agentless ZTNA w FortiOS i FortiProxy. Producent nie informuje obecnie o ich wykorzystaniu w rzeczywistych atakach [16].

Administratorzy powinni sprawdzić, czy wskazane produkty są używane, wdrożyć aktualizacje i potwierdzić wersje rozszerzeń na stacjach roboczych. Szczególnego nadzoru wymagają komponenty zapewniające dostęp uprzywilejowany, ponieważ luka w narzędziu ochronnym może zostać wykorzystana do obejścia mechanizmu, któremu organizacja powierza kontrolę nad dostępem administratorów.

Wnioski

Rekordowe liczby mogą łatwo doprowadzić do rekordowych zaległości. Choć wolumen wykrywanych podatności znacząco rośnie, liczba błędów realnie zagrażających organizacji pozostaje na podobnym poziomie [2, 3]. Dlatego im dłużej organizacja analizuje każdą aktualizację, tym szybciej akumulują się podatności, co utrudnia ich obsługę.

Proces powinien działać według zasady: aktualizuj domyślnie, analizuj wyjątki. Jeżeli poprawka dla stacji roboczych, przeglądarek lub typowej aplikacji może zostać wdrożona centralnie i nie wymaga rozbudowanych testów zgodności, należy ją uruchomić etapami możliwie jak najszybciej. Jeżeli użytkownicy odkładają instalację albo ponowne uruchomienie, aktualizacja powinna zostać wymuszona po krótkim, z góry określonym terminie.

Priorytetyzacja pozostaje potrzebna tam, gdzie wdrożenie może zakłócić krytyczną usługę, wymaga testów integracyjnych, okna serwisowego lub współpracy z dostawcą. Wtedy pierwszeństwo powinny otrzymywać podatności aktywnie wykorzystywane, osiągalne z Internetu bez uwierzytelnienia oraz dotyczące infrastruktury tożsamości, urządzeń brzegowych i systemów o wysokim znaczeniu biznesowym. Dla każdej odroczonej aktualizacji powinien zostać wskazany właściciel, termin, uzasadnienie i tymczasowe zabezpieczenie. Triage ma decydować, co zrobić najpierw, a nie tworzyć uzasadnienie, dlaczego pozostałych poprawek nie wdrożono.

W praktyce warto rozdzielić proces na dwa strumienie:

• aktualizacje standardowe – automatyczne wdrażanie falami, krótki pilotaż, ustalony termin wymuszenia, automatyczny restart lub ponowne uruchomienie aplikacji;
• aktualizacje kontrolowane – testy na środowisku reprezentatywnym, decyzja właściciela usługi, zaplanowane okno i ścieżka awaryjna dla luk aktywnie wykorzystywanych.

Skuteczność procesu należy mierzyć czasem od publikacji poprawki do jej potwierdzonego wdrożenia, odsetkiem aktualnych urządzeń, liczbą oczekujących restartów oraz wiekiem wyjątków. Liczba przeanalizowanych CVE może być wskaźnikiem aktywności, ale nie poziomu bezpieczeństwa.

Pracy związanej z aktualizacjami będzie przybywać. Organizacje powinny pogodzić się z tym, że kluczową zdolnością nie będzie coraz bardziej szczegółowe ręczne sortowanie podatności, lecz sprawne, powtarzalne i możliwie zautomatyzowane instalowanie dostępnych poprawek. Tam, gdzie można aktualizować bez złożonych testów – aktualizujemy. Tam, gdzie użytkownicy zwlekają – wymuszamy. Szczegółową analizę zachowujemy dla tych systemów, w których rzeczywiście chroni ona ciągłość działania.

Opracowanie: Mateusz Rakowski