Biuletyn Threat Intelligence Nr 20: Nowa norma — setki poprawek podatności miesięcznie

Podsumowanie

Lipcowe aktualizacje przyniosły rekordową liczbę poprawek w produktach Microsoftu, a istotne podatności usunęli również SAP, Fortinet, Adobe i Broadcom. Przy setkach publikowanych CVE kluczowym problemem staje się szybkie ustalenie, które aktualizacje wdrożyć w pierwszej kolejności. W biuletynie podsumowujemy najważniejsze poprawki i przedstawiamy praktyczne zasady triage opartego na ekspozycji oraz znaczeniu systemu.

Microsoft: rekordowa liczba poprawek utrudnia wybór priorytetów

Lipcowy Patch Tuesday Microsoftu jest największym w historii programu, obejmując 622 unikalne podatności w tym 62 krytyczne. Aż 26 luk ma wynik CVSS przekraczający 9.0, w tym 13 osiąga poziom 9.8. Zidentyfikowano trzy podatności zero-day: dwie są aktywnie wykorzystywane, a jedna została publicznie ujawniona przed wydaniem poprawki [1, 2].

Tak duży pakiet jest kolejnym efektem wykorzystania AI do analizy kodu. Microsoft zapowiedział, że wraz ze wzrostem skuteczności automatycznego wykrywania błędów kolejne aktualizacje mogą obejmować coraz więcej podatności [1, 3].

Aktywnie wykorzystywane luki nie mają najwyższego CVSS

Najpilniejszymi pozycjami nie są podatności ocenione na 9,8 lub 9,9, lecz dwie luki o znacznie niższej punktacji, których wykorzystanie potwierdzono w rzeczywistych atakach:

CVE-2026-56155 — CVSS 7.2 — podatność eskalacji uprawnień w Active Directory Federation Services. Uwierzytelniony atakujący może wykorzystać błąd kontroli dostępu do uzyskania uprawnień systemowych.

CVE-2026-56164 — CVSS 5.3 — podatność wynikająca z braku uwierzytelniania dla krytycznej funkcji w lokalnych instalacjach SharePoint Server. Pozwala nieautoryzowanemu atakującemu na eskalację uprawnień przez sieć.

W przypadku SharePoint zagrożenie jest częścią szerszej aktywności obejmującej również CVE-2026-32201 i CVE-2026-45659. Amerykańska CISA ostrzega przed wykorzystywaniem ich do uzyskania dostępu do lokalnych serwerów SharePoint, zdalnego wykonania kodu, kradzieży kluczy IIS, utrzymania dostępu oraz instalowania złośliwego oprogramowania [4, 5].

Oznacza to, że w przypadku serwerów SharePoint dostępnych z Internetu samo wdrożenie aktualizacji może być niewystarczające. Konieczne jest również sprawdzenie, czy przed aktualizacją nie doszło już do naruszenia. Dodatkowo powinien zostać włączony AMSI w trybie Full Mode. Szczególne znaczenie ma fakt, że 14 lipca zakończyło się rozszerzone wsparcie SharePoint Server 2016 i 2019, bez możliwości wykupienia programu ESU [3, 5].

Windows: największa koncentracja podatności

Spośród 622 podatności aż 416 dotyczy Windows. Około 250 umożliwia eskalację uprawnień, a w całym pakiecie zidentyfikowano 95 błędów pozwalających na zdalne wykonanie kodu. Zagrożenia obejmują kilka różnych powierzchni ataku: komponenty sieciowe, wirtualizację (w tym błąd pozwalający na wydostanie się z VM do hosta), systemy plików i zabezpieczenia systemu [2, 3]

Aktualizacja kończy również kolejny etap wycofywania szyfrowania RC4 z Kerberosa. Po jej wdrożeniu mechanizm RC4 będzie działał tylko dla kont jawnie skonfigurowanych do jego obsługi. Przed szeroką dystrybucją poprawki należy więc przeanalizować zdarzenia audytowe Kerberosa i zidentyfikować starsze konta usługowe oraz systemy, które nadal wymagają RC4. W przeciwnym razie aktualizacja może spowodować problemy z uwierzytelnianiem [3].

Zalecane działania

W pierwszej kolejności zaleca się zaktualizować lokalne serwery SharePoint oraz systemy wykorzystujące AD FS, a następnie zweryfikować je pod kątem wcześniejszego naruszenia. W dalszej kolejności priorytet powinny otrzymać dostępne z sieci komponenty Windows, kontrolery domeny, hosty Hyper-V i inne systemy infrastrukturalne.

