Исправление TeamCity CVE-2026-63077: руководство по экстренному обновлению для предприятий

Официально подтверждено, что CVE-2026-63077 затрагивает TeamCity On-Premises, а неисправленные серверы подвергались активной эксплуатации и попыткам эксплуатации. Для TeamCity Cloud пользовательское исправление не требуется: ответственность за соответствующее обновление лежит на поставщике, что отдельно указано в официальном сообщении о CVE.

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

Рекомендуемый порядок:

• ограничить доступ к административному интерфейсу из Интернета и оставить только необходимые корпоративные подсети или аварийный канал;
• заморозить изменения пользователей, ролей, токенов, агентов и конфигурации проектов;
• приостановить производственные задания, особенно связанные с подписью, публикацией и развёртыванием;
• сохранить журналы сервера, аудита, reverse proxy, базы данных и системных событий без перезаписи исходных файлов;
• зафиксировать список активных Mac Agent, их владельцев, адресов, статусов авторизации и текущих заданий;
• назначить одного координатора, который утверждает переход от изоляции к ремонту и от ремонта к восстановлению.

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

Матрица выбора пути

Исправленные версии 2025.11.7 и 2026.1.3 перечислены в официальном уведомлении JetBrains о CVE-2026-63077. Это не означает, что любая из них автоматически подходит конкретной организации: переход должен учитывать текущую ветку и зависимости.

До остановки сервера необходимо разделить то, что требуется для запуска TeamCity, и то, что требуется для доказательства корректности восстановления. Обычная резервная копия базы данных не обязательно содержит Data Directory, конфигурацию сервера, пользовательские настройки, плагины, журналы, секреты, рабочие каталоги агентов и все данные, необходимые для расследования.

Минимальный набор для сохранения:

• резервная копия базы данных с проверкой возможности восстановления;
• Data Directory и конфигурационные файлы TeamCity;
• список установленных плагинов и их версий;
• журналы сервера, аудита и прокси за период до ограничения доступа;
• описание подключений к VCS, хранилищам артефактов и внешним системам;
• перечень Mac Agent с именем, адресом, владельцем, serverUrl и статусом авторизации;
• сведения о Java, драйвере базы данных, операционной системе узла и способе запуска службы;
• журналы заданий, метаданные сборок и сведения о происхождении артефактов.

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

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

Для сред, где обновление связано с Java, отдельно проверяется официальная документация TeamCity по Java 21. Версия Java — не косметическая деталь: неподходящая среда выполнения может превратить аварийное исправление в отказ сервера или некорректную работу плагинов.

Работы выполняются в следующей последовательности.

Остановка и фиксация состояния

Остановите TeamCity штатным способом, убедитесь в отсутствии активных процессов и сохраните итоговое состояние сервера. Не удаляйте журналы и не очищайте рабочие каталоги до того, как они будут скопированы в место, доступное только группе расследования.

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

Установка исправления

Выберите исправленную ветку или официальный security patch, руководствуясь текущей версией, лицензией, зависимостями и длительностью окна. Не следует смешивать исправление уязвимости с одновременной заменой базы данных, массовым обновлением плагинов и перестройкой всей CI/CD-архитектуры: каждая дополнительная переменная усложняет установление причины сбоя.

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

Запуск и контроль

После запуска проверьте:

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

Результат «сервер запущен» недостаточен. Проверка должна отвечать на два разных вопроса: устранён ли путь дальнейшей эксплуатации и можно ли доверять данным, созданным до обновления.

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

Для контроля статуса, авторизации и операций с агентами используйте официальную документацию TeamCity REST API для Agent, а не только визуальный зелёный статус в интерфейсе.

Mac Agent нельзя возвращать в производственную маршрутизацию сразу после восстановления сервера. Сервер, агент, рабочая область, узел подписи и хранилище артефактов — разные доверенные границы. Их нужно проверять раздельно.

Для каждого агента создаётся отдельная карточка восстановления:

• имя агента и физическая или виртуальная идентичность хоста;
• назначенный владелец и допустимые проекты;
• serverUrl и способ подключения;
• состояние авторизации;
• версия и результат автоматического обновления;
• установленный Xcode и набор зависимостей;
• наличие signing Keychain и связанные права;
• состояние рабочего каталога до первой тестовой сборки;
• решение: вернуть, изолировать для расследования или вывести из эксплуатации.

