CVE-2026-21589 в Atlassian Data Center: анализ риска и срочные действия

Критическая уязвимость CVE-2026-21589 (CVSS 9.3) в продуктах Atlassian Data Center уже целенаправленно проверяется злоумышленниками: по данным телеметрии зафиксировано не менее 15 попыток эксплуатации всего через два часа после публикации технических деталей, что делает немедочное обновление и изоляцию уязвимых инстансов от интернета приоритетной задачей для всех организаций, использующих локальные развертывания Jira, Confluence, Bitbucket, Bamboo, Crowd и других Atlassian-систем.

Технические детали CVE-2026-21589

Уязвимость CVE-2026-21589 классифицирована как произвольный доступ к файлам в пределах корневого каталога веб-приложения (webroot) без аутентификации. Формальное описание и базовую информацию можно найти в базе NVD по шаблону CVE: карточка CVE-2026-21589 в NVD.

Под ударом находятся следующие продукты Atlassian (редакции Data Center и связанные серверные решения):

• Bitbucket Data Center — исправленные версии: 9.4.26, 10.2.8, 10.5.1
• Confluence Data Center — 9.2.26, 10.2.19
• Jira Service Management Data Center — 5.12.40, 10.3.26, 11.3.12
• Jira Software Data Center — 9.12.40, 10.3.26, 11.3.12
• Bamboo Data Center — 10.2.24, 12.1.12
• Crowd Data Center — 6.3.7, 7.0.3, 7.1.7, 7.2.4
• Crucible — 4.9.15
• Fisheye — 4.9.15

Облачные продукты Atlassian Cloud, по заявлению вендора, уже обновлены.

Ключ к эксплуатации лежит в механизме обработки web-ресурсов Atlassian. Исследователи из watchTowr показали, что логика разрешения путей преобразует строки вида \"..::..::..::..::WEB-INF::web.xml\" в стандартный относительный путь \"../../../../WEB-INF/web.xml\". Подробный технический разбор доступен в их публикации: анализ CVE-2026-21589 от watchTowr.

Далее эта особенность комбинируется с ресурсом плагина jQuery colorpicker, размещённым по пути /includes/jquery/plugins/colorpicker/images/. За счёт завершающего символа «/» атакующий может «вырваться» из каталога изображений и обратиться к другим файлам в приложении, используя один HTTP-запрос. Пример запроса для Jira:

GET /download/resources/jira.webresources:color-picker-popup/images/..::..::..::..::..::WEB-INF::web.xml HTTP/1.1
Host: <Jira-Hostname>

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

Особенно критичен сценарий для Crowd и Jira: доступен файл WEB-INF/classes/crowd.properties, содержащий учётные данные Crowd. Исследователи показывают, что, получив эти данные, злоумышленник может добиться административного доступа к приложению, создавать новые учётные записи и повышать привилегии до уровня Jira Administrator. Сопутствующий материал и примеры представлены в репозитории watchTowr: watchTowr vs Atlassian CVE-2026-21589.

Первые признаки эксплуатации и IOC

Компания Previdian, специализирующаяся на проактивной оценке уязвимостей, зафиксировала начало атак на свои honeypot-системы через два часа после публикации технических деталей эксплойта watchTowr. Согласно их телеметрии, было зарегистрировано 15 попыток эксплуатации с трёх уникальных IP-адресов в Японии и США. Подробности доступны в их обзоре: телеметрия по CVE-2026-21589 от Previdian.

Выделенные индикаторы компрометации (IOC):

• 38.60.157[.]86
• 146.70.187[.]234
• 159.26.119[.]225

Это ранние признаки разведывательного и тестового трафика. Важно, что основным триггером для начала волны сканирования стало публичное раскрытие технических деталей и наличие готовых шаблонов для инструментов автоматизированного сканирования (Nuclei). После публикации соответствующего шаблона, о чём предупреждает Previdian, массовое сканирование внешних периметров на уязвимость станет тривиальной задачей даже для малоопытных злоумышленников.

Оценка воздействия и профиль риска

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

• экспонируют инстансы Jira, Confluence, Bitbucket, Bamboo, Crowd и другие продукты Atlassian Data Center напрямую в интернет;
• используют Crowd как центральную точку аутентификации для других приложений;
• хранят в пределах webroot конфигурационные файлы с паролями, ключами API и токенами доступа (включая файлы web.xml, crowd.properties и аналогичные).

