Atak na łańcuch dostaw oprogramowania nie musi zaczynać się od luki w kodzie ani przejęcia całej infrastruktury producenta. Czasem wystarczy dostęp do konta jednego współpracownika i możliwość podmiany plików, którym użytkownicy ufają. 19 października 2026 roku cyberprzestępcy wykorzystali właśnie taki scenariusz, przejmując pięć wydań oficjalnego narzędzia OVHcloud CLI. Złośliwe pliki miały służyć do kradzieży poufnych informacji zapisanych na komputerach administratorów i programistów. Choć zagrożone wersje były dostępne przez stosunkowo krótki czas, incydent pokazał, jak łatwo można ominąć nawet rozbudowane zabezpieczenia procesu wytwarzania oprogramowania.

Autor: 11 min czytania

Pięć wersji narzędzia zamienionych w pułapkę

OVHcloud CLI to narzędzie wiersza poleceń umożliwiające administratorom i programistom zarządzanie usługami chmurowymi oraz hostingowymi bezpośrednio z terminala. Jest wykorzystywane między innymi do automatyzacji operacji, zarządzania zasobami i wykonywania zadań administracyjnych.

Według informacji opublikowanych przez OVHcloud oraz analizujących incydent badaczy atakujący podmienili pliki binarne pięciu wydań, od v0.11.0 do v0.15.0. Zmiany objęły istniejące już publikacje w oficjalnym repozytorium projektu na GitHubie. Zamiast oczekiwanych programów użytkownicy mogli pobrać zmodyfikowane wersje, przygotowane z myślą o wykradaniu sekretów z dysku.

Złośliwe pliki były dostępne 19 października przez około 94 minuty, od 12:47 do 14:21 UTC. Wykrycie incydentu było możliwe dzięki użytkownikowi, którego zadanie CI zaczęło zgłaszać błędy podczas pobierania programu. Przyczyną była niezgodność sumy kontrolnej SHA-256 z wcześniej ustaloną wartością.

To istotny szczegół – atak nie został wykryty wyłącznie dzięki mechanizmom bezpieczeństwa producenta. Zadziałała kontrola integralności wdrożona po stronie odbiorcy oprogramowania.

Przejęte konto zamiast ataku na cały proces CI/CD

Z dostępnych ustaleń wynika, że napastnicy wykorzystali przejęte konto GitHub współpracownika projektu, który miał możliwość publikowania plików w wydaniach. Następnie za pomocą standardowych mechanizmów GitHuba zastąpili archiwa dołączone do wcześniej opublikowanych wersji.

Atakujący nie musieli zmieniać kodu źródłowego w repozytorium ani modyfikować tagów wskazujących konkretne wydania. Nie uruchomiono również firmowego procesu CI/CD odpowiedzialnego za budowanie i testowanie oprogramowania. Złośliwe pliki zostały przygotowane poza tym procesem i przesłane bezpośrednio do istniejących publikacji.

Właśnie to odróżnia ten incydent od wielu klasycznych ataków na łańcuch dostaw. Organizacja może mieć testy jednostkowe, skanowanie podatności i automatyczne kontrole jakości, ale jeśli gotowe pliki można podmienić już po zakończeniu tych kontroli, zabezpieczenia nie obejmują całego cyklu życia oprogramowania.

Dodatkowym problemem był brak włączonej funkcji niezmienności wydań GitHub. Bez niej uprawniony użytkownik może zastąpić pliki dołączone do istniejącej publikacji, nie zmieniając przy tym jej adresu pobierania. Dla odbiorcy oznacza to, że znany i wcześniej zaufany link nie musi prowadzić do tych samych bajtów co wcześniej.

Jakie dane mogły zostać wykradzione?

Głównym celem złośliwego programu było pozyskanie sekretów dostępnych na komputerze, na którym został uruchomiony. W przypadku administratorów i inżynierów DevOps konsekwencje mogły być szczególnie poważne.

Narzędzia administracyjne często korzystają z kluczy API, tokenów dostępowych, danych uwierzytelniających i zmiennych środowiskowych. W środowiskach deweloperskich na dysku mogą znajdować się także poświadczenia do repozytoriów, systemów CI/CD, rejestrów kontenerów i innych usług chmurowych.

W przypadku OVHcloud CLI dokumentacja wskazuje między innymi plik ~/.ovh.conf jako miejsce przechowywania danych dostępowych. Program odczytuje również poświadczenia przekazywane przez zmienne środowiskowe.

Jeżeli zostaje uruchomiony złośliwy plik, potencjalne zagrożenie nie ogranicza się więc do pojedynczego konta OVHcloud. Ryzyko zależy od tego, do jakich zasobów ma dostęp dany użytkownik i jakie sekrety są zapisane na jego komputerze.

Na moment publikacji analizowanych doniesień OVHcloud nie ujawniło pełnego zakresu odczytywanych danych, miejsca ich przesyłania ani liczby pobrań złośliwych plików. Nie opublikowano również kompletnej analizy samego ładunku. Nie można zatem przesądzać, które konkretnie dane zostały faktycznie skradzione.

Kto był narażony na atak?

Zagrożenie dotyczyło określonych sposobów instalacji oraz architektur sprzętowych. Podmienione archiwa obejmowały macOS na procesorach Intel i Apple Silicon, Linuksa w wersjach x86-64 i ARM64 oraz Windows x86-64.

Ryzyko dotyczyło przede wszystkim osób, które w czasie incydentu pobrały archiwum bezpośrednio ze strony wydań GitHub, użyły oficjalnego skryptu instalacyjnego albo uruchomiły proces automatyzacji pobierający plik bez przypiętej sumy kontrolnej. Zagrożenie mogło również objąć użytkowników aktualizujących CLI z poziomu samego narzędzia, jeżeli mechanizm aktualizacji nie weryfikował integralności pobieranego archiwum.

