Administratorze, spokojnie, to dopiero piątek…

Są takie dni w branży IT, kiedy administratorzy kończą pracę o siedemnastej, zamykają laptopy i spokojnie wracają do rodzin. Środa, 21 października 2026 roku, zdecydowanie do nich nie należała. Dwie krytyczne luki w PHP, podatność w GitLabie oceniona na maksymalne 10 punktów, złośliwe oprogramowanie przemycone do popularnej biblioteki AI, wyciek sekretów z platformy chmurowej i klucz kryptograficzny będący dosłownie liczbą 4. A to przecież nie wszystkie atrakcje. Gdzieś na świecie ktoś zapewne właśnie rozważa zmianę zawodu. Hodowla alpak zaczyna wyglądać rozsądnie.

Zaczęło się od PHP. A właściwie od dwóch krytycznych podatności, które pozwalają atakującemu na zdalne wykonanie kodu bez konieczności logowania. Problem jest o tyle niewygodny, że PHP stanowi fundament ogromnej części współczesnego internetu. WordPress, Joomla, Drupal, Magento, MediaWiki i niezliczone aplikacje biznesowe korzystają z tego środowiska.

Oczywiście nie oznacza to, że każda strona internetowa automatycznie padła ofiarą ataku. Wystarczy jednak odpowiednio stara wersja interpretera, żeby nawet poprawnie napisana aplikacja stała się potencjalnie niebezpieczna.

Kiedy szczegóły zaczęły przedwcześnie wydostawać się do sieci, organizacje odpowiedzialne za cyberbezpieczeństwo postanowiły nie owijać w bawełnę. NSA, brytyjskie NCSC i europejskie instytucje alarmowały, że systemy trzeba pilnie aktualizować, a jeżeli nie jest to możliwe, rozważyć ich czasowe odłączenie.

I tu zaczęła się zabawa.

Holenderskie serwisy administracji publicznej, w tym DigiD i MijnOverheid, zostały profilaktycznie wyłączone. Problemy z dostępnością dotknęły również strony parlamentu oraz innych instytucji. Swoją witrynę wyłączyło nawet holenderskie Narodowe Centrum Cyberbezpieczeństwa. Instytucja, która na co dzień informuje innych, jak zabezpieczać systemy, sama musiała zastosować najbardziej radykalny wariant własnych zaleceń.

Z kolei w Wielkiej Brytanii 22 października potwierdzono czasowe wyłączenie 32 usług administracji rządowej i ograniczenie działania kolejnych czterech. Profilaktycznie zawieszano również inne serwisy, w tym należące do organizacji Wikimedia i Internet Archive.

Nasze władze również zareagowały wyłączeniem części stron:

– W związku z wykryciem luk w zabezpieczeniach PHP, czyli technologii wykorzystywanej przez wiele serwisów internetowych na całym świecie, podjęliśmy decyzję o czasowym wyłączeniu stron Biuletynu Informacji Publicznej (BIP) działających w Systemie Scentralizowanego Dostępu do Informacji Publicznej (SSDIP) – podał na portalu X Centralny Ośrodek Informatyki.

O zagrożeniu poinformował m.in. CERT Polska, który zalecił podjęcie działań zapobiegawczych.

Sprawa zrobiła się tak poważna, że publiczny apel wystosowała premier Japonii Sanae Takaichi. Wieczorem 21 października wezwała administratorów do natychmiastowego przygotowania aktualizacji. Dzień później przyznała, że również jej oficjalna strona internetowa została tymczasowo wyłączona.

Kiedy szef rządu zaczyna przypominać o aktualizowaniu PHP, można uznać, że problem wyszedł daleko poza zwykły dyżur administratora.

Poprawki ostatecznie pojawiły się 21 października. Problem w tym, że według Amazon Threat Intelligence pierwsze próby wykorzystania podatności zarejestrowano już cztery dni wcześniej. Administratorzy nie walczą więc wyłącznie z koniecznością aktualizacji. Muszą również sprawdzić, czy przypadkiem ktoś nie zdążył ich odwiedzić.

Aktualizować czy nie aktualizować? Oto jest pytanie

Gdy wydawało się, że PHP zapewni wystarczająco dużo pracy na najbliższe dni, do „imprezy” dołączył GitLab.

Firma opublikowała poprawki dla podatności CVE-2026-110264, ocenionej na 10 punktów w skali CVSS. To maksymalna możliwa nota. Luka w określonych warunkach pozwala na wykonanie kodu bez uwierzytelnienia i dotyczy wersji sięgających GitLaba 7.0, czyli roku 2014.

