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

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

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

За даними Atlassian, уразливі всі версії до виправлених (зазначені в тікетах і бюлетені безпеки) таких продуктів 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-редакціями

Навколо діапазону вразливих і виправлених версій спостерігається плутанина між бюлетенем безпеки та 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-платформ, які часто зберігають артефакти розробки, ключі інтеграцій і документацію з інфраструктури;
• показує, що навіть «обмежене» читання окремих файлів може бути досить серйозним, щоб потрапити до пріоритетних списків вразливостей на рівні державних регуляторів.

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

Оцінка впливу на організації

Під удар потрапляє весь спектр організацій, які:

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

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

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

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

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

Невизначеність із межами безпечних версій і статусом Server-редакцій створює додатковий операційний ризик: адміністраторам складніше швидко відповісти на запитання «чи є ця конкретна інсталяція уразливою», а отже, складніше пріоритизувати дії та комунікувати ризик бізнесу.

Практичні рекомендації зі зниження ризиків

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

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

2. Мережеві обмеження доступу

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

3. Тимчасові правила на рівні застосунків

Atlassian пропонує додаткові «мітигації» на рівні самих застосунків (вони не замінюють оновлення):

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

Ці заходи знижують імовірність успішної експлуатації, але не усувають саму вразливість. Після встановлення патча їх варто зберегти як додатковий захисний шар.

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

Atlassian прямо зазначає, що не може впевнено сказати, чи піддалися конкретні інстанси атакам, і пропонує адміністраторам самостійно перевірити журнали.

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

Бюлетень безпеки не дає критеріїв відокремлення невдалих спроб від успішних. На практиці корисно додатково аналізувати:

• коди відповіді сервера (підозрілими є серії відповідей 200/206 на нетипові шляхи);
• розміри відповідей і аномалії порівняно зі звичайними статичними ресурсами;
• кореляцію з подальшою активністю з тієї ж IP-адреси (автентифікація, зміна конфігурацій, завантаження артефактів).

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

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

З огляду на неавтентифікований характер вразливості, високий рівень впливу на конфіденційність і потенційний вплив на інші системи, доцільно:

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

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