JetBrains признала неприятное для любого вендора DevTools: уязвимость TeamCity, о которой компания сама предупредила клиентов 27 июля 2026 года, осталась незакрытой на ее собственном сервере. В итоге под удар попал Cadence, облачный сервис JetBrains для запуска проектов из PyCharm, а пользователям теперь советуют срочно перевыпускать секреты и считать прошлые выполнения недоверенными. Для русскоязычной IT-аудитории здесь важен не столько сам конфуз бренда, сколько знакомый вывод: CI/CD и удаленный рантайм с доступом к репозиториям, облакам и пакетным registry давно стали целью уровня supply chain.
Об инциденте сообщает The New Stack со ссылкой на раскрытие JetBrains. По данным компании, злоумышленники эксплуатировали сервер api.cadence.jetbrains.com, который стоял за Cadence и использовал TeamCity для оркестрации задач. Атаку обнаружили 23 августа, на следующий день сервер отключили, а сам затронутый период JetBrains обозначила довольно жестко: с 8 по 24 августа 2026 года. Особенно неприятно выглядит таймлайн. 27 июля JetBrains опубликовала advisory по CVE-2026-63077, а 7 августа отдельно предупредила, что непропатченные инсталляции TeamCity уже атакуют. И все же один уязвимый сервер оставался у самой JetBrains.
Суть CVE-2026-63077 для инфраструктурных команд понятна без маркетинговых украшений: это критическая RCE-уязвимость в TeamCity On-Premises, позволяющая неаутентифицированному атакующему выполнять команды на сервере через HTTP(S). JetBrains исправила проблему в версиях TeamCity 2025.11.7 и 2026.1.3, а тем, кто не мог обновиться, выпустила security patch plugin. В раннем advisory компания отдельно подчеркивала, что облачным клиентам TeamCity ничего делать не нужно, потому что нужные меры уже применены. Теперь выяснилось, что внутри JetBrains этот тезис сработал не везде: в сообщении о Cadence компания прямо написала, что сервер должен был быть пропатчен в рамках реакции на уязвимость, но этого не произошло.
Последствия выглядят уже не как локальный security bug, а как полноценный инцидент с длинным хвостом. JetBrains подтвердила доступ злоумышленников к персональным данным пользователей Cadence: именам, логинам, email-адресам, времени последнего входа и IP-адресам последнего доступа. Кроме того, была скомпрометирована полная резервная копия сервера Cadence за 2024 год. А это значит, что под риском оказались credentials, конфигурации, артефакты и журналы, которые в ней хранились. Компания отдельно сообщила о компрометации нескольких AWS IAM-пользователей и связанных с ними секретов, включая IAM-учетки сотрудников JetBrains, пользовавшихся Cadence. Также злоумышленники получили доступ к файлам в S3-бакетах AWS-аккаунтов JetBrains, связанных с сервисом.
Для разработчиков и platform-команд самый болезненный пункт другой: Cadence интегрировался с PyCharm через опциональный плагин и позволял синхронизировать проектные файлы для выполнения в облаке. Если в эти файлы попадали токены, ключи, конфиги деплоя или служебные данные, JetBrains предлагает считать их потенциально раскрытыми. Под подозрение попадают и сами результаты выполнения: компания рекомендует рассматривать как недоверенные не только входные данные, но и все execution outputs за затронутый период. Это уже не история в духе «смените пароль и идем дальше». Если через сервис проходили сборки, деплойные задачи, публикация пакетов или обращения к внешним API, придется разбирать цепочку до конца: что запускалось, чем подписывалось, куда публиковалось, что могло быть изменено.
В списке того, что JetBrains советует срочно ротировать, фактически весь типичный набор современного девтулчейна: креды AWS, Azure и Google Cloud; токены GitHub, GitLab и Bitbucket; доступы к npm, Maven, NuGet, PyPI; учетные данные Docker Hub, ECR, GCR и ACR; Slack-токены, webhooks, SSH-ключи, сервисные аккаунты и signing keys. Отдельно компания просит проверять логи на неожиданные клонирования репозиториев, несанкционированные коммиты, изменения webhook’ов, секретов и прав, новые personal access tokens, а также странные IAM-изменения и доступ к хранилищам. JetBrains опубликовала и шесть IP-адресов, связанных с наблюдаемой эксплуатацией, но сразу оговорилась: отсутствие этих индикаторов не означает, что компрометации не было.
На уровне рынка история бьет сразу по двум нервам. Первый: доверие к вендору инфраструктурных инструментов, который не выполнил собственную рекомендацию по патчингу. Второй: иллюзия, что облачный или «почти managed» сценарий автоматически безопаснее онпрема. На практике Cadence был сервисом удаленного выполнения кода, а такие системы по определению видят слишком много: исходники, артефакты, секреты, учетные данные к облакам и реестрам. Если в них происходит взлом, проблема быстро выходит за пределы одного сервиса и превращается в риск для всей цепочки поставки ПО. Для российских команд, которые строят собственные внутренние аналоги dev environments, self-hosted runners и AI-assisted пайплайнов, это хороший повод еще раз проверить базовые вещи: минимальные права, изоляцию секретов, срок жизни токенов, раздельные аккаунты для сборки и публикации, а главное — недоверие к артефакту по умолчанию после любого инцидента.
Самый неприятный вопрос здесь даже не в том, как именно была пропущена уязвимость TeamCity, а в том, сколько компаний по-прежнему воспринимают патчинг CI/CD как технический ритуал, а не как управление blast radius. История JetBrains показывает банальную, но дорогую истину: если сервис умеет запускать ваш код и держит у себя секреты, он уже является частью критической производственной цепочки. И когда в такой цепочке всплывает уязвимость TeamCity, проверять придется не только сервер, но и все, к чему он успел дотянуться.