Nie wszystkie kanały dystrybucji były jednak podatne. Według opublikowanych ustaleń instalacja przez Homebrew była chroniona dzięki przypiętym sumom SHA-256, a budowanie programu ze źródeł i użycie dostępnego obrazu Dockera nie zostały objęte incydentem.

OVHcloud wskazało wersję v0.10.0 jako niezainfekowaną, a następnie opublikowało czyste wydanie v0.16.0. Nowa wersja została wydana z włączoną ochroną niezmienności.

GlassWorm w tle incydentu

Badacze z OpenSourceMalware powiązali przejęte konto z wcześniejszą aktywnością, przypisywaną kampanii GlassWorm. Według ich analizy konto wykazywało oznaki kompromitacji już kilka miesięcy przed październikowym incydentem. W publicznych repozytoriach znaleziono zmiany historii Git oraz ukryty mechanizm ładowania kodu, powiązany z wcześniejszymi technikami tej kampanii.

GlassWorm opisywany był w kontekście ataków na ekosystemy programistyczne, w których zaufane konta i repozytoria służyły do rozpowszechniania złośliwego kodu.

Należy jednak zachować ostrożność w przypisywaniu odpowiedzialności. Zbieżność konta i wcześniejszych wskaźników zagrożenia stanowi podstawę do dalszego dochodzenia, ale nie dowodzi sama w sobie, że za wszystkie powiązane działania odpowiada dokładnie ten sam operator. Badacze zaznaczyli również, że nie byli w stanie przeanalizować usuniętego złośliwego pliku binarnego.

Jak zabezpieczyć środowisko po incydencie?

Osoby, które pobrały i uruchomiły podejrzaną wersję OVHcloud CLI, powinny potraktować dostępne na tym komputerze sekrety jako potencjalnie ujawnione. Samo zainstalowanie poprawnej wersji nie wystarczy, ponieważ nie unieważnia poświadczeń, które mogły zostać wcześniej skopiowane.

Zalecane działania obejmują:

  • Unieważnienie i rotację sekretów – należy zmienić klucze API, tokeny, hasła aplikacyjne i inne dane uwierzytelniające, które mogły być dostępne dla złośliwego programu.
  • Wykonanie operacji z zaufanego urządzenia – rotację poświadczeń należy przeprowadzić z komputera, który nie był narażony na działanie podejrzanego pliku.
  • Usunięcie zagrożonego programu – należy zastąpić go zweryfikowanym wydaniem v0.16.0 lub późniejszym, po sprawdzeniu jego autentyczności.
  • Weryfikację aktywności na kontach – warto przejrzeć logi API, historię logowań, zmiany konfiguracji, nowe klucze oraz nietypowe operacje wykonywane z użyciem dotychczasowych poświadczeń.
  • Sprawdzenie pipeline’ów – jeżeli narzędzie było wykorzystywane w CI/CD, trzeba ustalić, czy podczas incydentu pobrano lub uruchomiono podmieniony plik.

Organizacje powinny również ustalić, czy potencjalnie ujawnione klucze dawały dostęp do innych systemów. W przypadku szerokich uprawnień jednego tokenu incydent może wymagać szerszej analizy niż tylko sprawdzenie konta dostawcy chmurowego.

Sumy kontrolne i niezmienne wydania jako linia obrony

Jednym z najważniejszych wniosków z ataku jest konieczność niezależnej weryfikacji pobieranego oprogramowania. Sumy SHA-256 powinny być przypięte do zaufanej wartości, ustalonej poza kanałem, który może zostać naruszony. Sam plik checksums.txt pobrany z tego samego miejsca co archiwum nie zapewnia wystarczającej ochrony, jeśli napastnik może podmienić oba pliki.

Istotne jest także korzystanie z podpisów cyfrowych i poświadczeń pochodzenia artefaktów, które pozwalają zweryfikować, kto i w jaki sposób przygotował konkretną wersję programu. Warto również przypinać wersje zależności i narzędzi w automatyzacji, zamiast pobierać nieokreślone „najnowsze wydanie”.

Po stronie producentów ważną rolę odgrywają niezmienne wydania. Funkcja GitHub Immutable Releases blokuje modyfikowanie i usuwanie plików oraz tagów po publikacji, a także generuje poświadczenie pozwalające weryfikować zawartość wydania. OVHcloud poinformowało o włączeniu tej ochrony po incydencie.

Nie zastępuje ona wszystkich mechanizmów bezpieczeństwa, ale zamyka istotną lukę –  możliwość cichej podmiany pliku pod niezmienionym adresem.

Wnioski? Zaufanie do dostawcy nie zastępuje weryfikacji

Incydent OVHcloud pokazuje, że bezpieczeństwo oprogramowania nie kończy się na kontroli kodu źródłowego ani poprawnie działającym procesie CI/CD. Równie ważne jest zabezpieczenie kont publikujących, ochrona gotowych artefaktów i weryfikacja ich integralności po stronie odbiorcy.

Dla firm korzystających z chmury to przypomnienie, że narzędzia administracyjne są szczególnie atrakcyjnym celem. Uruchamiane z uprawnieniami administratora mogą mieć dostęp do danych, tokenów i kluczy, które otwierają drogę do wielu kolejnych systemów.

Dlatego organizacje powinny traktować dystrybucję narzędzi deweloperskich i administracyjnych jako część własnej powierzchni ataku. Przypinanie wersji, niezależna weryfikacja sum kontrolnych, rotacja sekretów oraz niezmienne wydania nie są już wyłącznie dobrymi praktykami. To podstawowe elementy obrony przed atakami na łańcuch dostaw oprogramowania.