Pięć tygodni ataków, zanim padło ostrzeżenie

Firma bezpieczeństwa watchTowr opublikowała analizę techniczną i kod proof-of-concept dla CVE-2026-8037 29 czerwca 2026 roku, niecały miesiąc po tym, jak Progress Software ujawniło lukę 4 czerwca. Już następnego dnia zespół reagowania na zagrożenia eSentire odnotowywał próby wykorzystania wymierzone w urządzenia Progress Kemp LoadMaster, nieuwierzytelniona lukę typu command injection z oceną CVSS 9.6.

Gdy amerykańska agencja CISA dodała lukę do swojego katalogu znanych wykorzystywanych podatności 7 sierpnia 2026 roku, telemetria zebrana przez eSentire i KEVIntel pokazywała już 792 próby wykorzystania w ciągu 41 dni, pochodzące z 65 unikalnych adresów IP w 18 krajach, w tym z Australii, Chin, Indonezji, Japonii, Polski i Stanów Zjednoczonych. CISA dała amerykańskim cywilnym agencjom federalnym czas do 10 sierpnia 2026 roku, zaledwie trzy dni, na załatanie luki zgodnie z Binding Operational Directive 26-04. Najważniejsza luka czasowa nie dotyczyła jednak tego trzydniowego terminu, lecz mniej więcej pięciu i pół tygodnia między pierwszym rzeczywistym atakiem a momentem, w którym wpis do KEV wymusił temat na agendzie większości zespołów bezpieczeństwa.

Dlaczego load balancer jest celem, którego nikt nie pilnuje

Load balancer nie jest systemem peryferyjnym. Zazwyczaj kończy lub przekazuje ruch dla niemal każdej publicznie dostępnej aplikacji, którą prowadzi organizacja, co daje mu wgląd w sieć i kontrolę nad routingiem, jakiej mają nieliczne inne urządzenia. Skompromitowanie go daje napastnikowi przyczółek z widokiem na wszystko, co znajduje się za nim, znacznie wykraczający poza wyłączenie jednej strony internetowej.

Mimo tej ekspozycji load balancery i podobne urządzenia sieciowe są rutynowo łatane wolniej niż aplikacje webowe, które chronią. Zespoły sieciowe i infrastrukturalne często traktują je jak instalację, której po skonfigurowaniu nie należy dotykać poza zaplanowanym oknem serwisowym. To właśnie ten nawyk sprawia, że nieuwierzytelniona luka umożliwiająca zdalne wykonanie kodu, taka jak CVE-2026-8037, jest tak niebezpieczna: urządzenie najbardziej wystawione na internet jest często tym, które ma najmniejsze szanse na awaryjne załatanie.

Luka w szczegółach: funkcja sanityzująca, którą nie sanityzuje

CVE-2026-8037 znajduje się w funkcji o nazwie escape_quotes, której zadaniem jest usuwanie niebezpiecznych znaków z danych wprowadzanych przez użytkownika, zanim trafiają one do polecenia powłoki. Funkcja nie robi tego w pełni, a luka jest dostępna przez punkt końcowy API /accessv2, gdy tylko API LoadMastera jest włączone. Napastnik nie potrzebuje żadnych danych logowania; wystarczy specjalnie spreparowane żądanie, aby urządzenie wykonało dowolne polecenia.

Dotknięte są wersja GA LoadMastera 7.2.63.1 i starsze oraz wersja LTSF 7.2.54.17 i starsze. Progress Software potwierdziło również ten sam błąd w wersjach MOVEit WAF sprzed GA 7.2.63.2. Dostępne są już poprawione wersje: LoadMaster GA 7.2.63.2 i LoadMaster LTSF 7.2.54.18. Nie ma alternatywy dla zainstalowania tych poprawek; wyłączenie API tam, gdzie nie jest potrzebne, zmniejsza ekspozycję, ale nie zamyka luki w wdrożeniach, które od niego zależą.

Dlaczego to wyzwalacz NIS2, a nie zwykłe zgłoszenie do łatania

Dla organizacji sklasyfikowanych jako podmioty kluczowe lub ważne na mocy unijnej dyrektywy NIS2, nieuwierzytelniona podatność na zdalne wykonanie kodu na urządzeniu infrastrukturalnym wystawionym do internetu jest niemal podręcznikowym przykładem tego, do czego napisano przepisy dyrektywy o zgłaszaniu incydentów. Load balancer umieszczony na granicy sieci, dostępny bez danych logowania i z potwierdzonym aktywnym wykorzystaniem, spełnia praktycznie każde kryterium, którym regulatorzy tacy jak polski CERT Polska posługują się przy definiowaniu poważnego incydentu: wpływ na poufność, integralność lub dostępność z potencjałem wyrządzenia znacznej szkody operacyjnej lub finansowej.

Ma to praktyczną konsekwencję wykraczającą poza samo łatanie. Jeśli urządzenie LoadMaster objęte zakresem NIS2 było wystawione do internetu i działało na podatnej wersji w oknie wykorzystania, termin zgłoszenia może już biec, niezależnie od tego, czy naruszenie zostało dotychczas potwierdzone. Czekanie na pewność wynikająca z analizy śledczej, zanim oceni się obowiązek zgłoszenia, to częsty i kosztowny błąd.

Co właściciele powinni zrobić w tym tygodniu

Kto eksploatuje urządzenie Kemp LoadMaster w wersji GA 7.2.63.1 lub starszej, albo LTSF 7.2.54.17 lub starszej, powinien natychmiast je załatać i priorytetowo potraktować instancje wystawione do internetu. Nie warto czekać na zaplanowane okno serwisowe; telemetria wykorzystania pokazuje, że napastnicy już skanują szeroko i bez wyboru celu, co oznacza, że niezałatane urządzenia są znajdowane przez zautomatyzowane skanowanie.

Poza ta jedną poprawką warto wykorzystać pięciotygodniową lukę czasową między pierwszym wykorzystaniem a wpisem do KEV jako impuls do przeglądu tego, jak organizacja śledzi komunikaty producentów specyficznie dla urządzeń sieciowych i infrastrukturalnych, kategorii, którą programy zarządzania poprawkami skoncentrowane na oprogramowaniu aplikacyjnym często pomijają. Program zarządzania poprawkami, który eskaluje dopiero wtedy, gdy coś pojawi się na rządowej liście wykorzystywanych podatności, z definicji zawsze pozostaje w tyle za napastnikami, którzy znaleźli lukę jako pierwsi.

Czytaj dalej: 45 601 luk, a naprawdę używanych jest 171  |  Martwy budynek kosztuje więcej niż okup