Инфраструктура реестра модулей Coder оказалась скомпрометирована: 31 августа часть запросов к официальному registry.coder.com перенаправлялась на сервер злоумышленника. Он раздавал измененные модули с кодом для поиска и кражи облачных учетных данных и других секретов.
Атака продолжалась с 07:35 до 21:45 UTC, то есть чуть больше 14 часов. Coder обнаружила проблему в тот же день, удалила посторонние IP-адреса из инфраструктуры, очистила кеш реестра и проверила опубликованные модули. Компания сообщила, что ее кодовая база и инфраструктура в Google Cloud не были взломаны. Признаков доступа к данным клиентов, которые хранит сама Coder, также не обнаружено.
Опасность сохраняется для организаций, чьи установки Coder успели загрузить вредоносный модуль в период атаки. Измененная копия могла сохраниться в локальном кеше и использоваться после того, как реестр уже очистили.
Причиной инцидента стала компрометация API-ключа Cloudflare, который использовала Coder. Атакующий добавил собственные IP-адреса в пул серверов, обслуживающих реестр модулей. Из-за этого часть трафика registry.coder.com попадала на подконтрольный ему сервер.
В бюллетене безопасности Coder указано, что вредоносные артефакты распространялись только среди части пользователей. Точное число затронутых организаций компания определить не может: сервер, который обслуживал вредоносные запросы, принадлежал атакующему, и его журналы Coder недоступны.
Подмененные модули содержали код для поиска учетных данных и отправки найденной информации на сервер злоумышленника.
В одном из индикаторов атаки фигурирует блок Terraform data "external" "telemetry", запускавший файл dlp-docker.sh. Coder также обнаружила несколько вариантов скрипта dlp.sh.
Скрипты обращались к домену coder-infra[.]com, который внешне похож на название инфраструктуры Coder. Вредоносный адрес был зарегистрирован 28 августа, за три дня до атаки. Для передачи данных использовался URL http://www[.]coder-infra[.]com/cli/check. В запросах фигурировал HTTP-заголовок X-CLI-Token.
Основной целью были секреты, доступные процессу, который разворачивает рабочие окружения Coder. Компания отдельно упоминает ключи облачной инфраструктуры, инструменты ИИ, учетные данные CI/CD и другие секреты из переменных окружения, конфигурационных файлов и истории терминала.
Coder описывает два основных сценария выполнения вредоносного кода. Первый возникает при загрузке нового шаблона, обновлении его версии или пробном запуске изменений. В этом случае процесс развертывания еще не получает пользовательские секреты. Вредоносный модуль при этом мог прочитать переменные окружения и учетные данные самого provisioner — компонента, который создает и настраивает рабочую среду.
Больше данных было доступно во время сборки рабочего окружения. В этот момент provisioner может получить OIDC-токен пользователя, SSH-ключ, если такая возможность настроена, и одноразовые токены внешних систем авторизации, используемых конкретным шаблоном. Долговременные refresh-токены в этот набор не входили.
Отдельный риск есть у установок, где provisioner работает внутри процесса coderd, а не как отдельная служба. В такой конфигурации вредоносный код мог получить переменные конфигурации Coder, включая пароль базы данных и параметры внешних систем авторизации.
Сам факт использования Coder еще не означает компрометацию. В зону риска попадают установки, которые скачали модуль из Coder Registry с 07:35 до 21:45 UTC 31 августа. Чаще всего это происходит при создании нового шаблона или новой версии существующего шаблона.
Coder также советует проверить системы, где в этот промежуток запускали пробную сборку шаблона или создавали рабочее окружение при отключенном кешировании модулей. Кеширование включено по умолчанию, поэтому последний сценарий встречается реже.
Рабочие окружения, созданные из шаблона, который успел получить зараженный модуль, тоже могут быть затронуты.
Отключение чужого сервера не удаляет файлы, которые уже попали на машины клиентов. Coder предупреждает, что вредоносные модули могли сохраниться в кеше конкретной установки. Такой файл продолжит использоваться локально даже после восстановления нормальной работы registry.coder.com. Поэтому администраторам потенциально затронутых систем недостаточно проверить, работает ли сейчас официальный реестр.
Компания опубликовала SQL-запросы, которые позволяют найти модули, загруженные во время атаки, связанные с ними шаблоны и рабочие окружения. Еще один запрос ищет в журналах provisioner строку data.external.telemetry — один из индикаторов вредоносного кода. Отдельный запрос удаляет из кеша модули, полученные в проблемный промежуток.
Coder рекомендует проверить журналы межсетевых экранов, DNS, прокси-серверов и VPC Flow Logs на исходящие подключения к coder-infra[.]com.
В опубликованном списке индикаторов компрометации также указан IP-адрес:
199.91.220[.]205
Для файлаdlp-docker.sh компания приводит SHA-256:
7190a17c593276d7fd71c4863a4bc0b6c957ed14249288e6f64c5540e2c49398
Coder опубликовала контрольные суммы еще для пяти вариантов dlp.sh, связанных с общим модулем и модулями aider, rstudio-server, windows-rdp и zed. Полный список находится в официальном бюллетене GHSA-vx42-ghc9-gw65.
Найденное обращение к вредоносному домену — серьезный признак возможной компрометации. Отсутствие такой записи не позволяет автоматически считать систему безопасной: нужные журналы могли не сохраниться.
После проверки и очистки кеша Coder рекомендует обновить платформу до исправленной версии.
Бюллетень имеет критический рейтинг 9,0 из 10 по CVSS 4.0. В нем версии ниже 2.37.0 указаны как затронутые, а исправления перечислены для веток 2.37, 2.36, 2.35 и 2.34: это версии 2.37.0, 2.36.4, 2.35.7 и 2.34.9. Отдельного CVE для инцидента не опубликовано.
Организациям, где вредоносный модуль мог выполниться, компания советует заменить все потенциально доступные ему учетные данные. В первую очередь это ключи облачной инфраструктуры, секреты инструментов ИИ, учетные данные CI/CD и другие токены, доступные provisioner через переменные окружения, конфигурацию или историю терминала.
Если зараженный код запускался во время сборки рабочего окружения, при расследовании нужно также учитывать OIDC-токены, SSH-ключи и одноразовые токены внешних систем авторизации.
Вопросы и ответы
Что произошло с Coder?
31 августа злоумышленник получил доступ к API-ключу Cloudflare и добавил свои серверы в инфраструктуру, обслуживающую registry.coder.com. Часть запросов к реестру получила измененные модули с кодом для поиска и отправки секретов.
Взломали ли исходный код Coder?
Coder не обнаружила признаков компрометации своей кодовой базы или инфраструктуры в Google Cloud. Атака затронула инфраструктуру доставки модулей.
Когда распространялись вредоносные модули?
С 07:35 до 21:45 UTC 31 августа 2026 года.
Какие данные могли попасть к злоумышленнику?
Это зависит от конфигурации и момента выполнения модуля. Потенциально доступны облачные API-ключи, учетные данные CI/CD, секреты инструментов ИИ, переменные окружения, OIDC-токены, SSH-ключи и одноразовые токены внешней авторизации. В некоторых конфигурациях под угрозой могли оказаться пароль базы данных Coder и другие параметры coderd.
Пострадали ли все пользователи Coder?
Нет. В первую очередь нужно проверять установки, скачивавшие модуль из основного реестра во время 14-часового окна атаки.
Известно ли число пострадавших?
Нет. Coder не может точно определить всех получателей вредоносных файлов, поскольку сервер злоумышленника находился вне инфраструктуры компании.
Достаточно ли обновить Coder?
Нет, если установка могла скачать зараженный модуль. Сначала следует проверить и удалить подозрительные файлы из кеша. Если вредоносный код выполнялся, потенциально раскрытые учетные данные нужно заменить.
Какие версии содержат исправления?
Coder перечисляет версии 2.37.0, 2.36.4, 2.35.7 и 2.34.9.
Есть ли CVE?
На момент публикации для инцидента CVE не указан. Coder выпустила собственный бюллетень GHSA-vx42-ghc9-gw65 с критической оценкой 9,0 по CVSS 4.0.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
