Atlassian CVE-2026-21589: aktywne ataki i dostęp do plików bez logowania

CISA dodała CVE-2026-21589 do katalogu Known Exploited Vulnerabilities, co oznacza, że istnieją dowody wykorzystania podatności w realnych atakach. Błąd pozwala napastnikowi bez konta pobrać określone pliki z katalogu głównego aplikacji w wielu lokalnie utrzymywanych produktach Atlassiana. Producent ocenia go jako krytyczny: 9,3 w CVSS 4.0.

Podstawą techniczną tej analizy jest biuletyn Atlassiana z 5 października. CISA dodała lukę do KEV 15 października i wyznaczyła amerykańskim agencjom federalnym termin działania na 18 października. Termin ten nie jest prawnym obowiązkiem polskich firm, lecz krótki czas reakcji dobrze pokazuje operacyjną pilność problemu.

Wniosek Breachroad: nie kończ zadania na instalacji aktualizacji. Jeżeli instancja była dostępna z internetu, trzeba równolegle sprawdzić logi i ustalić, jakie dane lub sekrety mogły znajdować się w plikach aplikacji. Poprawka zamyka podatność, ale nie unieważnia wcześniej pobranych informacji.

Które produkty są objęte problemem

Biuletyn wymienia wszystkie wersje sprzed wydań naprawczych dla następujących produktów:

• Bitbucket Data Center;
• Confluence Data Center;
• Jira Service Management Data Center;
• Jira Software Data Center;
• Bamboo Data Center;
• Crowd Data Center;
• Crucible i Fisheye.

Atakujący musi znać dokładną nazwę i ścieżkę docelowego pliku. Podatność nie pozwala mu wyświetlić listy katalogu. Nie jest to jednak wystarczająca bariera: nazwy typowych plików, układ popularnych instalacji i informacje zdobyte wcześniej mogą pomóc odgadnąć cel. Ryzyko zależy więc także od tego, jakie pliki są obecne w katalogu aplikacji i co zawierają.

Atlassian informuje, że objęte problemem usługi Cloud zostały poprawione, a jego dochodzenie nie znalazło tam dowodów wykorzystania. Klient chmury nie musi wykonywać działań opisanych dla własnej instalacji. Najpierw ustal model usługi — nazwa Jira lub Confluence sama nie odpowiada na pytanie, czy aktualizacją zarządza firma, partner czy Atlassian.

Wersje, do których trzeba zaktualizować

Atlassian rekomenduje najnowsze wydanie lub co najmniej odpowiednią wersję naprawczą:

• Bitbucket Data Center: 9.4.26, 10.2.8 albo 10.5.1;
• Confluence Data Center: 9.2.26 albo 10.2.19;
• Jira Service Management Data Center: 5.12.40, 10.3.26 albo 11.3.12;
• Jira Software Data Center: 9.12.40, 10.3.26 albo 11.3.12;
• Bamboo Data Center: 10.2.24 albo 12.1.12;
• Crowd Data Center: 6.3.7, 7.0.3, 7.1.7 albo 7.2.4;
• Crucible i Fisheye: 4.9.15.

Wybierz wydanie należące do właściwej, wspieranej gałęzi produktu. Nie porównuj samych liczb między gałęziami i nie zakładaj, że dowolna nowsza wersja z innej linii jest odpowiednim celem migracji. W klastrze sprawdź każdy węzeł, a w Bitbucket również mirrory i węzły mirror farm.

Jeżeli natychmiastowa aktualizacja nie jest możliwa, producent zaleca usunięcie instancji z internetu. Opisuje też regułę WAF lub reverse proxy filtrującą warianty przejścia między katalogami oraz osobne mitygacje dla Tomcata i Bitbucket. To rozwiązania tymczasowe, które trzeba pobrać bezpośrednio z bieżącego biuletynu, przetestować i wdrożyć na wszystkich węzłach. Nie zastępują poprawki.

Jak szukać śladów wykorzystania

Atlassian zaleca analizę logów dostępowych wszystkich objętych instancji. Linie żądań należy zdekodować do dwóch razy, a następnie wyszukać .. przylegające do /, \ lub ::. Alternatywą jest wyszukiwanie w surowych logach wyrażeniem regularnym podanym przez producenta.

Samo dopasowanie może oznaczać próbę, a nie udany odczyt pliku. Z kolei brak dopasowania nie zawsze zamyka analizę: retencja mogła być zbyt krótka, logi mogły ominąć część ruchu albo instancja mogła być dostępna inną ścieżką. Dlatego połącz logi aplikacji, reverse proxy, WAF, load balancera i źródła sieciowe. Zapisz zakres czasu, kompletność danych oraz każdy brak w telemetrii.

Warto ustalić, czy żądanie otrzymało odpowiedź, jaki był rozmiar transferu i czy podobny wzorzec dotyczył kilku produktów. Nie należy jednak publikować lub automatycznie blokować adresów IP jako jedynego wskaźnika — infrastruktura atakującego może być współdzielona lub szybko zmieniana.

Co zrobić, jeżeli plik mógł zostać pobrany

Najpierw zachowaj dowody i zinwentaryzuj możliwy zakres. Ustal, jakie pliki znajdowały się pod wskazanymi ścieżkami w czasie zdarzenia. Oceń, czy zawierały hasła, tokeny, klucze prywatne, dane połączeń, konfigurację SSO, informacje o bazie danych lub inne dane ułatwiające następny etap ataku.

Następnie unieważnij i wymień zagrożone sekrety zgodnie z ich zasięgiem. Sam restart aplikacji nie zmienia skradzionego tokenu. Sprawdź aktywność kont i usług, do których te dane mogły otwierać dostęp, a także nietypowe logowania i zmiany po czasie prawdopodobnego odczytu. Jeśli plik zawierał dane osobowe lub poufne informacje klientów, włącz właściciela biznesowego, prawników i zespół odpowiedzialny za obowiązki zgłoszeniowe.

To są zalecenia Breachroad wynikające z możliwego wpływu odczytu plików. Biuletyn Atlassiana potwierdza zakres produktów, mechanizm podatności, wersje naprawcze i sposób wyszukiwania żądań; nie przesądza, który plik został pobrany w konkretnej organizacji.

Plan na pierwsze godziny

1. Zidentyfikuj wszystkie własne instancje, klastry, mirrory i ich ekspozycję.
2. Zachowaj logi, snapshoty konfiguracji i oś czasu przed zmianami.
3. Ogranicz publiczny dostęp, jeżeli poprawka nie może wejść natychmiast.
4. Zaktualizuj do właściwej wersji i potwierdź stan każdego węzła.
5. Przeszukaj zdekodowane oraz surowe logi zgodnie z instrukcją producenta.
6. Dla podejrzanych odczytów ustal treść pliku, obróć sekrety i rozszerz dochodzenie.
7. Udokumentuj wynik: co sprawdzono, jakimi danymi i z jakimi ograniczeniami.

Taką kolejność warto mieć gotową, zanim pojawi się następny wpis w KEV. Pomaga w tym dojrzały proces zarządzania podatnościami połączony z planem reagowania na incydenty. Zespoły IT, bezpieczeństwa i właściciele usług mogą przećwiczyć wspólne decyzje podczas szkoleń cyberbezpieczeństwa dla organizacji.