Dwa Narzędzia Open Source Padły w Kilka Godzin

Inżynier Stawia Panel, Tylko Dla Zespołu

Inżynier w średniej firmie stawia serwer śledzący MLflow na wewnętrznej maszynie wirtualnej, aby zespół data science mógł rejestrować eksperymenty i porównywać przebiegi modeli. MLflow nie pyta o nazwę użytkownika ani hasło podczas instalacji, więc żadne nie zostaje skonfigurowane, a serwer wchodzi do sieci za czymś, co wszyscy uznają za sieć prywatną. W fabryce kilkaset kilometrów dalej inżynier utrzymania ruchu robi coś podobnego: stawia FUXA, otwartoźródłową platformę SCADA i HMI, aby dać zespołowi widok w przeglądarce na tagi linii produkcyjnej. Żaden z tych systemów nie został zbudowany, by być osiągalny z otwartego internetu, i żaden zespół tego nie sprawdził.

W tygodniu od 18 sierpnia 2026 roku oba założenia okazały się błędne jednocześnie. MLflow, platforma do śledzenia eksperymentów hostowana pod LF Projects w Linux Foundation, oraz FUXA, zupełnie niezwiązane narzędzie do przemysłowych systemów sterowania, ujawniły każde krytyczną, domyślnie nieuwierzytelnioną lukę - a w obu przypadkach atakujący mieli działające exploity w ciągu kilku godzin od publicznego ujawnienia, nie tygodni. Dwie różne bazy kodu, dwie różne branże, dwa zespoły, które nigdy się ze sobą nie koordynowały. To, co łączy te przypadki, to jedna decyzja projektowa, podjęta niezależnie, w odstępie lat, z tego samego powodu: szybciej jest wydać narzędzie z wyłączonym uwierzytelnianiem niż z włączonym.

Luka w MLflow Zamienia Przekierowanie w Kradzież Poświadczeń

Luka w MLflow, oznaczona jako CVE-2026-64849, ma wynik CVSS 9,3. To obejście walidacji adresu URL webhooka: MLflow pozwala rejestrować webhooki, które uruchamiają się przy zdarzeniach takich jak zakończony przebieg treningu, i sprawdza adres docelowy przed zezwoleniem na to, aby serwer nie mógł wskazywać na adresy wewnętrzne. Atakujący odkryli, że mogą obejść tę kontrolę, łącząc przekierowanie HTTP z DNS rebinding - rejestrują webhook na adres, który przechodzi walidację, a następnie w momencie żądania pozwalają mu rozwiązać się do wewnętrznego adresu IP, którego walidator nigdy nie widział. GitLab opublikował poradnik bezpieczeństwa dotyczący tej luki, a exploit został niezależnie potwierdzony przez serwisy zajmujące się cyberbezpieczeństwem, takie jak cybersecuritynews, cyberpress i GBHackers.

Korzyścią dla atakującego jest server-side request forgery: to sam serwer MLflow staje się tym, który wysyła żądanie, od wewnątrz sieci, w której się znajduje. Pozwala to atakującemu dotrzeć do wewnętrznych usług, które nigdy nie miały być widoczne na zewnątrz, a co kluczowe, do punktów końcowych metadanych instancji chmurowych w AWS, Azure i GCP - wewnętrznych adresów, które wydają tymczasowe poświadczenia maszynie, która o nie pyta. Ponieważ serwery śledzące MLflow często działają bez uwierzytelniania w rzeczywistych wdrożeniach, nic nie powstrzymuje zewnętrznego atakującego przed wysłaniem tego pierwszego żądania. The Hacker News poinformował 18 sierpnia 2026 roku, że aktywne wykorzystywanie luki zaczęło się w ciągu kilku godzin od ujawnienia.

Luka w FUXA Pozwala Osobom z Zewnątrz Zapisywać Pliki w Systemach Fabrycznych

FUXA to otwartoźródłowa platforma SCADA i HMI - rodzaj oprogramowania, które daje operatorom fabryki okno w przeglądarce na urządzenia faktycznie sterujące linią produkcyjną. Jej luka, CVE-2026-25895, ma jeszcze wyższy wynik niż MLflow, 9,5, a mechanizm jest bardziej bezpośredni: brak uwierzytelniania połączony z luką path traversal. Nieuwierzytelniony atakujący może wysłać żądanie, które wymyka się z katalogu, do którego FUXA spodziewa się zapisywać, i umieścić plik w dowolnym miejscu w bazowym systemie plików, jakie wybierze.

