Większość serwerów Artifactory wciąż jest podatna

Trzy poprawki, jeden łańcuch ataku

JFrog wydał poprawki do trzech odrębnych podatności Artifactory od 27 lipca 2026 roku, a atakujący spędzili tygodnie na łączeniu pierwszych dwóch, zanim trzecia stała się publiczna.

CVE-2026-42016 pozwala wymienić token o niskich uprawnieniach na token z uprawnieniami administratora. CVE-2026-42018 wydaje wewnętrzny token anonimowego użytkownika osobie, która nigdy się nie zalogowała, nawet gdy dostęp anonimowy jest wyłączony. CVE-2026-82329, ujawniona 28 sierpnia z oceną CVSS na poziomie 9,8, pozwala niezautoryzowanemu atakującemu zdobyć uprawnienia administratora wprost w domyślnej konfiguracji.

Dokładne kroki, które zmieniają gościa w administratora

Firma bezpieczeństwa Wiz opisała dokładny mechanizm: atakujący wysyłają żądanie POST do /access/api/v1/aws/token/, z ukośnikiem na końcu, które zwraca anonimowy JWT, mimo że dostęp anonimowy jest wyłączony. Następnie wysyłają ten token do /access/api/v1/tokens, aby zażądać tokena z uprawnieniami administratora, który Artifactory wydaje bez odpowiedniego sprawdzenia rzeczywistego poziomu uprawnień żądającego.

W przypadku najnowszego błędu, CVE-2026-82329, Wiz znalazł jeszcze bardziej bezpośredni skrót: jeden POST do /access/api/v1/registry/join zwraca wprost token administratora, bez potrzeby łączenia niczego. Po wejściu do środka atakujący tworzyli trwałe konta administratora, instalowali złośliwe wtyczki Groovy przez wbudowany w Artifactory framework wtyczek, aby uruchamiać kod na serwerze, a w niektórych przypadkach wgrywali backdoory napisane w Rust z możliwością zdalnego dowodzenia i kontroli. Wiz zaobserwował połączone ataki trwające od 15 sierpnia do 8 września 2026 roku, z odrębną falą wykorzystującą CVE-2026-82329 od 1 do 8 września.

Naprawione nie znaczy rozwiązane

Przepaść między istnieniem poprawki a serwerem, który faktycznie ją stosuje, jest tutaj prawdziwą historią i mierzy się ją w miesiącach, nie w dniach. JFrog naprawił CVE-2026-42016 w wersji 7.133.11 27 lipca; sześć tygodni później, według telemetrii Wiz, wciąż 59 procent organizacji było na niego podatnych.

CVE-2026-42018 nie wypadł lepiej: naprawiony w pięciu odgałęzieniach wersji do 12 sierpnia, cztery tygodnie później wciąż 62 procent organizacji było narażonych. CVE-2026-82329 poruszał się najszybciej, spadając z 67 procent podatnych przy ujawnieniu do 49 procent po dwóch tygodniach, ale to wciąż pozostawia niemal połowę wszystkich wdrożeń Artifactory otwartych na błąd o wadze 9,8 z 10. Skala automatycznych prób wykorzystania przeciwko niezałatanym serwerom nie jest teoretyczna: Fastly zarejestrował około 406 tysięcy prób wykorzystania CVE-2026-82329 w jednym dniu, 2 września, tego samego dnia, w którym CISA dodała go do swojego katalogu znanych wykorzystywanych podatności.

Obowiązek unijny, którego jeszcze nikt nie wymusza

CISA dała amerykańskim agencjom federalnym twardy termin, 5 września, trzy dni po dodaniu CVE-2026-82329 do swojego katalogu KEV 2 września. UE nie ma podobnego publicznego, datowanego nakazu dla firm prywatnych, choć artykuł 21 dyrektywy NIS2 już nakazuje wielu średnim firmom programistycznym i usługowym z branży IT prowadzenie udokumentowanego procesu zarządzania podatnościami, który obejmuje właśnie ten typ niezałatanego narzędzia łańcucha dostaw wystawionego na internet.

To pozostawia realną dziurę dla każdej firmy z siedzibą w UE, która sama hostuje Artifactory: istnieje prawny obowiązek zarządzania tym ryzykiem na podstawie NIS2, ale nie ma opublikowanego krajowego lub ogólnounijnego terminu, który wymuszałby tę sprawę tak, jak robi to nakaz CISA w Stanach Zjednoczonych. Na razie jedynym wiarygodnym motorem do załatania instancji Artifactory hostowanej w UE jest własny zespół bezpieczeństwa firmy, który czyta ostrzeżenie dostawcy i działa na jego podstawie, a nie zegar regulatora.

Czytaj dalej: Najgorzej Oceniona Luka w GitLabie Wymaga Tylko Jednego Publicznego Projektu  |  Błąd Zepsuł Dokładnie To, Od Czego Zależy Łatanie