Автоматическое обновление агента не следует сопровождать принудительной перезагрузкой узла: сначала нужно дождаться завершения процедуры и проверить итоговый статус. Условия запуска и обновления macOS-агента описаны в официальной документации по запуску TeamCity Agent на macOS.

Первую проверку проводят без производственной подписи и публикации:

• агент подключается к ожидаемому серверу;
• тестовая задача получает код из разрешённого VCS;
• Xcode и зависимости соответствуют утверждённой конфигурации;
• рабочая область очищается перед повторным запуском;
• сборка завершается без доступа к производственным секретам;
• журналы агента и сервера совпадают по времени и идентификатору задания.

Неизвестный агент не следует авторизовывать «для проверки». Его сначала отключают, сохраняют состояние и сравнивают с инвентарём. Если доверие к хосту потеряно, безопаснее создать новый чистый узел, чем пытаться доказать отсутствие изменений на старом.

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

Удобно вести таблицу расследования с колонками:

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

Ротация должна проходить по зонам ответственности:

• VCS — токены, пароли и SSH-ключи;
• реестр и хранилище артефактов — учётные записи публикации;
• облачные системы — ключи доступа и роли;
• развёртывание — ключи и сервисные учётные данные;
• Apple Developer — сертификаты, профили и учётные данные;
• macOS-подпись — signing Keychain, парольные материалы и разрешения.

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

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

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

До восстановления выпуска необходимо подготовить изолированный Mac-узел с минимальным набором инструментов. Его назначение — не заменить расследование, а дать независимую точку сравнения для кода, зависимостей, Xcode, тестов, архива и подписи.

Порядок проверки:

• заблокировать производственную маршрутизацию старых агентов;
• подключить чистый узел к исправленному TeamCity-серверу;
• выполнить получение исходного кода из разрешённого источника;
• собрать приложение без производительного signing Keychain;
• запустить тесты и проверить очистку рабочей области;
• отдельно выполнить архивирование;
• только после этого провести контролируемую подпись;
• сравнить результат с доверенным эталоном;
• проверить происхождение и публикацию артефакта;
• оформить решение о старом узле: переустановка, продолжение расследования или вывод из эксплуатации.

Производственный допуск принимается не по одному зелёному заданию, а по совокупности условий:

• сервер обновлён до поддерживаемого исправленного состояния;
• внешний доступ ограничен и повторно проверен;
• журналы сохранены, а расследование имеет владельца;
• неизвестные агенты изолированы;
• необходимые CI/CD-секреты ротированы и старые значения отозваны;
• чистая сборка воспроизводит ожидаемый результат;
• артефакты уязвимого периода классифицированы;
• существует план отката и понятен владелец решения.

Для команд без резервного Mac-узла временная изолированная среда может быть рациональнее, чем повторное включение непроверенного хоста. При выборе такого ресурса следует заранее определить срок аренды, способ доступа, политику сброса, границы сети, хранение журналов и порядок удаления секретов. В разделе помощи NUKCLOUD можно сверить доступные организационные вопросы перед PoC, а варианты аренды удалённого Mac оценивать только после определения требований к изоляции и восстановлению.

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

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

Перед включением выпуска ответственное лицо проходит контрольный список:

• [ ] Доступ к TeamCity On-Premises извне ограничен.
• [ ] Версия сервера или официальный security patch подтверждены по источнику.
• [ ] Backup базы данных, Data Directory и журналы проверены.
• [ ] Java, драйвер базы данных и плагины сопоставлены с выбранным путём обновления.
• [ ] Сервер, Mac Agent, рабочая область и signing node расследуются как отдельные объекты.
• [ ] Неизвестные или сомнительные агенты не авторизованы.
• [ ] VCS, реестры, облачные системы, ключи развёртывания и Apple Developer credentials ротированы по плану.
• [ ] Артефакты уязвимого периода получили решение о доверии или повторной сборке.
• [ ] Чистый Mac Agent успешно прошёл получение кода, сборку, тесты, архивирование и контролируемую подпись.
• [ ] Зафиксированы критерии отката, владелец решения и допустимая производственная нагрузка.

NUKCLOUD здесь уместен не как замена постоянной инфраструктуре, а как временный чистый контур для PoC, восстановления агента и повторного запуска ключевых сборок. Покупка собственного Mac сохраняет физический контроль, но требует заранее иметь резерв, обслуживание, сетевую доступность и процедуру безопасной переустановки. Обычный непроверенный старый узел дешевле только до первого сомнительного артефакта: после этого он увеличивает объём расследования и может задержать выпуск.

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