Veeam Backup & Replication 13: sześć CVE i dwa RCE z wynikiem 9,9

12 marca 2026 roku Veeam opublikował KB4831 dla sześciu podatności w Veeam Backup & Replication 13. Dwie z nich — CVE-2026-21669 i CVE-2026-21708 — mają CVSS 9,9 i mogą prowadzić do zdalnego wykonania kodu przez uwierzytelnioną tożsamość. Pozostałe dotyczą ekstrakcji zapisanych credentiali SSH, RCE w środowisku HA, lokalnej eskalacji i obejścia egzekwowania podpisu sterownika.

Poprawione wydanie to 13.0.1.2067; podatne są 13.0.1.1071 i wcześniejsze buildy v13 wskazane w KB. Producent wyraźnie ostrzegł, że po publikacji poprawki możliwy jest reverse engineering zmian. Backup server trzeba więc potraktować jak system krytyczny, a nie zaplanować aktualizację w zwykłym oknie za kilka miesięcy.

Sześć różnych granic zaufania

CVE-2026-21669 pozwala uwierzytelnionemu użytkownikowi domenowemu wykonać kod na serwerze backupu w instalacji Windows. Wynik 9,9 bierze się z bardzo małego wymagania początkowego: zwykłe konto domenowe nie powinno mieć ścieżki do kodu na zasobie przechowującym kopie całego środowiska. To scenariusz szczególnie istotny po phishingu lub przejęciu konta pracownika.

CVE-2026-21708 dotyczy roli Backup Viewer i umożliwia wykonanie kodu jako użytkownik postgres; obejmuje wariant Windows i appliance. Rola odczytowa brzmi bezpiecznie, ale w systemie o tak bogatej logice nawet dostęp „view” może docierać do niebezpiecznego interpretera lub warstwy danych.

CVE-2026-21670 umożliwia użytkownikowi o niskich uprawnieniach wydobycie zapisanych poświadczeń SSH. CVE-2026-21671 prowadzi do RCE przez Backup Admina w wdrożeniu HA appliance. CVE-2026-21672 jest lokalną eskalacją w Windows, a CVE-2026-21709 pozwala lokalnemu administratorowi ominąć egzekwowanie podpisu sterownika. Każda wymaga innej pozycji startowej; nie należy łączyć ich w jedno twierdzenie „każdy może zdalnie przejąć Veeam”.

Dlaczego serwer backupu jest celem tier zero

VBR zna hypervisory, repozytoria, serwery, agenty i konta usług. Może odczytywać dane, uruchamiać zadania na hostach, przeprowadzać restore i usuwać punkty przywracania. Kompromitacja nie ogranicza się do jednego systemu: atakujący może szukać credentiali, sabotować odzyskiwanie albo wykorzystać zaufane kanały do ruchu bocznego.

Backup powinien być ostatnią linią obrony przed ransomware. Jeżeli administracja kopii używa tego samego Active Directory, tej samej stacji administratora i tych samych tras sieciowych co produkcja, jeden przejęty użytkownik domenowy może znaleźć krótką drogę do systemu, który miał ratować firmę.

Ustalenie rzeczywistej ekspozycji

Zbierz wersję konsoli, serwera, appliance’a, węzłów HA i komponentów proxy/repository. Dowodem jest aktywny build procesu, nie wersja instalatora na udziale. Zapisz role kont, domenowe grupy mające dostęp, systemy zarządzające i trasy sieciowe. Sprawdź również nieużywane serwery DR, które uruchamiają się tylko podczas testu.

Następnie odpowiedz:

• czy dowolny Domain User może osiągnąć porty usługi VBR;
• które konta mają Backup Viewer i Backup Admin;
• jakie credentiale SSH są zapisane i do czego prowadzą;
• czy appliance HA i Windows wymagają różnych pakietów;
• czy repozytoria immutable są administracyjnie oddzielone;
• czy Veeam loguje do systemu poza własną domeną.

CVSS 9,9 nie oznacza braku uwierzytelnienia. Oznacza, że wymagane uprawnienia są niskie w relacji do pełnego wpływu. To dokładnie przypadek, w którym kontekst tożsamości jest ważniejszy od etykiety „internal only”.

Kolejność aktualizacji

Przed zmianą zabezpiecz konfigurację, logi i dane o zadaniach. Potwierdź integralność backupów oraz dostęp do niezależnego, offline lub immutable punktu odtworzenia. Następnie zaktualizuj serwer i wymagane komponenty zgodnie z KB4831 do 13.0.1.2067 lub nowszej poprawionej wersji.

W HA plan powinien uwzględniać kolejność węzłów, kompatybilność i test failover. Po aktualizacji sprawdź build każdego procesu, nie tylko numer w konsoli. Wykonaj kontrolowany backup i restore syntetycznego zasobu, a następnie potwierdź, że monitoring, repozytoria, agenty i integracje nadal działają.

Nie używaj w produkcji publicznego PoC do potwierdzania RCE. Wersja, osiągalność i rola wystarczają do decyzji. Aktywny exploit może uszkodzić usługę, bazę albo kopie i zaciera granicę między testem a incydentem.

Hunting i odzyskanie

Przejrzyj logowania kont domenowych do VBR, zmiany RBAC, tworzenie i uruchamianie nietypowych zadań, eksport credentiali, modyfikacje repozytoriów i retencji, wyłączenie immutability oraz operacje usuwania. Koreluj procesy potomne usług Veeam, połączenia do hostów zarządzanych, nietypowe zapytania do PostgreSQL i zmiany sterowników w Windows.

Jeśli dowody wskazują RCE, załóż utratę sekretów dostępnych z serwera: kont usługowych, SSH, hypervisorów, chmury i storage. Rotuj je w systemach docelowych, odbuduj serwer z zaufanego obrazu i dopiero potem podłącz repozytoria. Nie pozwól przejętemu control plane’owi ponownie zarządzać zdrowymi kopiami.

Architektura odporna na kolejne CVE

• oddziel domenę lub co najmniej warstwę tożsamości backupu;
• używaj dedykowanych, nieinteraktywnych kont o minimalnym zakresie;
• ogranicz porty VBR do jawnych komponentów;
• stosuj hardened repository i immutability z niezależnym administratorem;
• wymagaj PAM/JIT dla ról Backup Admin;
• trzymaj zewnętrzne logi i alarmuj zmiany retencji, repozytoriów oraz kont;
• regularnie testuj restore bez zależności od produkcyjnego AD.

Połącz ten plan ze strategią kopii 3-2-1, PAM i reakcją na ransomware. Jeżeli kopie mają być rzeczywistą ostatnią linią obrony, BreachRoad może przetestować ich segmentację i ścieżki tożsamości.

---

Źródło pierwotne: Veeam KB4831.