BOSH vSphere CPI CVE-2026-41012: przejęcie vCenter przez fałszywy endpoint

Rekord CVE-2026-41012 opublikowany w NVD 29 sierpnia opisuje błąd walidacji certyfikatu w BOSH vSphere CPI. Napastnik znajdujący się na trasie między BOSH Director a vCenter może podszyć się pod REST API vCenter, odebrać poświadczenia przesyłane w HTTP Basic Authentication i przejąć zasoby wirtualizacyjne zarządzane przez skompromitowane konto.

Cloud Foundry Foundation opublikowała biuletyn 27 sierpnia i oceniła lukę na 8,8 High w CVSS 4.0 oraz 7,7 High w CVSS 3.x. Podatne są wszystkie wydania BOSH vSphere CPI wcześniejsze niż 98.0.6. Producent zaleca aktualizację do 98.0.6 lub nowszej wersji i podkreśla, że samo dostarczenie certyfikatu CA nie usuwa ekspozycji.

To nie jest typowy błąd „HTTPS wyłączone”. Połączenie może używać TLS, a mimo to nie zapewniać oczekiwanej tożsamości drugiej strony. Szyfrowanie kanału do serwera kontrolowanego przez atakującego chroni dane przed osobami trzecimi, ale nie przed tym serwerem. Jeżeli klient nie potwierdzi prawidłowo, że certyfikat należy do oczekiwanego vCenter, Basic Auth przekaże nazwę użytkownika i hasło przeciwnikowi.

Dlaczego CPI jest tak istotną granicą zaufania

BOSH Director zarządza cyklem życia wdrożeń, a Cloud Provider Interface tłumaczy jego operacje na działania konkretnej infrastruktury. W przypadku vSphere są to między innymi tworzenie, modyfikowanie, uruchamianie i usuwanie maszyn wirtualnych, operacje na dyskach, datastore’ach, sieciach i zasobach klastra.

Oficjalna lista wymaganych uprawnień pokazuje szeroki zakres: konto CPI może przydzielać sieci, przeglądać i modyfikować pliki datastore, tworzyć oraz usuwać VM, klonować szablony, zmieniać urządzenia wirtualne, wykonywać migracje i operacje zasilania. Konkretne wdrożenie może ograniczyć rolę, ale kompromitacja takiego konta nadal daje dostęp do płaszczyzny zarządzania o znacznie większym wpływie niż pojedynczy workload.

Dlatego biuletyn mówi o możliwym przejęciu wszystkich VM, datastore’ów i sieci, którymi zarządza CPI. Nie należy tego automatycznie rozszerzać na każdy obiekt w całym vCenter — rzeczywisty zasięg jest ograniczony rolą i zakresem przypisania przejętego konta. W wielu środowiskach uprawnienia są jednak szerokie z przyczyn operacyjnych.

Jak wygląda warunek ataku

Napastnik musi uzyskać pozycję pozwalającą przechwycić lub przekierować ruch BOSH Director → vCenter. Może to oznaczać kompromitację elementu sieciowego, zmianę DNS lub routingu, dostęp do tej samej warstwy sieciowej albo kontrolę nad urządzeniem pośredniczącym. Producent klasyfikuje attack vector jako lokalny i attack complexity jako wysoką; nie jest to luka dostępna dowolnej osobie z internetu tylko dlatego, że zna adres Director.

Następnie atakujący wystawia endpoint imitujący REST API vCenter. Rutynowa operacja CPI powoduje połączenie Director z fałszywym serwerem. Nie trzeba przekonywać administratora do ręcznego logowania na witrynie phishingowej — interakcją jest normalna czynność operacyjna systemu, która uruchamia wywołanie.

Basic Authentication nie jest tu samodzielną przyczyną. Używane we właściwie uwierzytelnionym tunelu TLS może być chronione podczas transmisji. Problem polega na tym, że klient wysyła sekret po nawiązaniu kanału z niewłaściwą stroną. Jest to wzorcowy przykład różnicy między poufnością transportu a uwierzytelnieniem endpointu.

Dlaczego plik CA nie wystarcza

Cloud Foundry Foundation jednoznacznie zaznacza, że ekspozycji nie można złagodzić samym podaniem certyfikatu CA. Operator nie powinien więc kończyć analizy na stwierdzeniu „mamy wewnętrzny urząd i HTTPS”. Istotne jest, czy podatna wersja stosuje tę konfigurację we wszystkich wywołaniach REST i poprawnie sprawdza łańcuch, nazwę hosta oraz oczekiwaną tożsamość.

Z tego samego powodu ręczny test przeglądarką nie potwierdza bezpieczeństwa CPI. Przeglądarka i komponent automatyzacji mogą korzystać z innych bibliotek, trust store’ów i ustawień. Weryfikację trzeba wykonać na rzeczywistym połączeniu inicjowanym przez zaktualizowany komponent.

Inwentaryzacja i priorytet

