Luka w Jira i Confluence już w atakach: co załatać

Luka w Jira, Confluence, Bitbucket i Bamboo w wersjach Data Center pozwala obcym bez logowania czytać pliki z katalogu aplikacji na firmowym serwerze, a napastnicy już z niej korzystają. 15 października 2026 roku amerykańska agencja CISA dopisała lukę CVE-2026-21589 do katalogu podatności wykorzystywanych w atakach. Atlassian wydał poprawki 5 października, a dzień później badacze z watchTowr opublikowali opis ataku z gotowym kodem. Chmura Atlassiana jest już załatana, więc problem mają tylko instalacje u siebie.

Czym jest luka CVE-2026-21589 i kogo dotyczy

CVE-2026-21589 to luka w sześciu produktach Atlassian Data Center oraz w Crucible i Fisheye instalowanych u siebie, która pozwala napastnikowi bez konta odczytać wybrane pliki z katalogu głównego aplikacji WWW. Według komunikatu Atlassiana podatne są wszystkie wersje sprzed poprawki: Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo i Crowd w edycji Data Center oraz Crucible i Fisheye. Producent ocenia lukę na 9,3 w dziesięciostopniowej skali, czyli jako krytyczną.

Luka pozwala tylko czytać pliki, napastnik nie uruchomi przez nią kodu na serwerze. Napastnik musi znać dokładną nazwę i ścieżkę pliku, katalogów listować nie może. Atlassian dodaje jednak, że w niektórych konfiguracjach w tym katalogu leżą pliki wrażliwe, które podnoszą ryzyko. Klienci chmury nie muszą nic robić: Atlassian załatał ją sam i według komunikatu nie znalazł śladów wykorzystania.

Skąd tyle produktów naraz? Według analizy watchTowr błąd siedzi we wspólnej bibliotece atlassian-plugins-webresource, która serwuje obrazki i skrypty. Zamienia ona podwójny dwukropek :: na ukośnik, przez co ścieżka z ..:: przechodzi kontrolę i wychodzi poza folder z zasobami.

Wersje z poprawką: tabela dla administratora

Atlassian zaleca przejście na wersję z poprawką w swojej gałęzi długoterminowego wsparcia (LTS) albo na nowszą. Jeśli Twoja wersja nie należy do żadnej gałęzi z tabeli, przejdź na wspieraną gałąź i zainstaluj wskazaną wersję z poprawką albo nowszą. Przy klastrze aktualizacja dotyczy każdego węzła.

Starsze edycje Server w komunikacie w ogóle nie występują. Atlassian zakończył ich wsparcie 15 lutego 2024 roku i od tamtej pory nie wydaje dla nich poprawek. Komunikat nie rozstrzyga, czy ta luka ich dotyczy. Instalację Server dostępną z internetu warto naszym zdaniem odizolować i tak, jako system bez wsparcia, niezależnie od tej luki.

Pierwsza Misja AI · Kodożercy

Zagrożenia AI rozumie ten, kto wie, jak ona działa

Kurs Pierwsza Misja AI ma osobną lekcję o ciemnej stronie AI: halucynacje, deepfakes, manipulacja. Zanim zaczniesz się bać, zacznij rozumieć.

Poznaj pełny program →

Co napastnik może odczytać i dlaczego to groźne

Najgroźniejszy znany scenariusz dotyczy firm, które łączą Jirę z Crowdem, czyli katalogiem użytkowników Atlassiana. Badacze watchTowr pokazali go w swoim laboratorium. Najpierw odczytali plik WEB-INF/classes/crowd.properties, w którym Jira trzyma nazwę i hasło aplikacji do Crowda zapisane jawnym tekstem. Potem zalogowali się tymi danymi do Crowda, założyli nowe konto i dopisali je do grupy jira-administrators.

Ten scenariusz pokazali badacze. Ani CISA, ani Atlassian nie podają, kto wykorzystuje lukę, w jaki sposób i ile jest ofiar. watchTowr sam zastrzega, że lista dozwolonych adresów IP w Crowdzie mocno utrudnia ten scenariusz. Bez Crowda odczyt plików konfiguracyjnych nadal jest groźny, bo daje napastnikowi mapę instalacji do kolejnego ataku.

Czas na reakcję był krótki. Kod ataku i narzędzie do sprawdzania podatności watchTowr opublikował 6 października. Firma CrowdSec, która zbiera dane z sieci czujników, zarejestrowała pierwsze pasujące żądania już 7 października. Około 88% ruchu z pierwszych pięciu dni pochodziło jednak z jednego skanera badawczego. CrowdSec zaznacza też, że nie wie, czy którakolwiek próba się udała.

