TeamCity взламывают без пароля: CISA подтвердила активные атаки

5 августа запись CISA в каталоге KEV зафиксировала активную эксплуатацию CVE-2026-63077 в TeamCity On-Premises. Уязвимые локальные серверы атакуют без предварительной авторизации: достаточно сетевого доступа к TeamCity по HTTP или HTTPS.

Успешная эксплуатация позволяет выполнять команды операционной системы с правами процесса TeamCity. Поэтому речь идёт не только о захвате сервера: под угрозой могут оказаться конфигурации, сохранённые учётные данные, сборочные артефакты и связанные звенья цепочки непрерывной интеграции и доставки.

Какие серверы уязвимы

Проблема относится к самостоятельно размещённым установкам TeamCity. Через протокол опроса агентов атакующий может передать недоверенные сериализованные данные, обойти проверку подлинности и запустить произвольные команды без учётной записи и действий пользователя.

Первичный бюллетень JetBrains относит к уязвимым все версии TeamCity On-Premises и называет исправленными выпуски 2025.11.7 и 2026.1.3. Там же указано, что для TeamCity Cloud необходимые меры уже применены и клиентам облачного сервиса ничего устанавливать не нужно.

Ключевое условие атаки — доступность интерфейса TeamCity по HTTP(S). Наиболее очевидная цель — сервер с открытой в интернет страницей входа или программным интерфейсом, однако внутреннее размещение само по себе не устраняет риск: уязвимость остаётся достижимой из любого сегмента, откуда разрешено сетевое соединение с сервером.

Почему компрометация затрагивает сборочную цепочку

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

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

Установка исправления блокирует новые попытки через CVE-2026-63077, но не отменяет уже выполненные команды и не подтверждает чистоту системы. Поэтому для ранее доступного уязвимого сервера обновление и расследование возможного вторжения — две отдельные задачи.

Обновление или защитный модуль

1. Проверить все экземпляры. В инвентаризацию должны войти производственные, тестовые, резервные и временно выключенные серверы. Для каждого нужно установить точную версию и определить, из каких сетей доступен HTTP(S)-интерфейс.
2. Обновить поддерживаемую установку. Сервер следует перевести как минимум на 2025.11.7 либо 2026.1.3 в зависимости от используемой ветки. Более новый выпуск должен явно включать исправление CVE-2026-63077.
3. Установить защитный модуль, если обновление откладывается. JetBrains предоставляет его для TeamCity 2017.1 и новее. Модуль закрывает только эту уязвимость и не заменяет остальные исправления безопасности из актуального выпуска.
4. Ограничить доступ до устранения риска. Если обновление или модуль нельзя применить немедленно, внешний доступ следует временно закрыть, оставив соединения только из доверенных сетей. Ограничение поверхности атаки не является постоянной заменой исправлению.

Для установок TeamCity 2017.1–2018.1 после добавления защитного модуля требуется перезапуск сервера; начиная с версии 2018.2 его можно включить без перезапуска. На TeamCity 2024.03 и новее доступные защитные модули могут автоматически загружаться и отображаться администраторам в разделе обновлений, однако их применение всё равно необходимо проверить.

Какие признаки проверить в TeamCity

В опубликованном 7 августа обновлённом предупреждении JetBrains сказано о сообщениях как об успешной, так и о неудачной эксплуатации неисправленных серверов. Производитель рекомендует искать в журналах строку com.thoughtworks.xstream.converters.ConversionException: отдельно она не доказывает взлом, но может сопровождать попытку или успешную атаку.

После установки исправления в журнале может появиться com.thoughtworks.xstream.security.ForbiddenClassException. Такая запись способна указывать на попытку, которую уже заблокировал защитный модуль или исправленная версия.

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

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

Что пока неизвестно об атаках

CISA и JetBrains подтверждают эксплуатацию, однако публичных данных о масштабе кампании, личности атакующих и едином наборе сетевых индикаторов пока нет. Опубликованные JetBrains признаки требуют контекстного анализа и сами по себе не являются доказательством успешного взлома.

На 8 августа исправления и временный защитный модуль доступны. Главная граница риска проходит между TeamCity Cloud, где меры принял поставщик, и достижимыми по сети серверами TeamCity On-Premises: последние необходимо исправить и отдельно проверить на воздействие, которое могло произойти до обновления.