CVE-2026-59310: kampania przeciw VMware vCenter objęła 361 adresów IP w 47 krajach

CVE-2026-59310 przestała być wyłącznie pilną kwestią aktualizacji. Broadcom ujawnił i załatał krytyczną lukę w serwerze Syslog VMware vCenter 29 lipca 2026 r., ale badacze zaobserwowali jej aktywne wykorzystywanie już 3 sierpnia — zaledwie pięć dni później. Kampania objęła 361 zaobserwowanych adresów IP w 47 krajach. Napastnicy wykorzystywali m.in. reverse SSH do utrzymania dostępu, dlatego Shadowserver zalecił uznawać dotknięte systemy za całkowicie przejęte.

Co umożliwia CVE-2026-59310

Broadcom i amerykańska National Vulnerability Database opisują CVE-2026-59310 jako lukę typu directory traversal w serwerze Syslog VMware vCenter. Napastnik, który ma dostęp sieciowy do vCenter, nie musi się uwierzytelniać, aby wykorzystać błąd i uruchomić dowolny kod w podatnym systemie. Luka otrzymała ocenę CVSS 9,8, czyli poziom krytyczny.

W praktyce podatna, wystawiona instancja vCenter może stać się punktem wejścia do utrzymania dostępu i dalszego ataku na infrastrukturę wirtualną. Relacje dotyczące kampanii wskazują na wykonywanie kodu w kontekście root systemu vCenter, choć najbardziej autorytatywne opisy Broadcom i baz podatności potwierdzają przede wszystkim ryzyko zdalnego wykonania dowolnego kodu, bez pełnego opisu uprawnień w każdym przypadku.

Broadcom udostępnił poprawki, ale nie podał obejścia problemu. Oficjalnym sposobem usunięcia podatności jest więc zastosowanie aktualizacji wskazanych przez producenta.

Pięć dni od poprawki do ataku

Broadcom ujawnił CVE-2026-59310 i opublikował poprawki 29 lipca. Firma QUIRSO poinformowała o oznakach aktywnego wykorzystywania luki od 3 sierpnia, a następnie o szybkim rozszerzaniu się kampanii.

Ta kolejność ma duże znaczenie dla reagowania na incydenty. vCenter zaktualizowany po 3 sierpnia nie powinien być automatycznie uznawany za bezpieczny tylko dlatego, że instalacja poprawki zakończyła się powodzeniem. Administratorzy muszą rozdzielić dwa zadania: usunięcie podatności oraz sprawdzenie, czy wcześniej nie doszło do włamania.

Skala kampanii

Badacze powiązali aktywność z 361 zaobserwowanymi adresami IP w 47 krajach. Niemcy, Stany Zjednoczone, Turcja, Iran i Francja miały odpowiadać za ponad połowę zarejestrowanego zbioru.

Liczbę tę należy interpretować ostrożnie. Jeden adres IP nie musi oznaczać jednej organizacji, dlatego „361 ofiar” nie dowodzi, że zaatakowano 361 odrębnych firm lub instytucji. Dostępne raporty wskazują jednak na szeroką kampanię przeciwko systemom vCenter dostępnym z internetu albo osiągalnym z rozległych segmentów sieci wewnętrznych.

Dlaczego pojawia się wątek powiązania z Chinami

QUIRSO oceniło powiązanie kampanii z Chinami z umiarkowaną pewnością. Wśród wskazywanych przesłanek znalazły się artefakty w języku chińskim, narzędzia i publicznie powielane materiały badawcze, aktywność zgodna z godzinami pracy w strefie UTC+08:00 oraz dobór ofiar, który miał wykluczać Chiny kontynentalne.

Są to wskazówki dotyczące regionu lub środowiska językowego, ale nie identyfikują konkretnej chińskiej grupy państwowej ani nie dowodzą, że operacja była kierowana przez rząd. Atrybucja oparta na artefaktach malware’u, porach aktywności i profilu ofiar może zmienić się wraz z pojawieniem się nowych dowodów. Najostrożniejszym określeniem pozostaje więc „podejrzany aktor powiązany z Chinami”, a nie potwierdzona operacja sponsorowana przez państwo.

Jak wyglądał łańcuch ataku

Z dostępnych ustaleń wynika, że CVE-2026-59310 służyła do uzyskania początkowego wykonania kodu, po czym napastnicy wdrażali kolejne warstwy trwałości i dostępu:

1. Directory traversal: spreparowane żądania do usługi Syslog pozwalały wyjść poza przeznaczoną ścieżkę i zapisać treści kontrolowane przez napastników.
2. Trwałość przez cron: według raportów atakujący tworzyli nieprawidłowe wpisy cron, aby zadania cykliczne uruchamiały kolejne polecenia.
3. Dostarczenie backdoora: polecenia curl lub wget pobierały backdoor linuxFile, wykorzystujący WebSocket i obfuskację XOR.
4. Reverse SSH: instalowano narzędzia reverse SSH, które tworzyły wychodzące połączenia z infrastrukturą kontrolowaną przez napastników. Shadowserver poinformował, że ten mechanizm trwałego dostępu pojawił się u wszystkich ofiar uwzględnionych w jego raporcie specjalnym.
5. Wykorzystanie kont i poświadczeń: badacze odnotowali nieautoryzowane konta administratorów vCenter i ESXi oraz nadużywanie poświadczeń VMware Directory Service.
6. Wdrożenie ransomware: część raportów łączyła aktywność z wariantem ransomware wywodzącym się od Babuk, który dodaje rozszerzenie .babyk.

Szczególnie istotne jest ustalenie dotyczące reverse SSH. Według Shadowserver systemy, na których wdrożono ten mechanizm, należy traktować jako całkowicie przejęte. Usunięcie pojedynczego pliku binarnego lub wpisu cron bez odbudowania zaufania do urządzenia i rotacji uprzywilejowanych poświadczeń nie jest wystarczającą metodą odzyskania środowiska.

Ransomware mógł służyć także do zacierania śladów

Opisywana aktywność z rozszerzeniem .babyk nie musi oznaczać typowej kampanii ransomware, której głównym celem jest masowe szyfrowanie danych i wymuszenie okupu. Analitycy sugerowali, że wybiórcze szyfrowanie logów ESXi mogło utrudniać dochodzenie i ukrywać ślady włamania.

To nadal wniosek analityczny, a nie potwierdzone oświadczenie napastników dotyczące ich zamiarów. Obrońcy powinni jednak sprawdzić oba scenariusze: wpływ ransomware na maszyny wirtualne oraz celowe modyfikowanie lub niszczenie logów w celu utrudnienia analizy.

Repozytorium GitHub udające narzędzie do czyszczenia systemu

Raporty powiązały również operację z repozytorium GitHub, w którym pliki reverse SSH przedstawiano jako narzędzie do czyszczenia plików tymczasowych w systemie Linux. Udawanie narzędzia administracyjnego lub porządkowego może ułatwiać dystrybucję komponentu i zmniejszać jego widoczność podczas rutynowych kontroli. Dostępne dowody nie pozwalają jednak niezależnie ustalić, kto prowadził repozytorium, więc jego istnienie nie powinno być traktowane jako dowód atrybucji.

Wpływ na Broadcom i VMware

14 sierpnia akcje Broadcom spadły o około 5–6 proc., gdy do inwestorów dotarły informacje o aktywnym wykorzystywaniu luki w VMware vCenter. Jeden z raportów opisywał ruch kursu z 417,82 do 392,99 dol. w trakcie jednej sesji.

Raporty bezpieczeństwa były jednym z czynników presji na kurs, ale niekoniecznie jedynym. W tym samym czasie pojawiały się także szersze obawy dotyczące spółki, w tym jej ekspozycji na zadłużenie związane z sektorem sztucznej inteligencji. Nie można więc rzetelnie przypisać całego spadku ani dokładnej wartości utraconej kapitalizacji rynkowej wyłącznie CVE-2026-59310.

Dostępne informacje nie wystarczają również, aby stwierdzić, że kampania spowodowała już mierzalny spadek przychodów VMware. Najbardziej uzasadnione krótkoterminowe skutki biznesowe to koszty działań naprawczych klientów, ryzyko zakłóceń operacyjnych i presja reputacyjna. Ewentualny długoterminowy wpływ na przychody wymagałby dodatkowych danych finansowych lub ujawnień spółki.

Co powinni zrobić administratorzy vCenter

Aktualizacja jest pierwszym krokiem, a nie końcem reakcji. Organizacje powinny:

1. Natychmiast zastosować poprawki Broadcom na każdej podatnej instancji vCenter, w pierwszej kolejności na systemach dostępnych z internetu oraz osiągalnych z szerokich segmentów sieci wewnętrznej. Broadcom nie wymienia żadnego obejścia.
2. Traktować system jako przejęty, jeśli występują oznaki włamania, takie jak nieoczekiwane zmiany w cron, artefakty reverse SSH, plik linuxFile, niewyjaśnione pobrania przez curl lub wget, nieznane konta administratorów vCenter albo ESXi oraz nietypowa aktywność VMware Directory Service.
3. Odizolować podejrzane urządzenia i — o ile pozwala na to sytuacja operacyjna — zabezpieczyć obrazy dysków, logi oraz dane ulotne przed odbudową systemu.
4. Zmienić uprzywilejowane poświadczenia, w tym dane vCenter SSO, VMware Directory Service, ESXi lub root, kont API, kont usługowych oraz powiązanych kont administracyjnych. Należy unieważnić aktywne sesje i sprawdzić ścieżki federacji.
5. Odbudować system zamiast ograniczać się do „czyszczenia” w przypadku potwierdzonej trwałości napastnika. Usunięcie nieautoryzowanych kont, zadań cron, plików binarnych, kluczy SSH i tuneli powinno być elementem udokumentowanej procedury reagowania na incydent.
6. Przeszukać całą infrastrukturę wirtualną pod kątem aktywności .babyk, nieoczekiwanych połączeń wychodzących SSH lub WebSocket, nieznanych kont i śladów modyfikowania logów ESXi.
7. Odtworzyć zaufane dane i telemetrię ze znanych, niezmienialnych kopii zapasowych, jeśli logi lub konfiguracje zostały zmienione.
8. Ograniczyć przyszłą ekspozycję poprzez dostęp do zarządzania vCenter wyłącznie z segmentowanych sieci administracyjnych oraz monitorowanie połączeń wychodzących z vCenter i hostów ESXi.

Najważniejszy wniosek operacyjny jest prosty: trzeba zaktualizować każdą podatną instancję vCenter, ale udane zainstalowanie poprawki nie oznacza jeszcze, że środowisko jest czyste. Szybkie rozpoczęcie eksploatacji, trwały reverse SSH i zgłoszone nadużycia kont sprawiają, że wystawione systemy należy badać jako potencjalnie całkowicie przejęte.