Apache CloudStack CVE-2026-50112: plik Metalink prowadził do root na hoście KVM
Tenant z rolą User mógł ominąć walidację wewnętrznych URL-i Metalink, wywołać SSRF i uzyskać wykonanie poleceń jako root na współdzielonym hoście KVM.
- AUTOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLIKACJA
- 22 sierpnia 2026
- CZAS CZYTANIA
- 19 min czytania
- TEMAT
- Chmura, infrastruktura i DevSecOps
22 sierpnia publiczny rekord CVE-2026-50112 został zaktualizowany po komunikacie Apache opublikowanym dzień wcześniej. To jedna z tych podatności, w których niewielka różnica między walidacją adresu zewnętrznego i adresów zagnieżdżonych prowadzi do złamania granicy całej chmury. Uwierzytelniony tenant Apache CloudStack z domyślną rolą User może zarejestrować szablon wskazujący na plik Metalink, a wewnętrzne odnośniki tego pliku nie przechodzą ponownie przez allowlistę schematów.
Skutki obejmują dwa powiązane scenariusze. Secondary Storage VM może pobierać wewnętrzne zasoby, co tworzy SSRF i możliwość zachowania odpowiedzi jako szablonu dostępnego później przez zwykłe API. W środowisku KVM ścieżka z Metalink i NFS może natomiast doprowadzić do wykonania poleceń jako root na hoście hypervisora, również takim, który obsługuje maszyny innych tenantów. To nie jest przejęcie pojedynczej VM, lecz ryzyko cross-tenant na warstwie compute.
Podatne i poprawione wydania
Apache wskazuje zakres 4.14.0.0–4.20.3.0 oraz 4.21.0.0–4.22.1.0. Poprawki znajdują się w 4.20.3.1, 4.22.1.1 i późniejszych wersjach. Administrator powinien ustalić numer Management Server oraz agentów KVM i nie zakładać, że zaktualizowany interfejs zarządzający oznacza zaktualizowany cały dataplane.
Najwyższy priorytet mają środowiska KVM z publicznie dostępnym API rejestracji szablonów, kontami tenantów, directDownload=true lub obsługą Metalink/NFS. SSRF przez Secondary Storage VM pozostaje istotny także wtedy, gdy nie ma KVM, ponieważ ta maszyna systemowa może mieć dostęp do sieci zarządzającej, storage, metadanych chmurowych i usług niewidocznych z sieci gościa.
Nie ma podstaw, by rozszerzać zakres na każdą konfigurację CloudStack bez potwierdzenia. Advisory opisuje konkretne przepływy szablonu i hypervisor KVM. Inwentaryzacja powinna więc rozdzielać zarządzanie, Secondary Storage VM, agentów KVM, NFS, direct download i egress zamiast oznaczać wszystkie klastry jednym statusem.
Dlaczego kontener Metalink zmienia model zaufania
Metalink jest dokumentem opisującym plik i potencjalnie wiele źródeł lustrzanych. Użytkownik podaje URL dokumentu, lecz downloader później podejmuje kolejne decyzje na podstawie jego zawartości. Walidacja wyłącznie zewnętrznego URL-a sprawdza opakowanie, nie rzeczywiste miejsca pobierania.
To klasyczny problem parser–fetcher. Warstwa API może dopuścić HTTPS do zaufanej domeny, ale dokument pobrany z tej domeny zawiera schemat lub host, którego polityka nigdy by nie przyjęła bezpośrednio. Gdy agent przekazuje zagnieżdżony adres do innego komponentu, granica zaufania przesuwa się z Management Server na KVM lub Secondary Storage VM.
Allowlista musi być stosowana po każdym przekierowaniu i po rozwiązaniu każdego źródła, a decyzja powinna uwzględniać zarówno schemat, jak i cel sieciowy. Sam zakaz jednego protokołu nie zatrzymuje SSRF do loopback, adresów link-local lub segmentu zarządzającego przez dozwolony HTTP. DNS także może zmienić wynik pomiędzy walidacją i pobraniem, dlatego fetcher potrzebuje kontroli na etapie realnego połączenia.
Dlaczego rola User nie jest „małym” uprawnieniem
W chmurze multi-tenant tenant ma prawo tworzyć zasoby, obrazy i maszyny. To szeroka możliwość sterowania dataplane, lecz nie prawo do hosta. CVE-2026-50112 zamienia legalną operację rejestracji szablonu w wejście dla komponentu uprzywilejowanego. Management API jest tylko początkiem łańcucha; dalsze kroki wykonuje agent mający dostęp do storage i systemu operacyjnego hypervisora.
Ocena ryzyka musi więc uwzględniać liczbę kont tenantów, możliwość samodzielnej rejestracji template, współdzielenie hostów oraz wartość innych workloadów na tych hostach. Nawet pojedyncze konto deweloperskie może stać się drogą do wielu klientów. Wewnętrzna chmura jednego przedsiębiorstwa nadal może przekraczać granice działów i stref danych.
Jak ocenić ekspozycję bez ryzykownego testu
Zacznij od wersji i konfiguracji. Zidentyfikuj strefy KVM, Secondary Storage VM, role pozwalające wywołać rejestrację szablonu, wykorzystanie direct download oraz dozwolone typy URL. Przejrzyj historię API dla rejestracji template i ISO, pola URL, obecność plików .metalink, konta inicjujące oraz hosty wykonujące pobieranie.
Nie odtwarzaj ścieżki wykonania kodu na produkcyjnym hypervisorze. Bezpieczny test regresji może użyć izolowanego laboratorium bez workloadów i neutralnego niedozwolonego celu, aby potwierdzić, że wewnętrzny URL dokumentu zostaje odrzucony. Wynikiem ma być kontrolowany błąd polityki, nie połączenie z usługą zarządzającą ani zapis pliku na hoście.
W logach szukaj rozbieżności: zewnętrzny URL Metalink z innymi hostami lub schematami wewnątrz, pobrania z adresów prywatnych, link-local i loopback, niespodziewanych mountów NFS, procesów potomnych agenta KVM oraz plików powstałych poza katalogiem obsługi szablonów. Koreluj Management Server, SSVM, hypervisor i storage wspólnym job ID lub identyfikatorem template.
Plan aktualizacji
Wykonaj kopię konfiguracji i bazy zarządzającej zgodnie z procedurą CloudStack, ale traktuj snapshot jako możliwość odtworzenia, nie mitygację. Ustal ścieżkę do 4.20.3.1 lub 4.22.1.1. W staging sprawdź rejestrację zwykłych szablonów, redirecty, mirror failover, checksum, direct download i lifecycle istniejących obrazów.
Rollout powinien obejmować Management Server, odpowiednie System VM i agentów zgodnie z dokumentacją wydania. Po aktualizacji potwierdź rzeczywiste wersje działających komponentów. W środowisku HA unikaj sytuacji, w której część ruchu nadal trafia do starego węzła.
Jeżeli patch musi czekać, czasowo odbierz nieadministracyjnym rolom możliwość rejestracji z zewnętrznego URL-a, wyłącz niepotrzebny direct download i ogranicz egress SSVM oraz hostów KVM. Reguły sieciowe powinny blokować dostęp downloaderów do panelu zarządzającego, metadanych, loopback i segmentów infrastruktury. Te kroki zmniejszają zasięg, ale Apache rekomenduje aktualizację, bo nie wszystkie semantyczne warianty da się pewnie odfiltrować na brzegu.
Reagowanie na potencjalne naruszenie hypervisora
Podejrzany Metalink wymaga szerszej odpowiedzi niż usunięcie template. Zabezpiecz rekordy API, treść dokumentu, logi agenta, procesy, połączenia, historię mountów i integralność pakietów hosta. Oddziel zagrożony hypervisor od schedulerów, ale nie wyłączaj go bez oceny wpływu na pamięć ulotną i działające VM.
Jeżeli potwierdzisz wykonanie jako root, przyjmij utratę zaufania do hosta. Migracja workloadów, odbudowa z zaufanego obrazu, rotacja poświadczeń dostępnych hostowi i ocena sąsiednich tenantów będą bezpieczniejsze niż ręczne usuwanie jednego artefaktu. Sprawdź także SSVM, NFS i Management Server, ponieważ łańcuch przechodzi przez kilka płaszczyzn.
Sam nietypowy URL nie dowodzi kompromitacji. Legalne repozytoria mogą używać mirrorów i przekierowań. O rozstrzygnięciu decydują osiągnięty cel, zachowany plik, aktywność procesów oraz spójność czasu pomiędzy API i hostem.
Dowód skutecznej segmentacji
Po patchu sprawdź również kontrolę sieciową. Dokumentacja firewall i deklaracja IaC nie dowodzą, że proces pobierający nie ma trasy do wrażliwego celu. Zbieraj flow logs z interfejsów SSVM i hostów KVM, testuj rozwiązywanie DNS z ich rzeczywistego namespace oraz potwierdź blokadę IPv4, IPv6 i adresów link-local.
Egress policy powinna mieć właściciela i test ciągły. Nowy storage, proxy lub interfejs zarządzający może otworzyć ścieżkę poza przeglądem CloudStack. Patch usuwa znany błąd walidacji, a segmentacja ogranicza skutki kolejnego błędu w downloaderze; żadna z tych warstw nie zastępuje drugiej.
Fakty Apache i wnioski Breachroad
Zakres wydań, rola User, SSRF w SSVM, cross-tenant root na KVM oraz poprawione wersje pochodzą z komunikatu Apache. Aktualizacja rekordu 22 sierpnia nie oznacza, że podatność powstała dziś; dzisiejszą informacją jest pełne publiczne opisanie i dystrybucja danych do baz.
Segmentacja downloadera, korelacja telemetryki, bezpieczny test oraz procedura odbudowy hypervisora są wnioskami Breachroad. Szkolenia cyberbezpieczeństwa dla zespołów technicznych uczą analizy takich łańcuchów zaufania, a audyt bezpieczeństwa chmury może zweryfikować role, System VM, egress, KVM, storage i materiał dowodowy aktualizacji.
