OVHcloud: w GitHubie podmieniono CLI

Krótki, ale groźny incydent

OVHcloud poinformowało o naruszeniu bezpieczeństwa swojego oficjalnego narzędzia CLI służącego do zarządzania usługami firmy z poziomu terminala. Przez około 94 minuty w serwisie GitHub dostępne były podmienione binaria, które zamiast legalnej wersji zawierały element mający wykradać sekrety zapisane na dysku komputera.

Zdarzenie dotyczyło osób, które pobrały lub zaktualizowały narzędzie 19 października 2026 r. w oknie czasowym między publikacją złośliwych plików a ich usunięciem.

Co zostało zaatakowane

Chodzi o ovhcloud-cli, oficjalne narzędzie open source do obsługi usług OVHcloud, takich jak:

• VPS,
• Public Cloud,
• domeny,
• IAM,
• procesy uruchamiane w CI/CD.

Atak nie dotyczył infrastruktury budowania oprogramowania OVHcloud. Zmienione zostały same pliki udostępniane w repozytorium GitHub, czyli kanał dystrybucji pakietów.

Które wersje były skażone

Według przekazanych informacji problem dotyczył wersji:

• v0.11.0
• v0.12.0
• v0.13.0
• v0.14.0
• v0.15.0

Za czyste uznano v0.10.0 oraz późniejszą v0.16.0, opublikowaną już po incydencie. Właśnie ta nowsza wersja miała zostać zabezpieczona podpisanym tagiem i immutowalnym wydaniem.

Jak wykryto problem

Pierwszy sygnał przyszedł od użytkownika, którego pipeline CI porównał sumę SHA-256 pobieranej archiwum i wykrył, że plik nie zgadza się z oczekiwanym wzorcem. To ważny szczegół, bo złośliwa wersja nie tylko została wrzucona do repozytorium, ale też miała podmieniony plik checksums.txt, dzięki czemu ktoś sprawdzający sumę wyłącznie na stronie wydania mógłby niczego nie zauważyć.

Zmodyfikowane archiwa obejmowały różne platformy, w tym:

• Linux arm64 i x86_64,
• macOS arm64 i x86_64,
• Windows x86_64.

Co robił złośliwy plik

Z analiz wynika, że podmieniony binarny komponent był przygotowany do zbierania sekretów znajdujących się na dysku. Chodzi przede wszystkim o dane, które często trafiają na stacje administracyjne i do środowisk automatyzacji, na przykład:

• klucze API OVHcloud,
• pliki konfiguracyjne, w tym .ovh.conf,
• zmienne środowiskowe,
• klucze SSH,
• tokeny do innych usług chmurowych lub rejestrów pakietów,
• pliki kubeconfig i .env.

Jeśli ktoś uruchomił skażoną wersję, powinien założyć, że takie dane mogły zostać ujawnione.

Skąd wziął się problem

OVHcloud przekazało, że atakujący wykorzystał konto GitHub jednego z programistów projektu. Na tej podstawie podmieniono opublikowane wydania bez ingerencji w oficjalną ścieżkę kompilacji.

Jednym z istotnych ustaleń było również to, że w repozytorium nie była włączona opcja immutability releases. Po jej aktywowaniu kolejne wydania nie mogą być już swobodnie zmieniane, co znacząco utrudnia podobne nadużycia. W tym przypadku luka konfiguracji pozwoliła na edycję już opublikowanych paczek.

Czy wszyscy użytkownicy są zagrożeni

Nie każdy sposób instalacji oznaczał ryzyko. Z przekazanych informacji wynika, że zagrożenie dotyczyło przede wszystkim osób i systemów, które:

• pobrały binaria z GitHuba w krytycznym oknie czasowym,
• użyły oficjalnego skryptu instalacyjnego pobierającego archiwum bez weryfikacji skrótu,
• wykonały automatyczną aktualizację opartą na tym samym kanale dystrybucji.

Nie wskazano natomiast, by problem obejmował instalację przez go install albo budowanie bezpośrednio ze źródeł.

Co zrobić, jeśli użyto skażonej wersji

Najważniejsze działania to:

1. natychmiast zaktualizować CLI do bezpiecznej wersji,
2. usunąć skażoną kopię narzędzia,
3. zmienić wszystkie sekrety, które mogły znajdować się na urządzeniu w momencie uruchomienia.

W praktyce warto potraktować sprawę jak potencjalny incydent wycieku danych i odnowić wszystkie dostępy, które mogły być przejęte przez infostealer.

Dlaczego ten przypadek jest ważny

To kolejny przykład, że nawet oficjalne repozytorium projektu może zostać wykorzystane do dystrybucji złośliwego kodu, jeśli atakujący przejmie konto z odpowiednimi uprawnieniami albo znajdzie słaby punkt w mechanizmie publikowania wydań.

W środowiskach administracyjnych CLI ma często dostęp do wyjątkowo cennych danych. Dlatego każda taka podmiana jest szczególnie niebezpieczna — zwłaszcza gdy narzędzie trafia na maszyny z zapisanymi sekretami i szerokimi uprawnieniami.