Потенциальные последствия при успешной эксплуатации:

• Компрометация учётных данных — извлечение паролей, токенов и ключей шифрования из конфигурационных файлов.
• Эскалация привилегий — переход от неаутентифицированного доступа к правам администратора Atlassian-приложения за счёт украденных данных Crowd.
• Глубокое вмешательство в бизнес-процессы — создание скрытых административных аккаунтов, изменение прав пользователей, манипуляция очередями задач, репозиториями кода и пайплайнами сборки.
• Цепная компрометация — использование полученных учётных данных для доступа к другим системам, интегрированным с Atlassian (CI/CD, сервис-деск, система аутентификации).

С точки зрения отраслей, особая чувствительность у компаний, где Jira и Confluence являются критическими элементами операционной деятельности: ИТ-провайдеры, разработчики программного обеспечения, финансовые организации, телеком и крупные промышленные предприятия. Для них потеря целостности или конфиденциальности данных в Atlassian-среде напрямую бьёт по операционной устойчивости и соответствию требованиям регуляторов.

Практические рекомендации по защите

1. Приоритизация и установка патчей

Рекомендуемый приоритет — немедленное обновление всех затронутых инстансов до версий, содержащих исправление:

• Bitbucket Data Center: 9.4.26, 10.2.8, 10.5.1;
• Confluence Data Center: 9.2.26, 10.2.19;
• Jira Service Management Data Center: 5.12.40, 10.3.26, 11.3.12;
• Jira Software Data Center: 9.12.40, 10.3.26, 11.3.12;
• Bamboo Data Center: 10.2.24, 12.1.12;
• Crowd Data Center: 6.3.7, 7.0.3, 7.1.7, 7.2.4;
• Crucible и Fisheye: 4.9.15.

Порядок обновления имеет смысл выстраивать, начиная с публично доступных инстансов и систем, где Atlassian связан с управлением доступом (Crowd) и разработкой (Jira, Bitbucket, Bamboo).

2. Временные меры при невозможности немедленного обновления

До установки патчей имеет смысл реализовать все рекомендованные временные меры:

• Убрать инстанс с прямого доступа из интернета — разместить за VPN, прокси или ограничить доступ по IP-спискам.
• Настроить правила Web Application Firewall для блокировки подозрительных запросов к ресурсам /download/resources/…/images/ с последовательностями ..:: и попытками обращения к WEB-INF.
• Использовать Tomcat RewriteValve (для Confluence, Jira, Jira Service Management, Bamboo, Crowd) для принудительного отклонения подобных шаблонов URL.
• Для Bitbucket — добавить соответствующее правило в urlrewrite.xml, блокирующее переходы из путей с изображениями к системным каталогам.

Даже после установки патчей имеет смысл оставить часть этих фильтров как дополнительный защитный слой против возможных будущих обходов.

3. Обнаружение возможной эксплуатации

Рекомендованные шаги по проверке на предмет уже состоявшихся попыток атак:

• Проанализировать журналы доступа веб-сервера и обратных прокси на наличие запросов, содержащих:
  • последовательности ..::..:: в URL;
  • обращения к путям вида /download/resources/*color-picker-popup/images/;
  • упоминания WEB-INF/web.xml, crowd.properties и других чувствительных файлов.
• Проверить логи на обращения с IP-адресов:
  • 38.60.157[.]86
  • 146.70.187[.]234
  • 159.26.119[.]225

  с последующей корреляцией по времени и контексту запросов.

• Переоценить журналы аутентификации в Jira и Crowd: появление новых администраторских аккаунтов, изменения прав существующих пользователей в период после публикации эксплойта.

4. Ограничение последствий компрометации конфигурационных файлов

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

• смена паролей и ключей, которые могли храниться в web.xml, crowd.properties и аналогичных файлах;
• отзыв и перевыпуск токенов, используемых интеграциями с внешними системами (CI/CD, репозитории кода, системы аутентификации);
• проверка аномальной активности в интегрированных системах, куда мог быть получен доступ через скомпрометированные учетные данные.

Ключевое действие на ближайшие 24–48 часов — обновить все уязвимые инстансы Atlassian Data Center до исправленных версий, временно ограничить их доступность из интернета, а затем целенаправленно проанализировать журналы на предмет характерных запросов с ..:: и обращений к WEB-INF, с последующей сменой всех учётных данных, потенциально доступных из конфигурационных файлов.