PHP2Shell: podatności w samym PHP
Błędy w obsłudze pamięci i procesów PHP mogły zagrozić aplikacji nawet wtedy, gdy sam CMS był aktualny.
Historia, skutki i wnioskiKRONIKA ZAGROŻEŃ / 2006-2026
Przypominamy podatności, które przez ostatnie 20 lat wpływały na bezpieczeństwo stron i serwerów. Wyjaśniamy, co się wydarzyło, jakie były skutki i czego mogą nauczyć administratorów.
Przejdź do chronologii ↓
WIEDZA I PRAKTYKA
Dbanie o bezpieczeństwo to codzienna praca: śledzenie ostrzeżeń, sprawdzanie, których usług dotyczy zagrożenie, instalowanie poprawek i szukanie śladów ewentualnego włamania. Właśnie tak rozumiemy rolę Prywatnego Informatyka. Kronika pokazuje, dlaczego ta praca trwa również wtedy, gdy strona działa prawidłowo.
OD NAJNOWSZYCH DO NAJSTARSZYCH
Przedstawiamy wybrane zagrożenia dla stron, poczty i serwerów. Przy każdym wpisie podajemy datę publicznego ogłoszenia podatności - mogła zostać odkryta wcześniej.
Wydarzeń w kronice: 25
Błędy w obsłudze pamięci i procesów PHP mogły zagrozić aplikacji nawet wtedy, gdy sam CMS był aktualny.
Historia, skutki i wnioskiBłąd w obsłudze SCTP umożliwił badaczom podniesienie uprawnień do root i wyjście z kontenera na podatnych systemach.
Historia, skutki i wnioskiLuka w KVM/x86 mogła pozwolić napastnikowi wydostać się z maszyny wirtualnej i zaatakować serwer, na którym działała.
Historia, skutki i wnioskiPołączenie dwóch błędów rdzenia WordPressa otworzyło drogę do ataku bez logowania i bez dodatkowych wtyczek.
Historia, skutki i wnioskiBłąd w obsłudze XFRM ESP-in-TCP w Linuksie pokazał, dlaczego trzeba aktualizować także jądro systemu, na którym działają aplikacje.
Historia, skutki i wnioskiObejście uwierzytelniania w cPanel i WHM pokazało, jak luka w panelu zarządzania może zagrozić wielu usługom na serwerze.
Historia, skutki i wnioskiLuka w Roundcube pozwalała zalogowanemu użytkownikowi uruchomić kod na serwerze z uprawnieniami aplikacji pocztowej.
Historia, skutki i wnioskiBłąd wyścigu w serwerze SSH przypomniał, że dawna podatność może powrócić po zmianach w kolejnych wersjach programu.
Historia, skutki i wnioskiTym razem zagrożenie wynikało z celowo wprowadzonego kodu, a nie z przypadkowej pomyłki programisty.
Historia, skutki i wnioskiWykorzystanie sposobu obsługi strumieni HTTP/2 pozwalało przeciążać usługi i przerywać działanie stron.
Historia, skutki i wnioskiPołączenie luki SQL injection z błędem w obsłudze pamięci podręcznej Smarty mogło pozwolić na przejęcie sklepu.
Historia, skutki i wnioskiBłąd w jądrze umożliwiał lokalnym procesom naruszenie danych, które powinny być chronione przed zapisem.
Historia, skutki i wnioskiBiblioteka zapisująca komunikaty aplikacji stała się drogą do zdalnego wykonania kodu.
Historia, skutki i wnioskiZłośliwa zmiana w paczkach panelu administracyjnego pokazała, że zagrożenie może pojawić się jeszcze przed instalacją programu.
Historia, skutki i wnioskiBłąd sprawdzania adresu odbiorcy mógł pozwolić napastnikowi uruchomić polecenia na serwerze pocztowym.
Historia, skutki i wnioskiLuka w Drupalu umożliwiała atak na stronę na kilka sposobów i dotyczyła kilku rozwijanych równolegle wersji CMS.
Historia, skutki i wnioskiBłąd w REST API pozwalał zmieniać treść stron bez wymaganych uprawnień w dwóch wydaniach WordPressa.
Historia, skutki i wnioskiPodatność jądra Linuksa mogła zamienić ograniczony dostęp do systemu w znacznie szerszą kontrolę.
Historia, skutki i wnioskiInformacje przesyłane przez przeglądarkę trafiały do mechanizmu sesji bez wystarczającej kontroli.
Historia, skutki i wnioskiBłąd w warstwie obsługi bazy danych umożliwiał atak na stronę bez logowania do panelu CMS.
Historia, skutki i wnioskiW określonych konfiguracjach dane z zewnątrz mogły zamienić się w polecenia wykonywane przez powłokę systemową.
Historia, skutki i wnioskiZaszyfrowane połączenie nie wystarcza, gdy biblioteka obsługująca szyfrowanie ujawnia pamięć procesu.
Historia, skutki i wnioskiFałszywa odpowiedź zapisana przez resolver DNS mogła skierować użytkownika do niewłaściwej usługi mimo wpisania poprawnej domeny.
Historia, skutki i wnioskiPozornie niewielka zmiana w pakiecie kryptograficznym osłabiła klucze używane przez usługi i użytkowników.
Historia, skutki i wnioskiLuka w serwerze pocztowym pokazała, że bezpieczeństwo hostingu zależy również od usług działających obok strony WWW.
Historia, skutki i wnioskiNie znaleziono wpisów. Zmień wyszukiwaną frazę, rok lub obszar.
JAK CZYTAĆ KRONIKĘ
Opisujemy zagrożenia, które miały duży wpływ na bezpieczeństwo hostingu: ataki przez Internet, przejmowanie uprawnień w systemie i celowe wprowadzanie złośliwego kodu do oprogramowania. Kronika zawiera wybrane historie, a nie wszystkie zgłoszone podatności.
Opisy opieramy na komunikatach producentów i badaczy, do których linkujemy w artykułach. Dodajemy własny komentarz o tym, czego dane zdarzenie uczy administratorów stron i serwerów.
W artykułach podajemy wersje, w których wówczas usunięto opisywane błędy. Aktualizując serwer, kieruj się bieżącymi zaleceniami dostawcy i wybieraj wspierane wydania. Kronika opisuje historię zagrożeń i nie zastępuje śledzenia nowych ostrzeżeń.
Opracowanie pierwszego zestawu i weryfikacja źródeł: 4 listopada 2026 r.