Dowolny zapis pliku to nie zwykły błąd ujawnienia danych, to punkt zaczepienia. Atakujący, który może zapisywać pliki tam, gdzie chce, w systemie komunikującym się z urządzeniami przemysłowymi, może umieścić w nim kod wykonywalny i uzyskać zdalne wykonanie kodu, co oznacza pełną kontrolę nad hostem, na którym działa HMI - a w zależności od tego, jak ten host jest połączony z halą produkcyjną, także drogę do samych systemów sterowania. Podobnie jak w przypadku MLflow, The Hacker News oraz te same potwierdzające serwisy poinformowały, że aktywne wykorzystywanie luki zaczęło się w ciągu kilku godzin od publicznego ujawnienia, w tym samym tygodniu co poradnik dotyczący MLflow.

Wspólnym Wątkiem Nie Jest Kod, Lecz Ustawienie Domyślne

MLflow i FUXA nie mają wspólnego kodu, opiekunów ani rynku. Jedno śledzi eksperymenty uczenia maszynowego, drugie wizualizuje przemysłowe systemy sterowania, a ujawniono je niezależnie w tym samym tygodniu przez czysty zbieg terminów. To, co je łączy, to ustawienie domyślne: wydawanie bez uwierzytelniania, ponieważ jest to najszybszy sposób na uruchomienie narzędzia dla małego wewnętrznego zespołu, oraz ponieważ zespół zakłada, że otaczająca go sieć jest prywatna. To założenie to cała powierzchnia ataku.

To samo ustawienie domyślne kryje się za dużą częścią wewnętrznych narzędzi, których właściciele firm nigdy osobiście nie sprawdzają: panele MLOps, stosy monitorujące, wewnętrzne panele administracyjne oraz systemy SCADA/HMI w całym przemyśle wytwórczym. Każdy z nich prawdopodobnie postawiono szybko, przez kogoś kompetentnego, rozwiązującego realny problem, kto nigdy nie wrócił, by włączyć uwierzytelnianie, bo nic go do tego nie zmusiło. Luka między tym, co uznaje się za prywatne, a tym, co jest naprawdę osiągalne - czy to przez bezpośrednią ekspozycję w internecie, czy, jak w przypadku MLflow, przez przeskok SSRF z systemu, który jest osiągalny - to dokładnie tam, gdzie wylądowały oba exploity, i to tam wyląduje też następny.

Kilka Godzin Do Wykorzystania Luki To Teraz Prawdziwe Okno Na Łatanie

Dla każdej firmy w UE lub Wielkiej Brytanii, która prowadzi potoki MLOps - coraz częstsze, w miarę jak firmy wdrażają własną infrastrukturę ML i AI - lub każdej firmy przemysłowej czy produkcyjnej, która prowadzi systemy SCADA lub HMI, praktyczną odpowiedzią jest audyt, a nie notatka polityczna. Każde wewnętrzne narzędzie potrzebuje bezpośredniej odpowiedzi na jedno pytanie: czy uwierzytelnianie jest naprawdę włączone, a nie tylko zakładane, i czy narzędzie jest naprawdę nieosiągalne spoza sieci, w której ma według założeń żyć. MLflow i FUXA pokazują oba, że uczciwa odpowiedź często brzmi nie, i że nikt się o tym nie dowiaduje, dopóki luka nie zostanie wykorzystana.

Druga zmiana dotyczy zegara. Obie luki przeszły od publicznego ujawnienia do aktywnego wykorzystania w ciągu godzin, a nie tygodni, które tradycyjnie zakładały cykle łatania. Dla operatorów przemysłowych z siedzibą w UE w szczególności nie jest to wyłącznie problem techniczny: obowiązki NIS2 obejmują dostawców infrastruktury cyfrowej oraz, co istotne, operatorów produkcyjnych i przemysłowych prowadzących systemy OT i SCADA, co sprawia, że niezałatany, nieuwierzytelniony HMI to błąd zgodności w takim samym stopniu jak błąd bezpieczeństwa. Rozwiązanie nie jest egzotyczne - włączyć uwierzytelnianie, łatać w dniu ujawnienia, zakładać, że nic za zaporą sieciową nie jest naprawdę prywatne - ale musi się to wydarzyć, zanim wydarzy się exploit, a w tym tygodniu tę lukę zmierzono w godzinach.

Czytaj dalej: Wyciek, którego nie wyjaśni rejestr DORA  |  Shell i Philips stracili rysunki, nie hasła