Критическая уязвимость Atlassian CVE-2026-21589 уже используется в атаках на самодостаточно размещённые инсталляции Jira, Confluence и Bitbucket. Первые попытки эксплуатации появились в ловушечной сети Previdian менее чем через два часа после публикации технического разбора и публичного PoC; для начального доступа злоумышленнику не нужна аутентификация.
Проблема затрагивает восемь серверных продуктов Atlassian: Bitbucket Data Center, Confluence Data Center, Jira Service Management Data Center, Jira Software Data Center, Bamboo Data Center, Crowd Data Center, Crucible и Fisheye. Как сообщает BleepingComputer, дефект позволяет читать определённые файлы из веб-корня приложения, если атакующий знает их точное имя и путь. Для организаций, которые держат Atlassian Data Center в собственной инфраструктуре и открывают его из интернета, это история не про «плановое обновление на выходных», а про срочную проверку периметра.
Корень CVE-2026-21589 находится в общей библиотеке веб-ресурсов. Она преобразует двойное двоеточие :: в символ слеша, что позволяет сформировать запрос с обходом каталогов через конечные точки ресурсов плагинов. Исследователи watchTowr подтвердили неаутентифицированное чтение файлов в Jira, Confluence и Bitbucket. За пределы контекста приложения Tomcat их техника не выходит, но это слабое утешение: внутри приложения нередко лежат конфигурация, интеграционные секреты и данные, которых внешнему посетителю видеть не положено.
Самый неприятный сценарий связан со связкой Jira и Crowd. В такой конфигурации из файла WEB-INF/classes/crowd.properties можно извлечь открыто хранящиеся учётные данные приложения. Если Crowd доступен атакующему по сети, а у приложения достаточно прав, эти данные позволяют через API Crowd создать новую учётную запись администратора Jira. По сути, чтение файла превращается в захват административного доступа — без подбора паролей и без компрометации существующего пользователя.
У этого сценария есть важная оговорка. watchTowr отмечает, что список разрешённых IP-адресов для Crowd заметно усложняет атаку: злоумышленнику потребуется добраться до Crowd через другой узел либо использовать возможности вроде SSRF в Jira, Confluence или Bitbucket. Но ограничение доступа не отменяет необходимость исправления. Утёкшие данные из crowd.properties дают административные возможности уже в самой системе управления идентификацией Crowd, включая создание пользователей и изменение разрешений.
Previdian зафиксировала попытки эксплуатации с трёх IP-адресов: 38.60.157[.]86, 146.70.187[.]234 и 159.26.119[.]225. Компания рекомендует блокировать их, хотя рассчитывать лишь на блок-лист бессмысленно: после публикации PoC появился и шаблон Nuclei, поэтому поиск уязвимых серверов легко автоматизируется. Именно эта связка — готовая техника, публичный код и широкий набор популярных продуктов — обычно резко сокращает промежуток между раскрытием дефекта и массовым сканированием.
Администраторам стоит прежде всего определить, какие экземпляры Data Center доступны извне, и сверить версии с бюллетенем Atlassian. При невозможности немедленно обновиться вендор предлагает временные меры: ограничить внешний сетевой доступ, добавить правило WAF или прокси для блокировки характерных шаблонов обхода каталогов, настроить Tomcat RewriteValve для Confluence, Jira Service Management, Jira, Bamboo и Crowd либо правило переписывания URL для Bitbucket. Отдельно имеет смысл проверить, не доступен ли Crowd шире, чем действительно требуется, и не остались ли в интеграциях избыточные права.
Эта уязвимость Atlassian хорошо показывает цену привычной практики выставлять рабочие системы управления задачами и знаниями прямо в интернет: после публикации PoC защитникам приходится соревноваться не с ручной атакой, а с автоматизированным сканированием. Atlassian не может определить, были ли скомпрометированы отдельные инсталляции, поэтому обновление и проверка журналов доступа — минимально разумная реакция. Технический разбор и инструмент проверки watchTowr упомянуты в материале .