Luka CVE-2026-59310 w serwerze syslog wchodzącym w skład VMware vCenter pozwala napastnikowi z dostępem sieciowym do vCenter wykonać dowolny kod bez uwierzytelnienia. Broadcom ocenił ją na 9.8 w skali CVSS, czyli w praktyce na maksimum dla podatności zdalnej. 1 18 sierpnia 2026 roku CISA dopisała ją do katalogu Known Exploited Vulnerabilities. 2

TL;DR

  • Produkt: vCenter Server 8.0 (aktualizacje do U3j włącznie), 9.0.x przed 9.0.2.0100, 9.1.x przed 9.1.0.0300, a także pakiety Cloud Foundation, vSphere Foundation oraz Telco Cloud oparte na tych wersjach. 1
  • Wektor: przejście katalogowe (CWE-22) w serwerze syslog, osiągalne przez sieć bez uwierzytelnienia. 1
  • Skutek: zdalne wykonanie kodu na serwerze zarządzającym całym środowiskiem wirtualnym.
  • Status wykorzystania: aktywne ataki obserwowane od początku sierpnia, z ofiarami w kilkudziesięciu krajach. 3 4
  • Poprawka: nota Broadcom z 29 lipca 2026 r.; wersje naprawione to 9.1.0.0300, 9.0.2.0100 oraz odpowiednie wydania gałęzi 8.0. 1 5
  • Pierwszy ruch: natychmiastowa aktualizacja vCenter oraz sprawdzenie, czy serwer nie nawiązuje wychodzących połączeń do nieznanych adresów.

Dlaczego vCenter to najgorsze miejsce na taką lukę

vCenter jest punktem, z którego zarządza się całą infrastrukturą wirtualną: hostami, maszynami, migawkami i uprawnieniami. Przejęcie tego serwera nie oznacza dostępu do jednego systemu, lecz kontrolę nad środowiskiem, w którym te systemy działają. Napastnik z uprawnieniami w vCenter może tworzyć i klonować maszyny, montować dyski, wyłączać zabezpieczenia i sięgać po dane bez logowania się do poszczególnych serwerów.

W polskich realiach vSphere pozostaje podstawą serwerowni w średnich i dużych firmach, w spółkach komunalnych, u dostawców usług hostingowych i w administracji. To środowiska, w których pojedynczy błąd konfiguracji dostępu do vCenter oznacza ryzyko dla całej organizacji.

Jak przebiegają obserwowane ataki

Sekwencja zdarzeń jest tu istotna, bo pokazuje realny czas na reakcję. Broadcom opublikował notę bezpieczeństwa 29 lipca 2026 roku. Pierwsze podatne systemy zaczęły łączyć się z infrastrukturą kontrolowaną przez napastników 3 sierpnia — pięć dni później. 3

Według ustaleń przywoływanych przez media branżowe skala kampanii sięgnęła kilkuset unikalnych adresów ofiar w kilkudziesięciu krajach, a charakter działania wskazuje na zorganizowaną grupę, nie na przypadkowe skanowanie. 3 4 Po uzyskaniu wykonania kodu napastnicy wdrażają narzędzie typu reverse SSH, które tworzy trwałe przejście: to zaatakowany serwer nawiązuje połączenie na zewnątrz, a nie odwrotnie. Taki układ omija reguły zapory nastawione na blokowanie ruchu przychodzącego. 4

Praktyczny wniosek dla obrony jest jasny: samo zablokowanie dostępu z internetu do vCenter nie wystarczy, jeżeli serwer został już przejęty. Trzeba sprawdzić ruch wychodzący.

Co zrobić w 24-48 godzin

  1. Zaktualizuj vCenter do wersji naprawionej. Docelowo 9.1.0.0300, 9.0.2.0100 lub właściwe wydanie gałęzi 8.0 wskazane w nocie Broadcom. 5
  2. Ogranicz dostęp sieciowy do interfejsu zarządzania. vCenter nie powinien być osiągalny z internetu ani z ogólnej sieci użytkowników — dostęp warto wydzielić do sieci administracyjnej.
  3. Sprawdź połączenia wychodzące z serwera vCenter. Nietypowe sesje SSH i utrzymywane połączenia do nieznanych adresów to główny sygnał opisywanej kampanii. 4
  4. Przejrzyj konta i klucze. Nowi użytkownicy, dodane klucze publiczne SSH, zmodyfikowane zadania cykliczne i nietypowe wpisy w logach uwierzytelniania wymagają wyjaśnienia.
  5. Zaplanuj weryfikację powłamaniową, jeżeli aktualizacja następuje po 3 sierpnia. W tym oknie czasowym niezałatany i osiągalny sieciowo vCenter należy traktować jako potencjalnie skompromitowany, dopóki analiza nie wykaże inaczej.

Wskaźniki kompromitacji

Najbardziej użyteczne sygnały mają charakter behawioralny: wychodzące połączenia SSH z serwera vCenter, procesy nasłuchujące uruchomione poza standardowym zestawem usług, pliki zapisane w katalogach powiązanych z obsługą syslog oraz rozbieżność między czasem modyfikacji plików konfiguracyjnych a historią prac administracyjnych.

Podmioty objęte ustawą o krajowym systemie cyberbezpieczeństwa powinny pamiętać o obowiązku zgłoszenia incydentu poważnego do właściwego zespołu CSIRT. Niezależnie od statusu regulacyjnego rekomendujemy kontakt z CSIRT NASK (dawniej CERT Polska) przy potwierdzonym włamaniu oraz zabezpieczenie kopii logów i obrazów maszyn przed przywracaniem środowiska.

Źródła

Zobacz też

Przypisy

  1. Opis podatności, ocena 9.8 CVSS, klasa CWE-22 oraz lista dotkniętych wersji i produktów. — nvd.nist.gov › CVE 2026 59310 ↩ ↩2 ↩3 ↩4

  2. Wpis CISA z 18 sierpnia 2026 r. dodający podatność do katalogu aktywnie wykorzystywanych. — cisa.gov › cisa adds four known exploited vulnerabilities c… ↩

  3. Doniesienia o rozpoczęciu ataków 3 sierpnia 2026 r., pięć dni po ogłoszeniu poprawki, i o zasięgu kampanii. — thehackernews.com › attackers exploit vmware vcenter ↩ ↩2 ↩3

  4. Opis techniki utrwalania dostępu przez odwrócone połączenia SSH. — bleepingcomputer.com › critical vmware vcenter rce flaw exploited for r… ↩ ↩2 ↩3 ↩4

  5. Nota bezpieczeństwa Broadcom z wersjami naprawionymi. — support.broadcom.com ↩ ↩2