9 października Ahsay zaczął dostawać od partnerów zgłoszenia o nieautoryzowanym dostępie do serwerów AhsayCBS. 14 października CISA dopisała dwa CVE tego produktu do katalogu znanych wykorzystywanych podatności z terminem usunięcia na 17 października. Między tymi datami producent przyznał, że jego własne wcześniejsze łatki — v10.3.4.0 i v9.15.2.59 — nie usunęły problemu.
Co się właściwie stało
AhsayCBS to centralna konsola platformy backupowej sprzedawanej w modelu partnerskim: dostawca usług stawia serwer CBS, a klienci końcowi wysyłają do niego kopie agentami OBM i ACB. Jeden serwer, kopie wielu organizacji. To wyjaśnia, dlaczego ta sprawa ma inną wagę niż przeciętny wpis w katalogu.
Podatności są dwie i łączą się w łańcuch. CVE-2026-105133 (CWE-287) pozwala ominąć uwierzytelnienie przez manipulację parametrem random w funkcji checkSysPwd komponentu API. CVE-2026-105134 (CWE-77/78) pozwala wykonać polecenia systemowe przez ten sam parametr w punkcie /rps/api/json/UpdateReceivers.do komponentu Replication Receiver. Obie trafiły do bazy NVD 4 października 2026, obie z adnotacją, że exploit jest publiczny. Druga ma ocenę CVSS 3.1 równą 10.0 i CVSS 4.0 równą 9.3 — nieuwierzytelnione wykonanie kodu na serwerze, który trzyma kopie zapasowe.
Oś czasu producenta, opublikowana 13 października: 9 października pierwsze zgłoszenia partnerów o włamaniach, 10 października hotfix v10.3.4.45 dla wersji 10, 12 października hotfix v9.15.2.70 dla wersji 9 wraz z zaleceniem, by posiadacze wersji 7 i 8 najpierw podnieśli się do v9.15.0.0, a 13 października instrukcja wykrywania kompromitacji. Dzień później wpis do katalogu CISA z trzydniowym terminem. Tydzień od pierwszego zgłoszenia do zamknięcia sprawy w reżimie amerykańskiej dyrektywy BOD 26-04.
Łatka, która nie zamknęła dziury
Najważniejsze zdanie całej sprawy producent napisał 12 października w komunikacie o poprawkach: „We would like to inform you that our previous patches v9.15.2.59 and v10.3.4.0 did not fully address the following security vulnerabilities: CVE-2026-105133 CVE-2026-105134”. To nie jest opóźnienie wydania łatki. To wydana i rozesłana łatka, która nie działała.
Konsekwencja jest gorsza niż samo opóźnienie. Wpis w NVD do dziś podaje, że „upgrading to version 10.3.4 is able to resolve this issue”. Notatki wydawnicze AhsayCBS v10.3.4 z 5 sierpnia 2026 nie wymieniają ani jednej poprawki bezpieczeństwa — są tam wsparcie dla Debiana 12.15 i 13.6 oraz błędy w backupie Microsoft 365 i Proxmox VE. Administrator, który 5 października przeczytał bazę podatności, podniósł wersję do 10.3.4 i odhaczył pozycję na liście, ma dokument potwierdzający, że zrobił wszystko dobrze. I ma niezałatany serwer.
Pełne usunięcie obu podatności dają dopiero hotfiksy v10.3.4.45 i v9.15.2.70, każdy z wymaganym restartem serwera. Numer wersji w czterech członach różni się od numeru z bazy podatności o jeden człon — i o całą różnicę między systemem podatnym a załatanym.
Warto zestawić dwie daty. Exploit był publiczny 4 października, bo tak odnotowała go baza podatności w dniu publikacji obu wpisów. Działający hotfix dla wersji 10 pojawił się 10 października, dla wersji 9 — 12 października. To sześć i osiem dni, w których kod ataku był dostępny, a skuteczna poprawka nie istniała, przy czym przez większość tego okresu istniała poprawka pozorna. Pierwsze zgłoszenia włamań od partnerów przyszły 9 października, czyli w piątym dniu tego okna. Kolejność zdarzeń nie pozostawia wątpliwości, co się stało: ktoś wziął publiczny exploit i przeszedł nim po serwerach, które według bazy podatności były już załatane.
Cztery objawy, po których poznasz, że jest już za późno
Instrukcja producenta z 13 października wymienia wskaźniki kompromitacji konkretniej niż niejedno advisory: katalogi o nazwach typu ahsay_ts, ahsay_t8, ahsay_t20, srv, user, opt utworzone w katalogu głównym dysków; pliki .jsp o losowych nazwach (przykład producenta: 75bc584d292933ad.jsp) oraz katalogi o losowych nazwach w %CBS%\webapps; nieautoryzowani odbiorcy replikacji RPS; nieautoryzowane konta z uprawnieniami typu Admin.
Czyta się to jednoznacznie: webshell w katalogu aplikacji, konto administracyjne do powrotu i replikacja przestawiona na cudzy serwer. Ten ostatni punkt jest najcięższy, bo RPS służy do kopiowania danych na inny serwer. Nie mówimy więc wyłącznie o zaszyfrowaniu kopii. Mówimy o ich wyniesieniu.
Zalecenie naprawcze producenta brzmi: pełna przebudowa serwera — reinstalacja Windows albo Linuksa, świeża instalacja CBS z hotfiksem, odtworzenie konfiguracji z Auto Save w wersji sprzed kompromitacji, najlepiej z dnia poprzedzającego pojawienie się podejrzanych katalogów. Dostawca oprogramowania do odtwarzania danych mówi wprost, że własnego serwera nie da się wyczyścić. To uczciwa rekomendacja i jednocześnie najkosztowniejsza z możliwych.
Hotfix za loginem partnera
Obie poprawki leżą na stronach oznaczonych jako „partner only”, z adnotacją, że wymagane jest ważne konto w portalu partnerskim. Z punktu widzenia producenta to naturalne — klientem jest partner. Z punktu widzenia organizacji, która kupiła backup jako usługę, oznacza to, że nie ma żadnego sposobu, by samodzielnie sprawdzić, czy jej kopie leżą na załatanym serwerze. Nie zna wersji, nie ma dostępu do hotfiksu, nie zobaczy listy kont Admin.
To jest dokładnie ta zależność, którą NIS2 i nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa opisują jako ryzyko w łańcuchu dostaw: odpowiedzialność za bezpieczeństwo usługi zostaje przy podmiocie, który ją kupił, a techniczna możliwość weryfikacji — po stronie dostawcy. Jedynym narzędziem, jakie tu zostaje, jest pytanie zadane na piśmie i udokumentowana odpowiedź.
Co z tego wynika dla polskiej organizacji?
- Jeżeli kupujesz backup jako usługę, wyślij dostawcy jedno pytanie mailem: jaką wersję konsoli backupowej prowadzi, czy zastosował hotfix v10.3.4.45 lub v9.15.2.70 (albo odpowiednik u innego producenta) i w którym dniu. Brak odpowiedzi w ciągu 48 godzin też jest odpowiedzią i też warto go zapisać.
- Jeżeli AhsayCBS stoi u ciebie, najpierw szukaj śladów, potem łataj. Sprawdź katalogi główne wszystkich dysków pod kątem folderów ahsay_t*, zawartość %CBS%\webapps pod kątem plików .jsp o losowych nazwach, listę odbiorców replikacji RPS i listę kont z uprawnieniami Admin. Hotfix nałożony na przejęty serwer usuwa podatność, a nie webshella.
- Sprawdź, czy masz choć jedną kopię poza platformą dostawcy — na innym mechanizmie i na innych poświadczeniach. Najprostszy wariant dla środowisk z Microsoftem opisuje instrukcja backupu plików w Recovery Services vault. Nie dlatego, że akurat Azure. Dlatego, że jedna konsola z dostępem do wszystkich kopii jest pojedynczym punktem awarii niezależnie od tego, czyje logo ma w nagłówku.
Siedem lat i ta sama klasa błędu
Baza NVD zna dziewięć podatności tego producenta. W lipcu 2019 opublikowano CVE-2019-10267 — niezabezpieczone wgrywanie plików prowadzące do wykonania kodu w Ahsay Cloud Backup Suite 8.1.0.50. W styczniu 2020 doszło CVE-2020-5846: niezabezpieczone wgrywanie plików prowadzące do wykonania kodu, ocena 8.8. W październiku 2026 mamy nieuwierzytelnione wstrzyknięcie polecenia systemowego z oceną 10.0 i webshelle .jsp w katalogu aplikacji.
To nie jest teza, że producent jest gorszy od innych. To obserwacja, że w tym konkretnym produkcie ta sama klasa błędu — obca treść trafiająca na dysk serwera przez interfejs sieciowy — nie została wyeliminowana przez siedem lat, mimo że przeszła przez cały cykl: zgłoszenie, łatka, kolejna wersja główna. A konsekwencja jest tu cięższa niż gdziekolwiek indziej, bo ten jeden serwer z definicji trzyma kopię wszystkiego, co w organizacji ma wartość.
Kopia zapasowa jest ostatnią linią obrony tylko wtedy, gdy stoi za nią coś więcej niż zaufanie do numeru wersji. Konsola backupu z panelem wystawionym do sieci, hotfiksem dostępnym wyłącznie dla partnera i siedmioletnią historią tej samej klasy błędu nie jest ostatnią linią. Jest najkrótszą drogą do wszystkich danych naraz.