JetBrains не обновила свой TeamCity — ключи Cadence нужно менять

В обновлённом 31 августа 2026 года уведомлении JetBrains об инциденте компания подтвердила эксплуатацию CVE-2026-63077 на сервере Cadence, доступ к резервной копии за 2024 год, персональным данным и части ресурсов AWS. Сервер TeamCity, управлявший заданиями сервиса, должен был получить исправление, но остался без него.

Бывшим пользователям Cadence недостаточно удалить плагин или заменить токен его подключения: необходимо отозвать все секреты, которые хранились в сервисе, присутствовали в синхронизированных проектах либо передавались заданиям. Опубликованный 30 августа разбор SecurityLab указывает на риск для облачных учётных данных, репозиториев, систем публикации пакетов и других внешних ресурсов.

Кого затрагивает взлом Cadence

Cadence был размещённым у JetBrains сервисом для запуска проектов на облачных вычислительных ресурсах через дополнительный плагин PyCharm. Для оркестрации заданий использовался TeamCity, а атакованным узлом стал api.cadence.jetbrains.com. Это не означает компрометацию всех установок PyCharm или TeamCity: проверка нужна организациям и разработчикам, которые использовали именно Cadence.

Независимый разбор NEXSIGHT подтверждает период активности с 8 по 24 августа 2026 года, обнаружение эксплуатации 23 августа и отключение сервера на следующий день. Там же перечислены доступ к резервной копии, учётным данным AWS IAM и файлам в S3, а также риск для синхронизированного из PyCharm кода.

Из действующей среды были извлечены имена пользователей, настоящие имена, адреса электронной почты, время последнего входа и последние использованные IP-адреса. Доступ к полной резервной копии также установлен; находившиеся в ней несколько учётных записей AWS IAM и связанные секреты были скомпрометированы, а атакующий обращался к файлам в корзинах S3 учётных записей JetBrains.

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

Какие ключи необходимо отозвать

Перечень для проверки определяется не набором установленных продуктов JetBrains, а содержимым конкретных заданий Cadence. Токены, которыми плагин PyCharm подключался к сервису, уже аннулированы, но они не заменяют учётные данные внешних систем.

• Облачные платформы. Отозвать постоянные ключи AWS, Azure и Google Cloud, секреты сервисных учётных записей и другие данные, передававшиеся заданиям. В журналах аудита искать входы, создание ключей и пользователей, изменения ролей и политик, обращения к объектным хранилищам.
• Репозитории. Перевыпустить персональные и проектные токены GitHub, GitLab и Bitbucket, ключи SSH, ключи развёртывания и пароли технических пользователей. Проверить необычные клонирования и скачивания, новые коммиты, вебхуки, участников и изменения разрешений.
• Реестры пакетов. Заменить учётные данные npm, Maven, NuGet, PyPI и внутренних хранилищ. Искать неожиданные публикации и версии, смену владельцев и прав, создание или изменение токенов.
• Реестры контейнеров. Сменить секреты Docker Hub, ECR, GCR, ACR и частных реестров. Просмотреть входы, загрузку и удаление образов, перемещение тегов и изменения доступа.
• Интеграции и автоматизация. Отозвать токены Slack, секреты вебхуков, ключи API, учётные данные сервисных пользователей и ключи развёртывания. Проверить создание интеграций, изменение адресов доставки и неожиданные обращения с новых IP-адресов.
• Подпись и сертификаты. Если задания могли читать закрытый ключ подписи пакетов, контейнеров или выпусков, требуется новый ключ и прекращение доверия к старому. Артефакты, выпущенные после начала подозрительной активности, следует сопоставить с журналом подписания.

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

Где искать подозрительные действия

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

1. Составить список всех проектов и заданий Cadence, включая закрытые и экспериментальные.
2. Для каждого задания определить синхронизированные файлы, переменные среды, подключённые репозитории, облака, реестры и внешние API.
3. Связать каждый найденный секрет с владельцем, уровнем прав и журналом системы, доступ к которой он открывал.
4. В первую очередь отозвать производственные ключи и секреты с широкими правами, не откладывая замену до завершения анализа журналов.
5. Искать не только входы, но и новые токены, роли, пользователей, вебхуки, публикации, коммиты и изменения политик.
6. Сохранить журналы и подозрительные артефакты до устранения последствий, чтобы не потерять время операции, IP-адрес и сведения о действовавшей учётной записи.

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

Почему смены токена плагина недостаточно

Токен плагина открывал PyCharm доступ к Cadence. Облачный ключ, токен репозитория или сертификат подписи давал уже заданию Cadence доступ к другой системе. Аннулирование первого закрывает прежнее подключение к сервису, но не мешает применить скопированный внешний секрет напрямую.

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

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

Читайте также:

• У реабилитации ребёнка с ДЦП нет одной цены: считать нужно доплаты
• Почему вам нужно начать изучать программирование
• Как выбрать самые лучшие партнёрские программы и на какие факторы нужно обращать внимание при выборе