Jak zabezpieczyć Jirę i Confluence, jeśli nie możesz zaktualizować dziś

Pierwszy krok według Atlassiana to odciąć instancję od internetu do czasu poprawki. Dotyczy to także instalacji schowanych za logowaniem, bo atak nie wymaga konta. Jeśli odcięcie nie wchodzi w grę, komunikat daje trzy obejścia:

1. Reguła w zaporze aplikacyjnej (WAF) albo na serwerze pośredniczącym, dla wszystkich produktów. Blokuje adresy, w których dwie kropki .. stoją tuż obok /, \ albo ::, także w postaci zakodowanej. Gotowe wyrażenie regularne jest w komunikacie. Po wdrożeniu trzeba sprawdzić, czy reguła łapie też zakodowane warianty.
2. RewriteValve w Tomcacie, czyli mechanizm serwera, który blokuje albo przepisuje podejrzane adresy. Dotyczy Confluence, Jiry, Jira Service Management, Bamboo i Crowda. Najpierw kopia zapasowa, potem na każdym węźle klastra: zatrzymanie węzła, wpis w server.xml, plik rewrite.config w katalogu WEB-INF i ponowne uruchomienie.
3. Reguła w urlrewrite.xml tylko dla Bitbucketa, wstawiona przed innymi regułami. Trzeba ją dodać na wszystkich węzłach, na wszystkich serwerach lustrzanych (mirrorach) i węzłach ich farm, a potem ponownie uruchomić Bitbucketa.

Crucible i Fisheye mają w komunikacie tylko pierwszą opcję, czyli regułę WAF.

Jak sprawdzić logi, czy ktoś już próbował

Atlassian nie potwierdzi za Ciebie, czy instancja była zaatakowana, i każe sprawdzić to własnemu zespołowi bezpieczeństwa. Producent podaje dwie metody przeszukania logów dostępowych serwera WWW:

1. Zdekoduj każdy wiersz żądania z zapisu URL, najwyżej dwa razy, i szukaj .. tuż obok /, \ albo ::.
2. Albo przeszukaj surowe, niezdekodowane wiersze tym samym wyrażeniem regularnym, którego używa reguła WAF.

Trafienie w logu oznacza próbę ataku, która mogła się nie udać. Aktualizacja zamyka lukę, ale nie cofa tego, co ktoś mógł odczytać wcześniej. Kto łączy Jirę z Crowdem i miał ją wystawioną do internetu po 5 października, powinien naszym zdaniem po aktualizacji zmienić hasło aplikacji z crowd.properties i przejrzeć członków grup administratorów. Tego zalecenia nie ma w komunikacie Atlassiana, wynika ono z demonstracji watchTowr.

Termin CISA 18 października nie wiąże polskich firm

Termin wynika z dyrektywy BOD 26-04 i wiąże federalne agencje cywilne w USA. Dla polskiego administratora wpis w katalogu CISA znaczy co innego: agencja ma dowody, że luka jest wykorzystywana. Przy tej pozycji CISA wymaga od agencji także sprawdzenia śladów włamania, nie tylko instalacji poprawki. Podobny schemat, czyli poprawka, publiczny kod ataku i próby w ciągu doby, opisywaliśmy przy lukach zero-day z połowy października i luce w TeamCity.

{ dla firm }

Co możemy zrobić dla Twojej firmy?

Budujemy strony, sklepy i aplikacje, łączymy systemy z KSeF i księgowością, wdrażamy automatyzacje i agentów AI, a na koniec dbamy o widoczność w Google. Zaczynamy od rozmowy o tym, co dziś zabiera Twojemu zespołowi najwięcej czasu.

strony i sklepyaplikacjeKSeF i integracjeautomatyzacjeagenci AISEO

Zobacz, co robimy dla firm → Software house, który prowadzi ten blog

Podsumowanie

Luka w Jira, Confluence, Bitbucket, Bamboo i Crowd w edycjach Data Center oraz w Crucible i Fisheye pozwala bez logowania odczytać pliki z katalogu aplikacji. Od 15 października 2026 roku jest w katalogu CISA jako wykorzystywana w atakach. Poprawki istnieją od 5 października, a publiczny kod ataku od 6 października. Chmura Atlassiana jest załatana, a edycji Server, wspieranych do lutego 2024 roku, komunikat nie obejmuje. Najgroźniejszy znany scenariusz prowadzi przez hasło do Crowda, choć na razie pokazali go tylko badacze. Zaktualizuj każdy węzeł do wersji z tabeli. Do tego czasu odetnij instancję od internetu albo wdróż obejście z komunikatu Atlassiana, a potem przejrzyj logi dostępowe od 5 października.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.