Wyszukaj deploymenty BOSH korzystające z vSphere CPI, w tym środowiska tworzone dawno temu i utrzymywane przez automatyzację, która rzadko zmienia wersję release. Potwierdź wersję zadeklarowaną w manifestach oraz wersję faktycznie wdrożoną na Director. Uwzględnij środowiska testowe: często mają słabszą segmentację, a jednocześnie współdzielą vCenter z produkcją.

Następnie zmapuj endpoint vCenter, sposób rozwiązywania jego nazwy, trasę sieciową, proxy oraz konto używane przez CPI. Oceń rolę w vCenter i miejsca jej propagacji. Im szersze uprawnienia i więcej zarządzanych obiektów, tym większy potencjalny wpływ.

Priorytet powinny otrzymać wersje sprzed 98.0.6, Director działające w sieciach współdzielonych, połączenia przechodzące przez niezaufane urządzenia oraz konta o uprawnieniach na root lub cały datacenter. Brak ekspozycji internetowej nie jest wystarczającą kompensacją, ponieważ założeniem ataku jest pozycja wewnątrz ścieżki.

Bezpieczna aktualizacja

Przejdź do BOSH vSphere CPI 98.0.6 lub nowszego wspieranego wydania. Przed wdrożeniem zapisz manifest, wersję release, fingerprinty artefaktów oraz konfigurację endpointu. Przetestuj typowe operacje CPI: odczyt stanu, utworzenie i usunięcie kontrolnej VM, operacje na dysku, metadane oraz komunikację z wymaganymi obiektami vCenter.

Test negatywny powinien potwierdzić, że komponent odrzuca serwer z nieprawidłowym łańcuchem lub nazwą certyfikatu i nie przesyła mu nagłówka Authorization. Wykonuj go wyłącznie w kontrolowanym środowisku z nieprodukcyjnymi poświadczeniami. Celem jest sprawdzenie poprawki, nie odtworzenie ataku na działającej infrastrukturze.

Po aktualizacji zweryfikuj, czy pipeline automatyzacji nie przywraca starego wydania z przypiętego manifestu lub cache. Sama zmiana jednego Director nie rozwiązuje problemu w pozostałych regionach i środowiskach odzyskiwania awaryjnego.

Czy trzeba rotować poświadczenia vCenter

Jeżeli podatny komponent działał w sieci, którą można było przejąć, wykryto anomalie DNS/routingu, nieoczekiwane certyfikaty albo logowania konta CPI z innych adresów, rotacja jest uzasadniona. Najpierw utwórz nowe poświadczenie o minimalnym wymaganym zakresie, zaktualizuj Director i potwierdź działanie. Dopiero potem unieważnij stare, aby nie utracić kontroli nad wdrożeniami.

Rotacja hasła nie usuwa zmian już wykonanych przez przejęte konto. Porównaj role, permissions, VM, snapshoty, zadania klonowania, konfigurację sieci, datastore’y i zdarzenia administracyjne z zatwierdzonym baseline’em. Sprawdź również guest operations i modyfikacje obrazów lub szablonów, z których później tworzone są nowe maszyny.

Detekcja na trzech warstwach

Na warstwie sieciowej monitoruj zmianę adresu rozwiązywanego dla vCenter, nietypowe trasy, nowe urządzenia proxy i certyfikaty odbiegające od znanego fingerprintu. Alert powinien dotyczyć zmiany tożsamości endpointu, a nie tylko wygaśnięcia certyfikatu.

Na BOSH Director koreluj czas operacji CPI z błędami TLS, ponowieniami, zmianami endpointu i wdrożeniami release. Nie loguj pełnego nagłówka Authorization. Na vCenter szukaj logowań konta CPI z nowych źródeł oraz działań niepasujących do okna deploymentu: zmian ról, masowego klonowania, eksportu plików, nietypowych snapshotów i operacji na wielu VM.

Najsilniejszy sygnał powstaje przez połączenie warstw. Nowy certyfikat na trasie, po którym konto CPI loguje się z innego adresu i wykonuje operacje poza harmonogramem, ma znacznie większą wartość niż każde zdarzenie osobno.

Fakty źródłowe i wnioski Breachroad

Mechanizm przechwycenia, oceny CVSS, zakres wersji, stwierdzenie o niewystarczającym CA i wydanie naprawcze pochodzą z biuletynu Cloud Foundry oraz rekordu CVE. Analiza kolejności rotacji, korelacja detekcji i rekomendacja testu obu stron to wnioski obronne Breachroad. Producent nie informuje w biuletynie o aktywnym wykorzystaniu CVE-2026-41012.

Źródła pierwotne

Automatyzacja infrastruktury używa poświadczeń o dużym wpływie i dlatego jej kanały zarządzające wymagają takiej samej uwagi jak systemy tożsamości. Podczas audytu bezpieczeństwa chmury weryfikujemy granice między orkiestratorem, hypervisorem i siecią zarządzającą. Zespoły mogą przećwiczyć modelowanie podobnych zależności na szkoleniach technicznych z cyberbezpieczeństwa.