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

Именно так, по данным Acronis Threat Research Unit, действовала группа Red Heron. Она атаковала интернет-доступные инсталляции Gitea и, по оценке исследователей, затронула 13 организаций в шести странах.

Что произошло

Исследователи связали Red Heron с быстрой эксплуатацией свежей уязвимости CVE-2026-60004 в Gitea — платформе для хостинга исходного кода. В отчете сказано, что злоумышленники сканировали 1386 экземпляров Gitea в семи странах и отдельно вели базу из 477 систем, связанных с Тайванем.

В результате атак пострадали организации в Канаде, Аргентине, Тайване, США, Катаре и Шри-Ланке. Среди затронутых отраслей — оборона, выборы, энергетика, аэрокосмос, телеком, госструктуры, общественная безопасность и наука.

Как шла атака

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

По словам исследователей, уже через несколько дней после раскрытия дыры Red Heron превратила proof-of-concept-код в Python-скрипт exp_enhanced.py. Это позволило быстро обрабатывать множество целей без ручной работы.

Дальше атака часто шла по цепочке: доступ к Gitea — кража репозиториев — сбор логинов, токенов и ключей — закрепление в сети — боковое перемещение. В одной из тайваньских сред злоумышленники, по данным отчета, дошли до root-доступа в трехузловом кластере Proxmox.

На сервере подготовки исследователи нашли и вредоносный Linux-имплант JITTERLY с более чем 30 командами для запуска шелла, передачи файлов, удаления процессов, сетевого туннелирования и интерактивной работы. Внутри также обнаружили rootkit SIXZUT, который прячет файлы, процессы и сетевые соединения, а еще умеет запускаться снова после удаления.

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

Кого задело и чем это грозит

По данным Acronis TRU, среди жертв оказались компании из самых чувствительных секторов. В Тайване атакующие, по словам исследователей, выкачали сотни репозиториев, связанных с SCADA/HMI-инструментами, IoT-интеграциями, сетевым сниффером, серверными конфигурациями и внутренними бизнес-приложениями.

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

Главный риск здесь даже не в самом исходном коде. Когда в руки атакующих попадают репозитории и секреты, они получают карту внутренней сети, точки входа в другие сервисы и ключи к дальнейшему проникновению. В такой ситуации один скомпрометированный сервер разработки может потянуть за собой целую инфраструктуру.

Отдельный вывод для бизнеса прост: self-hosted-платформы для кода, особенно с открытым доступом из интернета, нужно считать критичным активом, а не вспомогательным сервисом. И проверять их надо так же регулярно, как почту, шлюзы и удаленный доступ. Если сотрудники работают из кафе, аэропортов или поездов, для защиты приватности стоит заранее продумать подключение через сторонний защищенный маршрут как дополнительную меру, но не вместо базовой гигиены безопасности.

Что делать сейчас

Если у вас есть свой Gitea или любая похожая система для хранения исходников, не откладывайте проверку. Сначала ищите свежие обновления, потом пересматривайте права доступа и секреты, а затем проверяйте журналы на странные регистрации, массовые запросы и неизвестные IP-адреса.

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

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

Проверить, есть ли у вас интернет-доступные инсталляции Gitea или похожих платформ.
Обновить систему и закрыть известные уязвимости.
Сменить секреты, токены, SSH-ключи и пароли, если они могли лежать в репозиториях.
Посмотреть логи на массовые регистрации, необычные скачивания и боковое перемещение.
Ограничить доступ к системам разработки по IP, если это допустимо для вашей инфраструктуры.
Включить двухфакторную проверку для учетных записей администраторов.
Хранить конфигурации и секреты отдельно от исходного кода.
Для рабочих сессий в общественных сетях заранее настроить дополнительный уровень защиты трафика как опцию приватности.