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 з подальшою зміною всіх облікових даних, потенційно доступних із конфігураційних файлів.