Атака на Coder длилась 14 часов 10 минут: с 07:35 до 21:45 UTC 31 августа 2026 года злоумышленники раздавали через реестр проекта вредоносные Terraform-модули, которые вытягивали ключи, токены и другие секреты из инфраструктуры. Для русскоязычной IT-аудитории здесь важен не только сам инцидент, но и его механика: компрометация не бэкэнда приложения, а внешней сетевой обвязки привела к тому, что разработчики получали «правильные» артефакты с «неправильных» серверов.
Речь идет о платформе Coder, которую используют компании и госструктуры для разворачивания self-hosted облачных сред разработки, в том числе для сборки и деплоя AI-приложений. Как пишет BleepingComputer, атакующие получили доступ к инфраструктуре Coder в Cloudflare и добавили в пул реестра несанкционированные IP-адреса. После этого часть запросов к registry.coder.com Cloudflare направлял не на легитимные узлы Coder, а на серверы злоумышленников. Снаружи это выглядело почти как штатная работа сервиса, но пользователи скачивали уже подмененные модули.
По данным Coder, вредоносные артефакты были модифицированными Terraform-модулями для шаблонов рабочих окружений. В зараженной цепочке поставки они играли роль инфостилера: искали переменные окружения и секреты provisioner'а, ключи API для облаков и AI-инструментов, учетные данные CI/CD, секреты из конфигурационных файлов и истории терминала, пользовательские OIDC-токены, настроенные SSH-ключи, одноразовые токены внешней аутентификации, а в отдельных сценариях еще и пароли к базе данных Coder и другие конфигурационные секреты, если provisioner запускался внутри coderd. Украденные данные отправлялись на домен-двойник coder-infra[.]com.
Это и делает атаку на Coder особенно неприятной. Обычно, когда речь идет о supply chain-инциденте, команда безопасности первым делом проверяет собственные репозитории, подписи пакетов, историю сборок и CI-пайплайны. Здесь проблема сидела на другом уровне: злоумышленники не обязательно должны были ломать сам реестр как приложение, им хватило возможности встроить свои серверы в пул, откуда CDN и edge-инфраструктура начинали раздачу контента. Для инженеров это плохая новость, потому что привычная логика «скачали с официального домена, значит все в порядке» больше не работает без дополнительной верификации артефактов.
Что именно нужно проверять
Coder выпустил исправленные версии: 2.37.0, 2.36.4, 2.35.7 и 2.34.9. Но само обновление закрывает только дальнейшую доставку вредоносных модулей, а не последствия уже состоявшейся компрометации. Компания рекомендует потенциально затронутым пользователям как можно быстрее перевыпустить все секреты из списка выше. Отдельно советуют до обновления проверить firewall-, proxy-, DNS- и VPC flow-логи на обращения к coder-infra[.]com, изучить логи provisioner'а на наличие data.external.telemetry, определить, какие модули были загружены в окно атаки, и очистить локальные или прокси-кэши, где могли остаться вредоносные пакеты.
Это важный практический момент для команд, которые живут в Terraform и автоматизируют все подряд. Если модуль попал в кэш, проблема не заканчивается вместе с восстановлением реестра. Подмена может всплыть позже в новом окружении, во временном пайплайне или при повторном применении шаблона. Coder опубликовал SQL-запрос, который помогает найти потенциально затронутые кэшированные модули и версии шаблонов. Но даже при таком инструменте компания честно признает пределы своей видимости: поскольку атакующая инфраструктура находилась вне ее контроля, у Coder нет доступа к критическим журналам, а значит нельзя со стопроцентной уверенностью перечислить все скомпрометированные инсталляции.
Еще одна деталь, которая немного снижает градус паники, но не отменяет инцидент: refresh tokens, по словам Coder, не передавались provisioner'у, и признаков воздействия на клиентские данные, которые хранила сама компания, не обнаружено. Однако это не повод расслабляться. Для реальной атаки на бизнес злоумышленникам часто достаточно не базы клиентов, а набора рабочих секретов: облачный API-ключ, CI-токен, SSH-ключ к bastion-host, OIDC-токен разработчика. Дальше уже можно двигаться по инфраструктуре тихо и без лишнего шума, причем формально с валидными учетными данными.
Почему этот кейс шире одного вендора
История с Coder укладывается в заметный тренд 2025-2026 годов: атакующие все чаще бьют не в production-сервис как таковой, а в его каналы доставки доверенного кода. За последние месяцы рынок видел и подмены npm-пакетов, и вредоносные обновления, и атаки на сетевую маршрутизацию. Разница лишь в точке входа. Раньше разработчикам годами говорили о риске «не ставьте пакет с подозрительным названием», теперь приходится привыкать к другому сценарию: пакет может быть с правильным именем, с официального домена и в привычном workflow, но приехать не с того сервера.
Для российских и вообще русскоязычных команд это особенно актуально в двух случаях. Первый: компании, которые строят внутренние dev-платформы, golden templates и стандартизированные рабочие окружения для сотен инженеров. Там один зараженный модуль быстро масштабируется на весь парк. Второй: команды, которые активно завязаны на AI-инструменты и облачные интеграции. В списке интересов вредоносного кода отдельно фигурируют API-ключи AI-tooling, а значит ущерб может выйти далеко за рамки классического «утек секрет от AWS». Это может быть доступ к платным моделям, пайплайнам инференса, внутренним промпт-цепочкам и служебным интеграциям, где аудит доступа обычно слабее, чем у основной инфраструктуры.
У этого кейса есть и неприятный организационный вывод. Supply chain-защита больше не сводится к SCA-сканеру, запрету на случайные зависимости и периодическому аудиту lock-файлов. Если компания тянет модули, провайдеры, образы и шаблоны из внешних реестров, ей нужны не только allowlist'ы, но и контроль сетевого поведения артефактов, журналирование скачиваний, понятная стратегия очистки кэшей и механизм быстрой ротации секретов. Иначе каждая такая атака превращается в многочасовой квест по логам, где сложно даже ответить на базовый вопрос: кто именно скачал вредоносный модуль и что он успел сделать.
Атака на Coder вряд ли останется частным эпизодом из жизни одного devtools-вендора. Скорее это еще один сигнал, что доверие к инфраструктуре поставки кода теперь нужно строить послойно: домен, CDN, кэш, подписи, логи, поведение артефактов после запуска. Иначе следующая компрометация будет выглядеть не как громкий взлом, а как несколько часов «нормальной» работы, после которых у атакующего уже есть все нужные ключи.