Злоумышленник подменил бинарные файлы в выпусках OVHcloud CLI

19 октября 2026 года злоумышленник, использовавший скомпрометированную учётную запись GitHub HassenBF, подменил бинарные файлы в выпусках OVHcloud CLI с v0.11.0 по v0.15.0. Активность продолжалась около 94 минут: за это время файлы загрузили примерно 250 раз, затем ресурсы удалили.

Как подменили выпуски OVHcloud CLI

Злоумышленник не менял исходный код, теги и рабочие процессы CI. Он загрузил в выпуски бинарные файлы, собранные локально, а затем заменил файл checksums.txt, чтобы опубликованные хеши совпадали с вредоносными файлами. Для сборки использовали коммит 5ead8ef, обычный коммит основной ветки от 13 октября, и локальные флаги go build -ldflags="-s -w". Стандартный ldflag версии в сборку не включили.

Команда ovhcloud version показывала значение undefined и хеш коммита злоумышленника. Команда ovhcloud upgrade распознавала бинарный файл как сборку для разработки.

Полезная нагрузка и затронутые установки

Вредоносная полезная нагрузка искала данные в следующих хранилищах и файлах:

• учётные данные ИИ-агентов;
• учётные данные облачных и контейнерных сред;
• данные Terraform и NPM;
• ключи SSH;
• файлы .netrc и .gitconfig;
• конфигурации Docker и Kubernetes и связанные с ними секреты.

Собранные данные сохранялись в постоянных каталогах /tmp/envchecker-*, а затем выгружались в виде архива на адрес 45.32.148.174/upload. Для передачи использовались JSON-запросы, имитирующие формат Solana-RPC.

Первичная компрометация учётной записи была связана с вредоносным ПО GlassWorm, доставленным через вредоносное расширение для VS Code, установленное в октябре 2025 года. Восстановленный загрузчик использовал JavaScript, закодированный с помощью селекторов вариантов, и обёртку AES-256-CBC. Он выполнял региональные и временные проверки, опрашивал транзакции Solana для получения командных данных, загружал зашифрованную полезную нагрузку второго этапа и запускал её в виртуальной машине Node.js с неограниченным доступом к функции require.

Точка передачи данных в Solana во время анализа была неактивна, но потенциально могла быть реактивирована новой транзакцией с примечанием memo. Затронутые способы установки включали прямую загрузку для macOS, Linux x86_64 и Windows x86_64, ручную загрузку и команду ovhcloud upgrade.

Пользователи Linux arm64, которые устанавливали CLI только с помощью install.sh, не подвергались риску: скрипт запрашивал артефакт aarch64, тогда как в выпусках использовалось обозначение Linux_arm64. Пользователи arm64, применявшие обновление или ручную загрузку, могли быть затронуты. Установки через Homebrew были защищены закреплёнными хешами, поэтому подменённые бинарные файлы отклонялись.

Рекомендации по восстановлению

Авторы отчёта рекомендуют считать затронутые системы скомпрометированными и выполнить следующие действия:

• отозвать и заменить все доступные учётные данные и токены, используя отдельное устройство;
• удалить подозрительные каталоги для промежуточного хранения;
• пересобрать хост, если целостность системы нельзя подтвердить;
• при переустановке использовать чистый, проверенный выпуск v0.16.0.

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.