BeyondTrust CVE-2026-102764: aktywne ataki na Remote Support

System zdalnego wsparcia ma pomagać administratorowi wykonywać operacje na cudzym urządzeniu. Gdy podatność dotyczy właśnie takiej platformy, konsekwencje mogą wykraczać daleko poza jeden serwer. Trzeba sprawdzić nie tylko wersję produktu, lecz także konta, sesje, pliki i połączenia, do których urządzenie miało dostęp.

16 października CISA dodała CVE-2026-102764 w BeyondTrust Remote Support do katalogu aktywnie wykorzystywanych podatności KEV. Dla amerykańskich agencji federalnych termin działań wyznaczono na 19 października. Ten termin nie jest automatycznie obowiązkiem prawnym polskiej firmy, ale wpis w KEV stanowi mocny dowód, że podatność nie jest już scenariuszem teoretycznym.

Biuletyn BeyondTrust BT26-05 klasyfikuje błąd jako krytyczny, z wynikiem CVSS v4 9,3. Producent opisuje niewłaściwą walidację pochodzenia komunikatów w wewnętrznym komponencie. Zdalny napastnik może w określonych warunkach wykonywać operacje na plikach urządzenia.

Wniosek Breachroad: instalację wystawioną do internetu należy potraktować jednocześnie jako pilne zadanie aktualizacyjne i potencjalny incydent. Poprawka usuwa znaną ścieżkę ataku, ale nie cofa operacji wykonanych wcześniej.

Kto jest narażony

Tabela producenta wskazuje Remote Support w wersjach do 26.2.3 włącznie. Dla wspieranych wersji od 24.3.1 do 26.2.3 dostępna jest poprawka BT26-05-RS. Starszą instalację trzeba najpierw uaktualnić do obsługiwanego wydania, a dopiero potem zastosować właściwą poprawkę.

Sposób działania zależy od modelu wdrożenia:

• klienci BeyondTrust SaaS otrzymali poprawkę od producenta 9 października;
• właściciele instalacji self-hosted muszą potwierdzić automatyczne zastosowanie poprawki albo wdrożyć ją ręcznie;
• brak produktu w centralnym spisie nie jest dowodem jego braku — urządzenie mogło zostać uruchomione przez helpdesk, dostawcę IT lub w ramach starszej umowy.

Biuletyn wymienia Remote Support jako produkt dotknięty CVE. BeyondTrust udostępnił również zapobiegawczą poprawkę dla Privileged Remote Access ze względu na współdzielony kod, ale nie należy przedstawiać tego jako potwierdzenia identycznej podatności w PRA. Właściciele obu produktów powinni korzystać z bieżących instrukcji producenta.

Dlaczego dostęp do plików jest poważnym sygnałem

„Operacje na plikach” nie muszą oznaczać tylko odczytu jednego dokumentu. Wpływ zależy od praw procesu, zawartości urządzenia i integracji. Potencjalnie istotne są pliki konfiguracyjne, klucze, certyfikaty, logi, artefakty aktualizacji oraz dane używane do zestawiania sesji.

Nie wolno jednak dopowiadać skutków, których producent nie potwierdził. Sam wpis KEV nie dowodzi, że każda podatna instalacja została przejęta, a obecność wersji podatnej nie jest równoznaczna z kradzieżą danych. To powód do sprawdzenia dowodów, nie do automatycznego ogłaszania naruszenia.

Plan działania na dziś

1. Znajdź wszystkie instancje. Sprawdź DNS, CMDB, skany powierzchni zewnętrznej, umowy helpdesku i konta dostawców.
2. Rozdziel SaaS od self-hosted. Dla SaaS zachowaj potwierdzenie zakresu i daty poprawki; dla własnej instalacji odczytaj rzeczywisty poziom wersji i patcha.
3. Ogranicz ekspozycję. Jeśli nie można od razu zaktualizować urządzenia, zastosuj ograniczenia zalecane przez producenta i zredukuj dostęp sieciowy bez niszczenia potrzebnych logów.
4. Wdróż poprawkę i zweryfikuj wynik. Nie kończ zadania na komunikacie „instalacja zakończona”. Potwierdź wersję na każdym węźle oraz poprawne uruchomienie usługi.
5. Zachowaj materiał dowodowy. Eksportuj logi uwierzytelnienia, sesji, operacji administracyjnych, zmian konfiguracji oraz ruchu z urządzenia za okres obejmujący czas przed poprawką.
6. Szukaj nieoczekiwanych zmian. Sprawdź nowe konta, klucze, zadania, pliki, integracje i połączenia wychodzące. Porównaj konfigurację z zatwierdzoną kopią.
7. Oceń sekrety i systemy sąsiednie. Jeżeli na urządzeniu były dane dostępowe, certyfikaty lub tokeny, zaplanuj ich kontrolowaną rotację i sprawdź użycie w systemach docelowych.

Przed restartem lub odbudową warto zachować stan potrzebny do analizy. Gdy trwa atak, izolacja może mieć pierwszeństwo, ale czas i zakres każdej czynności trzeba odnotować.

Poprawka nie zastępuje odpowiedzi na pytanie „czy weszli?”

Zespół powinien prowadzić dwa strumienie pracy. Pierwszy ma zamknąć podatność. Drugi ma ustalić, czy wystąpiła aktywność przed zamknięciem. Połączenie ich w jedno zadanie typu „serwer zaktualizowany” często kończy dochodzenie zbyt wcześnie.

Jeżeli pojawiają się ślady manipulacji plikami, nowe konta, nietypowe sesje albo nieznany ruch wychodzący, urządzenie należy obsłużyć zgodnie z planem reagowania. Zakres analizy powinien objąć również hosty, do których z Remote Support zestawiano sesje, oraz konta używane przez operatorów.

Co jest faktem, a co rekomendacją

Zakres wersji, natura błędu, wynik CVSS i sposób dystrybucji poprawki pochodzą z biuletynu BeyondTrust. Aktywne wykorzystywanie i federalny termin 19 października wynikają z katalogu CISA KEV. Źródła nie twierdzą, że każda instalacja została przejęta.

Równoległe patchowanie i triage, kontrola systemów sąsiednich oraz kolejność zachowania dowodów są rekomendacjami Breachroad. Warto wpisać je w stały proces zarządzania podatnościami i plan reagowania na incydenty. Zespoły IT, bezpieczeństwa i właściciele usług mogą przećwiczyć takie decyzje podczas szkoleń cyberbezpieczeństwa dla organizacji, a realną ekspozycję urządzeń i uprzywilejowanych ścieżek zweryfikować w ramach audytu bezpieczeństwa IT.