Обработка путей в Jira Software Data Center и Confluence Data Center позволяет прочитать отдельные файлы без учётных данных. Уязвимость CVE-2026-21589 получила оценку 9.3 по шкале CVSS и уровень Critical по классификации Atlassian. Речь идёт о проблеме высокой степени опасности: атака не требует ни аккаунта, ни входа в систему, поэтому обычная защита логином и паролем её не сдерживает. Уязвимость затрагивает все версии Jira Data Center и Confluence Data Center, выпущенные до исправленных сборок. Оба продукта компании разворачивают на своих серверах, а не в облаке, и отвечает за обновление сам заказчик.
Уязвимость CVE-2026-21589
Механика уязвимости связана с обходом каталогов. Злоумышленник подставляет в запрос путь, который выводит его за пределы разрешённой директории, и получает содержимое нужного файла. Приложение отдаёт документ, не проверяя, есть ли у запрашивающего права на него. Успех возможен только при точном знании имени файла и его расположения. Перебирать или просматривать список файлов система не даёт, поэтому найти чувствительный документ наугад не получится. Это сужает возможности массового сканирования, но не мешает целенаправленной атаке. В корне веб-приложения нередко лежат конфигурационные файлы с учётными данными к базам данных, ключами и параметрами подключений. Если администраторы хранили такое в общедоступных каталогах, последствия могут оказаться тяжёлыми.
В бюллетене по Confluence проблему отнесли к обходу каталогов с пометкой о произвольном чтении и записи. Однако опубликованное описание говорит только о неавторизованном доступе к файлам. О возможности менять их или выполнять код там не сказано. Atlassian советует администраторам оценивать задокументированное влияние, а не расширенные формулировки в классификаторах. Разница важна: чтение чужого файла уже даёт злоумышленнику материал для дальнейших шагов, а изменение содержимого открывало бы путь к подмене данных и захвату системы. До подтверждения таких возможностей разумно исходить из более скромной оценки.
Облачные сервисы Atlassian уже получили исправления. Внутренняя проверка не выявила следов эксплуатации, и клиентам Cloud ничего делать не нужно. Для самостоятельно развёрнутых систем такой вывод не действует. Экземпляры, открытые в интернет, остаются под угрозой, пока администраторы не установят патч. Вход по логину и паролю тут не защищает, поскольку атака идёт до аутентификации. Даже корпоративный портал с формой входа стоит на время убрать из публичного доступа. Отдельная сложность в том, что Jira и Confluence часто связаны с другими внутренними системами: утекшие ключи и токены могут открыть злоумышленнику доступ за пределы одного приложения. Такие платформы обычно используют крупные организации, службы поддержки и отделы разработки, а данные в них касаются задач, документации, переписки и учётных записей сотрудников.
Исправления для Jira Data Center вошли в версии 9.12.40, 10.3.26 и 11.3.12. Для Confluence Data Center патчи доступны в версиях 9.2.26 и 10.2.19. Номера ветвей различаются, поэтому администраторам стоит свериться с бюллетенями производителя и выбрать сборку, соответствующую их линии обновлений. Сборки, срок поддержки которых истёк, тоже могут содержать ошибку. Поэтому Atlassian рекомендует перейти на исправленную версию с длительной поддержкой или на более новую. Обновление на промежуточную версию без патча проблему не решает.
Если обновиться сразу не получается, первым шагом стоит убрать систему из интернета. Внешний доступ ограничивают и для приложений с аутентификацией. Затем опасные запросы можно закрыть на уровне межсетевого экрана веб-приложений (WAF, средство фильтрации HTTP-трафика) или обратного прокси. Правило блокирует комбинацию из двух точек рядом с косой чертой, обратной косой чертой или двойным двоеточием. URL-кодированные варианты оно тоже перехватывает. Перед развёртыванием правило проверяют на тестовых запросах: слишком широкий фильтр ломает обычную работу, слишком узкий пропускает обход. Настройки зависят от конкретного средства, поэтому готовых универсальных рецептов тут нет.
Второй вариант опирается на механизм RewriteValve в Apache Tomcat. Сначала делают резервную копию экземпляра, затем останавливают каждую ноду кластера. В файле conf/server.xml внутри элемента Context включают компонент перезаписи. В каталог WEB-INF (atlassian-jira/WEB-INF для Jira или confluence/WEB-INF для Confluence) добавляют конфигурацию rewrite.config, подготовленную Atlassian. После этого ноду аккуратно запускают и проверяют, что приложение отвечает как обычно. Настройку вносят на каждом узле кластера, иначе защита окажется неполной: балансировщик продолжит отправлять часть запросов на незакрытый узел.
Atlassian прямо предупреждает, что обе меры носят временный характер и не заменяют установку патча. В первую очередь команды безопасности закрывают развёртывания, доступные из интернета, и проверяют каждый узел кластера. Обход каталогов относится к давно известному классу атак, однако в корпоративных продуктах такие ошибки появляются снова и снова. Причина обычно в том, что проверка путей разбросана по разным компонентам, и часть из них забывают обновить при доработках. Для организаций это означает простую вещь: обновление до исправленной сборки остаётся единственным надёжным решением, а временные фильтры лишь снижают риск, не устраняя ошибку. Разрыв между выходом патча и его установкой превращается в главное окно риска для тех, кто держит корпоративные системы на своих серверах.
Ссылки