Aktualizacje Edge powinny być wymuszane centralnie i kontrolowane niezależnie od aktualizacji systemu operacyjnego. Należy również weryfikować wersje innych przeglądarek opartych na Chromium oraz urządzeń, na których automatyczna aktualizacja może być blokowana przez polityki, brak restartu aplikacji albo długotrwałe pozostawienie otwartych sesji. Ponieważ sam Microsoft opublikował 46 własnych poprawek Edge (i przyjął 427ogólnych poprawek Chromium), warto rozważyć wymuszenie restartu przeglądarek lub całych systemów.

Android: czas na weryfikację aktualizacji

Choć lipcowy biuletyn Google nie wymienia nowych podatności w Androidzie, to w zeszłym miesiącu wydano poprawki dla 124 podatności, w tym aktywnie wykorzystywanej CVE-2025-48595 [7]. Aktualizacje producentów urządzeń zwykle pojawiają się z opóźnieniem, ponieważ poprawki Google muszą zostać dostosowane do konkretnych modeli, sterowników i chipsetów. Jednocześnie poza głównym biuletynem ujawniono CVE-2026-46242 „Bad Epoll” w jądrze Linux, która może dotyczyć części urządzeń z Androidem i pozwalać na uzyskanie uprawnień root [8].

Z tego względu zaleca się zweryfikowanie, czy firmowe urządzenia mają poziom zabezpieczeń co najmniej 2026-06-05, oraz wskazanie modeli, które nie otrzymują już regularnych aktualizacji producenta.

Krytyczne podatności SAP

W lipcowym pakiecie aktualizacji SAP usunął trzy krytyczne podatności. Najpoważniejsza, CVE-2026-44747 (CVSS 9.9), dotyczy SAP NetWeaver Application Server ABAP. Uwierzytelniony atakujący może doprowadzić do uszkodzenia pamięci, a następnie uzyskać nieautoryzowany dostęp do danych, zmodyfikować je lub zakłócić działanie systemu. Dostępne obejście ogranicza funkcjonalność SAP GUI for HTML, dlatego zalecanym rozwiązaniem jest aktualizacja ABAP Kernel [9].

Poprawiono również CVE-2026-27690 — CVSS 9.1 w SAP Approuter, umożliwiającą ujawnienie odpowiedzi użytkowników lub atak DoS, oraz CVE-2026-44761 — CVSS 9.1 w SAP Commerce Cloud, związaną z pozostawieniem domyślnych poświadczeń OAuth 2.0. Zaleca się pilne wdrożenie aktualizacji oraz sprawdzenie środowisk produkcyjnych pod kątem przykładowych klientów OAuth i domyślnych sekretów. Nie potwierdzono dotychczas aktywnego wykorzystania tych luk [9].

Fortinet łata siedem produktów

Fortinet opublikował poprawki dla siedmiu podatności w FortiOS, FortiProxy, FortiPAM i FortiSandbox. Największe praktyczne ryzyko stwarza CVE-2026-59835 w FortiSandbox, umożliwiająca nieuwierzytelnionemu atakującemu dostęp do serwera VNC maszyn wirtualnych analizujących podejrzane pliki. Istotne są również CVE-2026-59839, pozwalająca uwierzytelnionemu użytkownikowi CLI usuwać pliki z głównego systemu plików, oraz CVE-2026-23573 – nieuwierzytelniona podatność XSS w internetowym portalu SSL-VPN.

Pozostałe błędy obejmują przepełnienia bufora oraz manipulowanie odpowiedziami HTTP w portalu captive portal i komunikatach Web Filter. Choć żadnej z siedmiu luk nie sklasyfikowano jako krytycznej, dotyczą one systemów pełniących centralną rolę w ochronie sieci. Zaleca się aktualizację zgodnie z komunikatami Fortinet PSIRT, w pierwszej kolejności dla wystawionych do Internetu usług SSL-VPN i captive portal, ograniczenie dostępu CLI oraz sprawdzenie, czy interfejs VNC FortiSandbox nie jest dostępny z niezaufanych sieci [10].

Krytyczne podatności VMware Avi Load Balancer

Broadcom usunął siedem podatności w VMware Avi Load Balancer. Najpoważniejsza, CVE-2026-47865 (CVSS 9.8), pozwala nieuwierzytelnionemu atakującemu (mającemu dostęp sieciowy) ominąć logowanie i uzyskać dostęp do warstwy sterującej. Pozostałe luki umożliwiają m.in. zdalne wykonanie kodu, podniesienie uprawnień i atak directory traversal.