Dwanaście lat. W świecie technologii to niemal epoka geologiczna. Przez ten czas zdążyliśmy przeżyć kilka rewolucji sprzętowych, pojawienie się generatywnej AI i niezliczone dyskusje o przyszłości programowania. A gdzieś w kodzie cierpliwie czekał sobie błąd.

Administrator, który właśnie skończył aktualizować PHP, może zatem otworzyć kolejny terminal i zabrać się za GitLaba. Oczywiście najpierw powinien sprawdzić, czy nie doszło już do naruszenia bezpieczeństwa.

Żeby admini przypadkiem nie zdążyli się znudzić, do akcji wkroczył również Fortinet. Producent rozwiązań bezpieczeństwa 21 października zapowiedział pilne aktualizacje FortiOS, FortiManager i FortiAnalyzer, których udostępnienie zaplanowano na następny dzień.Powód? Kolejne podatności wykryte między innymi dzięki wykorzystaniu zaawansowanych modeli sztucznej inteligencji. Firma apeluje o jak najszybsze wdrożenie poprawek, zwłaszcza na urządzeniach dostępnych z internetu. Jest tylko jeden drobny szczegół.

Pełne informacje o usuwanych lukach Fortinet zamierza opublikować dopiero 10 listopada. Administrator ma więc pilnie aktualizować urządzenia odpowiedzialne za bezpieczeństwo sieci, choć jeszcze nie wie dokładnie, przed czym je zabezpiecza. A jeśli komuś mało atrakcji, na początku października firma ostrzegała już przed aktywnie wykorzystywaną podatnością CVE-2026-104286 w FortiMailu, ocenioną na 9,8 punktu w skali CVSS.

Najwyraźniej nawet urządzenia, które mają chronić nas przed cyberatakami, postanowiły w tym tygodniu dołączyć do listy rzeczy wymagających natychmiastowego ratowania.

Ale prawdziwa ironia pojawia się przy LiteLLM.

Popularny projekt wykorzystywany do obsługi modeli językowych padł ofiarą ataku na łańcuch dostaw oprogramowania. Złośliwa wersja 1.107.0 trafiła do PyPI, a także oficjalnych obrazów Docker. Zawierała kod kradnący dane uwierzytelniające i mechanizm umożliwiający zdalne wykonywanie poleceń.

Najlepsze, choć tylko z punktu widzenia wyjątkowo czarnego humoru, jest to, że nie trzeba było nawet importować zainfekowanej biblioteki. Wystarczało jej zainstalowanie i późniejsze uruchomienie Pythona w takim środowisku.

Wyobraźmy sobie administratora, który właśnie wykonuje rutynową aktualizację pakietów, aby zwiększyć bezpieczeństwo. Tyle że tym razem instalacja poprawki może oznaczać wpuszczenie przestępcy do środka.

Złośliwe wydanie szybko wycofano, ale użytkownicy, którzy zdążyli je pobrać i uruchomić, muszą zakładać możliwość utraty sekretów. A ponieważ LiteLLM często pracuje w środowiskach integrujących wiele usług AI, liczba potencjalnych kluczy do wymiany potrafi być naprawdę imponująca.

Chmura też potrzebuje administratora

W międzyczasie Railway poinformował o nieautoryzowanym dostępie do systemów przechowujących zmienne środowiskowe klientów. Mogły one zawierać klucze API, hasła do baz danych i inne poufne informacje.

Firma zaleciła wymianę wszystkich sekretów zapisanych na platformie. Jednocześnie, na czas prowadzonego dochodzenia, wstrzymała wdrożenia aplikacji.

Trudno wymyślić bardziej niewdzięczny scenariusz. Dostawca mówi, żeby natychmiast wymienić klucze, ale jednocześnie ogranicza możliwość wdrożenia aplikacji z nowymi ustawieniami. Część usług uruchomiono ponownie 22 października, jednak przywracanie pełnej funkcjonalności przebiegało etapami.

To nie koniec problemów z chmurą. PingCAP ujawnił, że od 9 września do 7 października nieuprawniona osoba korzystała ze skradzionych danych uwierzytelniających, uzyskując dostęp do części wewnętrznych systemów i kopiując informacje. Firma podkreśla, że nie znalazła dowodów naruszenia danych przechowywanych w samych bazach TiDB, ale dochodzenie dotyczące zakresu incydentu trwa.

