Dziewięć Dni od Poprawki do 361 Ofiar

Broadcom opublikował ostrzeżenie VMSA-2026-0006 29 lipca 2026 roku, ujawniając CVE-2026-59310 wraz z towarzyszącą mu luką obejścia uwierzytelniania, CVE-2026-59309, w VMware vCenter Server w wersjach 8.0, 9.0 i 9.1. Poprawione wersje udostępniono tego samego dnia: vCenter 9.1.0.0300, vCenter 9.0.2.0100 oraz vCenter 8.0 U3k lub U2f, w zależności od używanej ścieżki aktualizacji.

QUIRSO GmbH, niemiecka firma zajmująca się informatyką śledczą i reagowaniem na incydenty, podaje, że infrastruktura kontrolowana przez atakującego zarejestrowała pierwsze połączenia przychodzące od zaatakowanych systemów vCenter 3 sierpnia 2026 roku, zaledwie pięć dni po wydaniu poprawki. Do 7 sierpnia firma naliczyła 361 odrębnych adresów IP ofiar rozproszonych w 47 krajach, przy czym mniej więcej połowa była skoncentrowana w Niemczech, Stanach Zjednoczonych, Turcji, Iranie i Francji. QUIRSO opublikowało regułę detekcji YARA wraz ze swoimi ustaleniami, ale wstrzymało niektóre wskaźniki naruszenia bezpieczeństwa na czas współpracy z organami ścigania.

Funkcja Syslogu, Która Oddaje Cały Serwer

CVE-2026-59310 znajduje się w logice obsługi katalogów komponentu Syslog Server w vCenter. Własne ostrzeżenie Broadcomu stwierdza wprost, że złośliwy podmiot z dostępem sieciowym do vCenter może wykorzystać ten problem do uruchomienia dowolnego kodu, a co kluczowe - bez wcześniejszego uwierzytelnienia. To właśnie to połączenie, brak uwierzytelnienia oraz wykonanie kodu na poziomie systemu, przyniosło tej luce wynik krytyczności 9,8 na 10 i sprawia, że każda instancja vCenter dostępna z internetu staje się celem natychmiastowym, a nie teoretycznym.

vCenter nie jest narzędziem peryferyjnym. To płaszczyzna zarządzania całym środowiskiem wirtualizacji organizacji - konsola, która udostępnia, migruje i kontroluje każdą maszynę wirtualną, jakiej używa firma. Ostrzeżenie dostawcy dotyczące akurat tego produktu nigdy nie powinno trafiać do tej samej kolejki co rutynowa poprawka aplikacji.

Dlaczego reverse_ssh Pokonuje Regułę Zapory, Którą Już Masz

Zamiast otwierać nasłuchujący port na zaatakowanym serwerze vCenter - coś, co większość systemów monitorowania sieci jest zaprojektowana wykrywać - atakujący stojący za tą kampanią instalują reverse_ssh, otwartoźródłowe narzędzie w Go, które sprawia, że zaatakowana maszyna nawiązuje wychodzące połączenie SSH z powrotem do infrastruktury atakującego. Ponieważ połączenie jest wychodzące, może ono ominąć reguły zapory sieciowej skonfigurowane do blokowania niechcianego ruchu przychodzącego, które jednak przepuszczają zwyczajnie wyglądające sesje wychodzące, dając atakującemu trwały, interaktywny przyczółek, który przetrwa prosty przegląd segmentacji sieci.

Dla urządzenia, które już zajmuje centralne miejsce w środowisku wirtualizacji organizacji, ten mechanizm trwałości zamienia jeden niezałatany serwer vCenter w długotrwały przyczółek, a nie jednorazowe włamanie.

Teza Oryginalna: Prawdziwa Historia To Luka w KEV

Większość doniesień o podatnościach mierzy pilność tym, czy dana luka trafiła do katalogu Known Exploited Vulnerabilities agencji CISA, a wiele programów łatania jest zbudowanych, formalnie lub nieformalnie, wokół właśnie tego wyzwalacza. CVE-2026-59310 łamie to założenie. Niezależna telemetria zarówno QUIRSO, jak i firmy bezpieczeństwa Rapid7 udokumentowała setki rzeczywistych naruszeń w 47 krajach w ciągu pierwszych półtora tygodnia od ujawnienia, a mimo to w chwili pisania tego artykułu CVE nadal nie pojawiła się w katalogu CISA. Proces łatania, który traktuje wpis do KEV jako sygnał do eskalacji ostrzeżenia dotyczącego vCenter do statusu awaryjnego, był więc z definicji już o tygodnie w tyle za atakującymi, którzy znaleźli i uzbroili tę lukę.

Lekcja wykracza poza to pojedyncze CVE. W przypadku oprogramowania na poziomie infrastruktury, takiego jak konsola zarządzania hiperwizorem, telemetria niezależnej firmy śledczej lub sam wynik krytyczności nadany przez dostawcę powinny same w sobie wystarczyć do wywołania awaryjnego łatania, bez czekania na wpis w rządowym katalogu, który tym razem po prostu nie pojawił się na czas.

Co Powinni Zrobić Teraz Operatorzy vCenter

Każda organizacja korzystająca z vCenter 8.0, 9.0 lub 9.1, która nie zastosowała jeszcze poprawek z 29 lipca, powinna potraktować to jako zmianę awaryjną, a nie planową, oraz powinna potwierdzić, że interfejs zarządzania nie jest bezpośrednio dostępny z publicznego internetu, co i tak nigdy nie powinno mieć miejsca. Biorąc pod uwagę udokumentowaną tu metodę trwałości opartej na połączeniach wychodzących, monitorowanie wychodzących połączeń SSH inicjowanych przez serwery na poziomie infrastruktury, a nie tylko dostęp przychodzący do nich, jest teraz częścią pełnej strategii wykrywania dla tej konkretnej kampanii.

Dla istotnych i ważnych podmiotów w UE objętych dyrektywą NIS2, które w oknie wykorzystywania luki eksploatowały instancje vCenter dostępne z internetu lub w inny sposób narażone, ten incydent wpisuje się dokładnie w kategorie, dla których napisano tę dyrektywę: nieuwierzytelnione zdalne wykonanie kodu na infrastrukturze z potwierdzonym aktywnym wykorzystywaniem oraz realną możliwością wpływu na poufność, integralność lub dostępność całego środowiska wirtualizacji.

Czytaj dalej: Dwa Wywołania API Dały 295 Atakującym Dostęp Root  |  CVSS 9.6: luka uderzyła w load balancery 792 razy