Producent nie wskazał żadnych obejść, dlatego zaleca aktualizację do wersji 32.1.2, 31.2.2-2p3 lub 30.2.7. Szczególny priorytet powinny otrzymać instalacje, w których interfejs zarządzający jest dostępny z niezaufanych sieci [11].

Wnioski

W ostatnim Biuletynie Threat Intelligence nr 19 wskazywaliśmy, że miesięczne okna serwisowe i priorytetyzacja oparta głównie na CVSS przestają odpowiadać tempu działania atakujących. Lipcowe aktualizacje pokazują kolejny problem. Organizacje muszą nie tylko reagować szybciej, ale też radzić sobie z gwałtownie rosnącą liczbą wykrywanych podatności. W ramach Projekt Glasswing, Anthropic i ok. 50 partnerów wdrożyło poprawki dla łącznie ponad 10 tys. podatności o wysokim lub krytycznym poziomie ryzyka. W dużej mierze ujawniane są błędy, które istniały wcześniej, lecz pozostawały niewykryte [12].

W samym ekosystemie Microsoftu załatano 622 podatności, a kolejnych 427 dotyczyło Chromium wykorzystywanego przez Edge. Ręczna analiza każdej pozycji jest w takiej sytuacji niewykonalna. Co więcej, dwie aktywnie wykorzystywane luki Microsoft sklasyfikował jako „ważną” i „umiarkowaną”. To kolejny dowód, że sama ocena CVSS lub kategoria nadana przez producenta nie wystarczają do określenia kolejności działania. Znacznie ważniejsze jest to, czy podatność jest wykorzystywana, gdzie znajduje się podatny system i do czego może posłużyć jego przejęcie.

Jak zmienić podejście do aktualizacji?

Organizacja muszą identyfikować, które systemy są dostępne z internetu, obsługują tożsamość, ruch sieciowy, pocztę, kopie zapasowe lub mechanizmy bezpieczeństwa. Błędy w takich systemach może mieć pierwszeństwo przed wyżej ocenionym błędem w izolowanej stacji roboczej. Pozwoli to utworzyć przyspieszoną ścieżkę dla podatności:

• aktywnie wykorzystywanych lub obecnych w katalogu KEV,
• dostępnych z internetu bez uwierzytelnienia,
• posiadających publiczny exploit albo wiarygodny PoC,
• dotyczących systemów tożsamości, VPN, urządzeń brzegowych, backupu i narzędzi bezpieczeństwa,
• umożliwiających przejęcie kontroli nad krytycznym procesem biznesowym.

Dla tej grupy decyzja o sposobie reakcji powinna zapadać w ciągu godzin, a aktualizacja lub skuteczne ograniczenie ryzyka — zwykle w ciągu 24–72 godzin. Jeśli poprawki nie można od razu wdrożyć, konieczne jest ograniczenie dostępu, wyłączenie podatnej funkcji, segmentacja albo dodatkowy monitoring. Takie zabezpieczenia są jednak rozwiązaniem tymczasowym, a nie zamiennikiem aktualizacji.

Pozostałe podatności powinny trafiać do następnych kolejek, ocenianych na podstawie ekspozycji, znaczenia zasobu, wymaganych uprawnień, dostępności exploita i istniejących zabezpieczeń. Zarządzanie ryzykiem nie powinno oznaczać rezygnacji z mniej pilnych poprawek. Odpowiada ono na pytanie „co wdrożyć najpierw”, a nie „czego nie trzeba aktualizować”.

Co więcej, masowe aktualizacje stacji roboczych, przeglądarek i popularnych aplikacji powinny być maksymalnie zautomatyzowane. Tym co warto rozważyć to wymuszanie ponownego uruchomienia oprogramowania lub systemu. Takie działania wiążą się zwykle z oporem użytkowników. Praktyka pokazuje jednak, że komunikaty z wyprzedzeniem oraz przyzwyczajenie do przewidywalnego harmonogramu pozwalają mocno ograniczyć niezadowolenie. Efektem jest natomiast zmniejszenie powierzchni ataku.

Ostatecznie miarą skuteczności nie może być liczba przeanalizowanych CVE ani zainstalowanych poprawek. Ważniejsze są: czas identyfikacji podatnych zasobów, czas zabezpieczenia systemów krytycznych, odsetek zaktualizowanych urządzeń oraz wiek zaakceptowanych wyjątków.

Opracowanie: Mateusz Rakowski