Z kolei Zeabur po drugim incydencie bezpieczeństwa w ciągu kilku miesięcy zdecydował się zakończyć działalność platformy. Usługi mają zostać ostatecznie wyłączone do końca grudnia. Firma wskazuje także na problemy organizacyjne i biznesowe.

Dla klientów oznacza to kolejne zadanie. Tym razem nie wystarczy wymienić hasła ani zainstalować aktualizacji. Trzeba jeszcze znaleźć nowego dostawcę i przenieść działające systemy.

A teraz proszę wpisać bezpieczne hasło. Na przykład 4

Na deser zostaje eMudhra, indyjski dostawca certyfikatów cyfrowych.

W październiku odkryto, że klucze prywatne ośmiu pośrednich urzędów certyfikacji tej firmy były tak słabe, że można je było odgadnąć praktycznie natychmiast. Jeden z nich miał wartość 4. Tak, dokładnie cztery. Nie cztery miliardy ani ciąg zaczynający się od czwórki.

Cztery!

Pozostałe miały równie kompromitujące wartości, liczące zaledwie dwie lub trzy cyfry. Tymczasem prawidłowy klucz P-384 powinien być losową liczbą z przestrzeni obejmującej około 10 do potęgi 115 możliwych wartości.

Mówimy o instytucji, której podstawowym zadaniem jest budowanie cyfrowego zaufania i której część infrastruktury kryptograficznej okazała się chroniona liczbami, jakie można spotkać na paragonie za zakupy.

Nie ma dowodów, że wszystkie certyfikaty wystawione przez firmę zostały skompromitowane. Problem dotyczył konkretnych certyfikatów pośrednich, ale potencjalne konsekwencje były na tyle poważne, że producenci przeglądarek zaczęli blokować poświadczenia od tego dostawcy.

Skończyło się tym, że wczoraj, 22 października, eMudhra ogłosiła wycofanie się z globalnego biznesu certyfikatów SSL/TLS.

Można więc powiedzieć, że historia zatoczyła koło. Firma zajmująca się potwierdzaniem wiarygodności innych sama straciła zaufanie.

Dobranoc. O ile system pozwoli

W całej tej historii najbardziej niepokojąca nie jest nawet liczba podatności. Każdy administrator wie, że błędy istniały, istnieją i będą istnieć. Istotne jest tempo, w jakim zaczynają się kumulować, oraz skala ich konsekwencji.

Jeszcze niedawno poważna luka bezpieczeństwa oznaczała zwykle analizę, wdrożenie poprawki i podwyższoną czujność. Teraz w ciągu kilkunastu godzin można otrzymać równocześnie ostrzeżenia dotyczące języka programowania, platformy DevOps, biblioteki AI, dostawcy chmury i infrastruktury certyfikatów.

Co więcej, część problemów odkrywamy dzięki sztucznej inteligencji. Wykrycie podatności PHP wspierały zaawansowane modele AI, a ich twórcy zapowiadają, że podobnych odkryć będzie przybywać. To świetna wiadomość dla bezpieczeństwa długoterminowego. Nieco mniej optymistyczna dla administratorów, którzy muszą nadążyć z wdrażaniem poprawek.

Pozostaje jeszcze pytanie, kto właściwie powinien za to wszystko odpowiadać. Administrator, który nie zaktualizował systemu wystarczająco szybko? Dostawca, którego zabezpieczenia zawiodły? Twórcy oprogramowania, którzy przez lata nie zauważyli podatności? A może organizacje, które oczekują stuprocentowej dostępności usług, ale niekoniecznie chcą inwestować w ludzi niezbędnych do jej zapewnienia?

Nie istnieje przecież przycisk „zabezpiecz wszystko”, choć najwyraźniej niektórzy wciąż wierzą, że znajduje się gdzieś obok „aktualizuj”.

Jeżeli z tego tygodnia wynika jakaś lekcja, to taka, że współczesna infrastruktura IT jest coraz bardziej zależna od elementów, nad którymi jej administratorzy mają coraz mniejszą kontrolę. Można mieć perfekcyjnie skonfigurowany firewall, rygorystyczne procedury i najnowsze narzędzia monitoringu, a i tak obudzić się z problemem, ponieważ ktoś gdzieś opublikował złośliwą bibliotekę albo wygenerował klucz kryptograficzny równy cztery.

A więc drodzy administratorzy, spróbujcie dzisiaj trochę odpocząć. Sprawdźcie tylko PHP, GitLaba, obrazy kontenerów, klucze API, certyfikaty, logi i status usług chmurowych.

I pamiętajcie, że jutro też może wydarzyć się coś ciekawego.

W końcu dziś jest dopiero piątek…