Luka CVE-2026-21589 w Jira i Confluence już atakowana. Ataki ruszyły 2 godziny po publikacji kodu

Krytyczna luka CVE-2026-21589 (CVSS 9,3) w produktach Atlassian Data Center jest już wykorzystywana w atakach. Firma Previdian zaobserwowała pierwsze próby ataków w swojej sieci pułapek (honeypotów) niespełna dwie godziny po tym, jak badacze z watchTowr opublikowali szczegółową analizę luki razem z działającym kodem ataku. O samej luce i wersjach z poprawką pisaliśmy we wczorajszym artykule.

Dwie godziny od publikacji do ataku

„W ciągu dwóch godzin od opublikowania przez watchTowr analizy technicznej i kodu dowodowego dla CVE-2026-21589 nasza sieć pułapek zaczęła rejestrować próby wykorzystania luki” — przekazał Ryan Dewhurst z Previdian.

Luka dotyczy ośmiu produktów w wersji Data Center: Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, Crucible i Fisheye. Pozwala bez logowania odczytać dowolny plik z katalogu głównego aplikacji. Według watchTowr przyczyną jest obsługa sekwencji ::, którą aplikacja zamienia na /, co pozwala obejść sprawdzanie ścieżki.

Skala narażenia jest duża: watchTowr naliczył w wyszukiwarce urządzeń FOFA około 700 tysięcy instancji Confluence widocznych z internetu.

Od odczytu pliku do konta administratora

Odczyt plików brzmi niegroźnie, ale w praktyce prowadzi do przejęcia systemu. W instalacjach połączonych z Atlassian Crowd napastnicy pobierają plik WEB-INF/classes/crowd.properties, w którym login i hasło aplikacji są zapisane otwartym tekstem. Z tymi danymi mogą założyć sobie konto administratora. watchTowr pokazał w ten sposób przejęcie uprawnień administratora Jiry.

Ataki zarejestrowane przez Previdian pochodziły z trzech adresów IP:

• 38.60.157[.]86
• 146.70.187[.]234
• 159.26.119[.]225

Warto sprawdzić, czy pojawiają się one w dziennikach serwera WWW i zapory. Ich brak niczego jednak nie dowodzi, bo kod ataku jest publiczny i skorzysta z niego każdy.

Co zrobić teraz

1. Zaktualizuj Jira, Confluence, Bitbucket, Bamboo, Crowd, Crucible i Fisheye do wersji z poprawką (tabela wersji jest w naszym poprzednim artykule).
2. Ogranicz dostęp z internetu do instancji Data Center: VPN albo lista dozwolonych adresów.
3. Dodaj w zaporze aplikacyjnej (WAF) lub serwerze pośredniczącym reguły blokujące sekwencje :: i .. w ścieżkach.
4. Przeszukaj dzienniki od 5 października pod kątem zapytań o crowd.properties i inne pliki konfiguracyjne.
5. Jeśli instancja była dostępna z internetu bez poprawki, zmień hasło aplikacji w Crowd, klucze i tokeny zapisane w plikach aplikacji oraz sprawdź listę administratorów, czy nie pojawiło się nowe konto.

Wersje w chmurze (Atlassian Cloud) nie są podatne.

Komentarz SecurHUB

Ten przypadek dobrze pokazuje, jak skrócił się czas na reakcję. Jeszcze kilka lat temu od komunikatu producenta do masowych ataków mijały tygodnie. Dziś bywa to kilka godzin od chwili, gdy w sieci pojawi się kod ataku. Firma, która aktualizuje systemy w comiesięcznym oknie serwisowym, przy takich lukach jest zawsze spóźniona. Dlatego systemy dostępne z internetu warto stale monitorować i mieć gotową procedurę pilnej aktualizacji. Pomagamy w tym w ramach monitoringu SOC 24/7 i testów penetracyjnych.

Źródła: BleepingComputer, watchTowr Labs, Atlassian, CERT Orange Polska