CVE-2026-21589 в Atlassian Data Center: риск утечки данных и что делать

CVE-2026-21589 — критическая уязвимость (CVSS 9.3) в восьми продуктах Atlassian Data Center, позволяющая удалённому неаутентифицированному злоумышленнику читать известные ему файлы в корне веб-приложения, затрагивает как поддерживаемые, так и часть устаревших версий, включая Server-редакции; Atlassian уже обновил облачные сервисы, а владельцам локальных инсталляций рекомендуется немедленно обновиться или временно изолировать и защитить системы с помощью правил на WAF и приложенных к продукту конфигураций переписывания URL.

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

Atlassian описывает проблему как уязвимость класса path traversal: специально сформированный запрос с последовательностью вида .. рядом с символами /, \ или :: даёт возможность получить доступ к файлам, расположенным в каталоге развертывания веб-приложения. При этом:

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

Официальное описание и рекомендации опубликованы в advisory Atlassian: CVE-2026-21589: arbitrary file access vulnerability impacts multiple products. CVE также зарегистрирован в базе CVE Project: запись CVE-2026-21589 и в NVD по шаблонной ссылке NVD: CVE-2026-21589.

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

• Bitbucket Data Center — см. тикет BSERV-20604;
• Confluence Data Center — тикет CONFSERVER-104488;
• Jira Software Data Center — тикет JRASERVER-79546;
• Jira Service Management Data Center — тикет JSDSERVER-16809;
• Bamboo Data Center — тикет BAM-26567;
• Crowd Data Center — тикет CWD-6610;
• Crucible — тикет CRUC-8741;
• Fisheye — тикет FE-7583.

Облачные версии Atlassian уже обновлены, Bitbucket Cloud уязвимости не подвержен. Для клиентов cloud никаких действий не требуется, всё внимание должно быть сосредоточено на локальных развёртываниях.

Проблемные моменты с версиями и Server-редакциями

Вокруг диапазона затронутых и исправленных версий наблюдается путаница между advisory и CVE-записями:

• для Crowd в тикете CWD-6610 одно поле указывает фиксированную версию ветки 7.1 как 7.1.7, тогда как таблица в том же тикете одновременно показывает 7.1.6 как исправленную и как уязвимую;
• в JSON-записи по CVE для Crowd указана версия 7.1.1 как рубеж, хотя по release notes Crowd 7.1 этот релиз датирован ноябрём 2025 года, то есть задолго до публичного раскрытия уязвимости;
• для Bamboo в CVE-записи встречаются два варианта номера: 10.2.4 и 10.2.24, что затрудняет однозначное определение безопасной версии.

Отдельной проблемой является состояние Server-редакций. В CVE-записи Atlassian помечает как уязвимые все версии Bamboo Server, Bitbucket Server, Confluence Server и Crowd Server, не указывая для них ни одной исправленной версии. Для Jira Software Server, Jira Service Management Server, Crucible Server и Fisheye Server указаны версии, начиная с которых продукты считаются неуязвимыми (например, Jira Software Server с 9.12.40), но не разъясняется, допустим ли запуск этих версий по условиям лицензий Server.

Дополнительно, согласно общим release notes Crowd, последняя Server-версия Crowd — 5.2 (сентябрь 2023 года), то есть ни одна из перечисленных фиксированных версий Crowd не относится к линейке Server. Для владельцев таких установок это означает фактическое отсутствие исправления и необходимость компенсирующих мер.

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

Контекст угроз: прецедент с CVE-2021-26086

Path traversal в продуктах Atlassian уже становился объектом эксплуатации. Уязвимость CVE-2021-26086 в Jira Server и Data Center позволяла удалённым злоумышленникам читать отдельные файлы и была впоследствии добавлена в каталог известных эксплуатируемых уязвимостей CISA. Подробности доступны в записи NVD: CVE-2021-26086.

Этот прецедент важен по двум причинам:

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

В текущем advisory Atlassian заявляет, что не обнаружила свидетельств эксплуатации CVE-2026-21589 в облачной среде и не может подтвердить, были ли скомпрометированы конкретные локальные инсталляции. Отсутствие информации о фактических атаках не снижает риск, учитывая критический балл CVSS и историю с уже эксплуатировавшимися аналогичными ошибками.

Оценка воздействия на организации

Под удар попадает весь спектр организаций, которые:

• эксплуатируют Atlassian Data Center или ещё не мигрировали с Server на современные редакции;
• делают эти инстансы доступными с интернета (включая сценарии с обязательной авторизацией);
• используют Atlassian как центральный элемент цепочки разработки и эксплуатации (управление задачами, репозитории, CI/CD, управление доступом).

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

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

Комбинация таких данных способна привести к:

• эскалации доступа из чтения файлов к захвату базы данных, интеграционного аккаунта или другого сервиса;
• утечке исходного кода, внутренней документации и другой интеллектуальной собственности через цепочку зависимостей (например, при доступе к Bitbucket или Bamboo);
• усилению атак на цепочку поставок, если через уязвимый Atlassian-инстанс злоумышленник получит представление о процессе сборки и выпуска продукта.

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

Практические рекомендации по снижению рисков

1. Обновление как приоритетный сценарий

• Ориентируйтесь на официальный advisory Atlassian: advisory по CVE-2026-21589 и связанные тикеты продуктов (BSERV-20604, CONFSERVER-104488 и др.).
• Для каждого продукта определите текущую версию и сравните с указанием «Fixed in» в соответствующем тикете.
• Предпочтительный вариант — обновление до обозначенной исправленной LTS-версии или более новой, если она также помечена как содержащая фикс.
• Для устаревших Server-редакций, для которых исправлений нет, рассматривайте ускоренную миграцию на Data Center или cloud либо перевод таких инстансов в строго контролируемый, изолированный контур.

2. Сетевые ограничения доступа

• Если немедленное обновление невозможно, по рекомендации Atlassian по возможности временно отключите инстанс от внешней сети.
• Для критичных систем, которые нельзя выключить, ограничьте доступ только внутренними сетями и VPN, исключив прямую публикацию в интернет.
• Примените на WAF или обратном прокси правило, блокирующее запросы, где после до двухкратного URL-декодирования встречается последовательность .. непосредственно рядом с /, \ или ::. Конкретное выражение Atlassian приводит в advisory.

3. Временные правила на уровне приложений

Atlassian предлагает дополнительные «митигации» на уровне самих приложений (они не заменяют обновление):

• для Confluence, Jira Software, Jira Service Management, Bamboo, Crowd — использование Tomcat RewriteValve с правилом, блокирующим описанные выше шаблоны в URL; для активации потребуется изменить конфигурацию на каждом узле и перезапустить сервис;
• для Bitbucket — добавление правила в urlrewrite.xml на каждом узле и зеркале, также с последующей перезагрузкой;
• для Crucible и Fisheye доступны только внешние меры (WAF/обратный прокси).

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

4. Анализ журналов на предмет возможной эксплуатации

Atlassian прямо указывает, что не может удостовериться, подверглись ли конкретные инстансы атакам, и предлагает администраторам самостоятельно проверить логи.

• Выгрузите журналы доступа веб-сервера и/или встроенные журналы продукта за интересующий период.
• Нормализуйте запросы: выполните декодирование URL до двух раз, чтобы выявить попытки обхода через двойное кодирование.
• Поиск выполняйте по наличию .., непосредственно соседствующего с /, \ или :: — либо примените то же регулярное выражение, которое используется в блокирующем правиле Atlassian.

Advisory не даёт критериев отделения неудачных попыток от успешных. В практическом плане полезно дополнительно анализировать:

• коды ответа сервера (подозрительны серии ответов 200/206 на нетипичные пути);
• размеры ответов и аномалии по сравнению с обычными статическими ресурсами;
• корреляцию с последующей активностью с того же IP (аутентификация, изменение конфигураций, скачивание артефактов).

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

5. Приоритизация реагирования

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

• выделить все инстансы Atlassian, доступные из интернета, в высший приоритет для обновления и внедрения митигаций;
• особо отнестись к инсталляциям, обслуживающим процессы разработки и сборки, а также хранящим чувствительные артефакты (репозитории, артефакты сборок, конфигурации доступа);
• в кратчайшие сроки устранить неопределённость по версиям: свериться с тикетами, advisory и, при необходимости, поддержкой Atlassian по «серым» версиям вроде упомянутых вариантов Crowd и Bamboo.

Основной практический вывод: CVE-2026-21589 нужно рассматривать не как локальный дефект одного продукта, а как критический риск утечки конфигураций и данных в ключевой части инфраструктуры разработки. Организациям следует немедленно инвентаризировать все локальные инстансы Atlassian, обновить их до безопасных версий либо изолировать, включить рекомендованные фильтры на WAF и уровне приложений и провести целевой разбор журналов на наличие подозрительных запросов с path traversal-паттернами.