19 октября 2026 года злоумышленники подменили пять релизов OVHcloud CLI и успели раздать вредоносные архивы примерно за полтора часа. Сборка выглядела как обычное обновление, но внутри был стилер, который искал секреты на диске и отправлял их на сервер атакующих.

Этот случай хорошо показывает, почему опасны не только фишинг и заражённые вложения, но и атаки на цепочку поставки. Когда человек или автоматизация ставят инструмент из доверенного источника, проверяют не всё подряд — и на этом играют злоумышленники. Похожая логика уже встречалась в разборе атак на сайты через автономных ИИ-агентов: компрометация одного звена быстро превращается в проблему для сотен систем.

Что произошло с OVHcloud CLI

OVHcloud предупредила о подмене архивов версий с 0.11.0 по 0.15.0. Злоумышленники получили доступ к GitHub-аккаунту одного из контрибьюторов и загрузили в уже опубликованные релизы свои файлы вместо оригинальных.

Под удар попали сборки для macOS, Linux и Windows. Для версии 0.15.0 атакующие ещё и заменили файл с контрольными суммами, так что проверка по опубликованным хешам не спасала — они уже вели к вредоносным архивам.

Как работала атака

Схема была довольно грязной, но эффективной. Атакующие локально собрали вредоносную версию из более позднего коммита, затем подменили архивы в старых релизах и спрятали следы в уже существующей истории публикаций.

Главная проблема таких атак — доверие к обновлению как к рутинной операции. Пользователь видит знакомый инструмент, знакомую страницу релизов и часто не перепроверяет, что именно скачивает. Если автоматизация тянет архив напрямую в CI, риск только растёт.

Здесь помогает только дисциплина: проверка контрольных сумм, подписи релизов, закрепление версий и отказ от слепого обновления по первой доступной ссылке. В корпоративной среде это должно быть не рекомендацией, а стандартом.

Почему это опасно

Вредоносная сборка искала широкий набор секретов: SSH-ключи, конфигурации AWS, Google Cloud, Azure, Docker, Kubernetes и Terraform, а ещё данные из сред разработки. Всё найденное архивировалось и уходило на сервер злоумышленников.

Это опасно не только для разработчиков. Один скомпрометированный рабочий ноутбук может открыть доступ к облаку, контейнерам, тестовым стендам и внутренним репозиториям. Если на машине лежат токены доступа или ключи к инфраструктуре, атакующие получают не один аккаунт, а целую систему.

Подобные инциденты отлично сочетаются с кражей учётных данных, которую злоумышленники часто запускают через расширения браузера, поддельные обновления или заражённые утилиты. Для компаний это означает не только простой, но и риск повторного входа атакующих через украденные ключи.

Как понять, что это может касаться вас

Риск есть у тех, кто в тот промежуток времени ставил или обновлял OVHcloud CLI через релизы GitHub, официальный скрипт или CI без проверки SHA-256. Отдельно стоит проверить машины, где инструмент обновлялся встроенным механизмом — он тоже мог скачать подменённый архив.

Если вы ставили CLI через Homebrew, собирали из исходников или использовали Docker-образы, угроза была ниже: там проверка целостности сработала. Но и в этом случае полезно пересмотреть журналы, токены и недавние изменения в доступах.

Особенно внимательно стоит отнестись к рабочим станциям разработчиков и серверным учёткам, где могли лежать облачные ключи, SSH-агенты или конфигурации Kubernetes. Для таких систем разумно провести инвентаризацию секретов и сменить чувствительные токены.

Что делать прямо сейчас

Если вы используете подобные CLI-инструменты, проверьте источник установки, версии релизов и историю обновлений. Затем смените все секреты, которые могли храниться на машине или в окружении CI.

Для шифрования трафика на личных устройствах и особенно при работе через открытые точки доступа можно использовать платформу Freedome, но она не заменяет проверку релизов, подписи и контрольные суммы. Сама по себе защита канала не спасёт, если на устройство уже попал стилер.

Полезно также держать в голове базовое правило: доверять не имени файла, а его происхождению. Если релиз выглядит обычным, это ещё не значит, что он безопасен.

Практический чек-лист

  • Проверьте, ставили ли вы OVHcloud CLI 19 октября 2026 года или обновляли его в этот день.
  • Сравните версии, которые есть на ваших рабочих станциях и в CI, с теми, что вы ожидали увидеть.
  • Смените SSH-ключи, облачные токены, Docker- и Kubernetes-секреты, если они могли храниться на затронутой машине.
  • Проверьте журналы загрузок и запусков на предмет подозрительных архивов и неожиданных обновлений.
  • Включите проверку контрольных сумм и подписей релизов для всех рабочих утилит.
  • Ограничьте права учёток, от имени которых запускаются сборки и автоматические обновления.
  • Пересмотрите, какие секреты лежат на ноутбуках разработчиков и в переменных окружения CI.
  • Если у вас есть публичные точки доступа в офисе или дома, не полагайтесь на них как на безопасную среду.
Поделиться: