W środę, 21 października 2026 roku, Wykop.pl został tymczasowo wyłączony, serwisy Telewizji Polskiej przestały na pewien czas działać, a kolejne instytucje ograniczały dostęp do swoich usług internetowych. Przyczyną nie była jednak zwykła awaria, lecz alarm bezpieczeństwa dotyczący dwóch krytycznych podatności w PHP – technologii wykorzystywanej przez ogromną część współczesnego internetu. Luki oznaczone jako CVE-2026-109618 oraz CVE-2026-109619 umożliwiają zdalne wykonanie kodu na podatnym serwerze, w określonych konfiguracjach nawet bez znajomości jakiegokolwiek hasła. Zagrożone są wersje PHP sięgające serii 5.x, a pierwsze próby wykorzystania podatności zostały już zaobserwowane przez specjalistów zajmujących się cyberbezpieczeństwem.

Sytuacja jest na tyle poważna, że polski CERT zalecił administratorom natychmiastowe przygotowanie aktualizacji, a w uzasadnionych przypadkach również czasowe wyłączenie zagrożonych usług. Podobne ostrzeżenia pojawiły się w innych krajach. Wydanie awaryjnych poprawek zaplanowano na 21 października na godzinę 16:00 czasu polskiego i tego dnia rzeczywiście zostały one udostępnione. Problem polega jednak na tym, że nie wszystkie wykorzystywane w internecie wersje PHP są nadal wspierane, a część administratorów będzie musiała poczekać na poprawki przygotowane przez dostawców systemów operacyjnych lub usług hostingowych.

Wykop wyłączony, TVP z przerwą w działaniu. Kolejne instytucje reagują

Jednym z najbardziej zauważalnych w Polsce przykładów był Wykop.pl, który 21 października poinformował użytkowników o tymczasowym wyłączeniu platformy w związku z krytycznymi podatnościami w PHP. Administratorzy zdecydowali się ograniczyć dostęp do serwisu, aby zadbać o bezpieczeństwo infrastruktury. Początkowo zapowiadano przywrócenie działania około godziny 17:00. Wykop nie przedstawił jednak informacji wskazujących, że doszło do skutecznego włamania lub kradzieży danych użytkowników. Samo wyłączenie strony należy więc traktować jako działanie zapobiegawcze, a nie dowód udanego cyberataku.

Problemy z dostępnością odnotowali również użytkownicy serwisów Telewizji Polskiej. Niedostępne były między innymi tvp.pl, tvp.info oraz sport.tvp.pl, a także niektóre powiązane aplikacje. Biuro prasowe TVP wyjaśniło, że 21 października, między godziną 10:49 a 11:51, prowadzono prace związane z eliminowaniem zagrożeń wynikających z ujawnionych podatności. Obejmowały one między innymi zmiany zasad działania zapory sieciowej i ponowne uruchamianie części usług. Ze względu na rozbudowaną infrastrukturę przeprowadzenie tych operacji spowodowało czasową niedostępność portali. TVP podkreśliła, że problem nie ograniczał się wyłącznie do jej serwisów.

Na podobne środki zdecydowały się inne instytucje. Politechnika Białostocka poinformowała o prewencyjnym ograniczeniu dostępu do wybranych usług, w tym stron internetowych, systemu USOSweb i platformy Moodle. Narodowy Instytut Dziedzictwa uprzedził użytkowników o możliwych przerwach po godzinie 16:00, związanych bezpośrednio z koniecznością aktualizacji PHP. Również infrastruktura Wikimedia została objęta nadzwyczajnymi działaniami: czasowo wyłączono między innymi wybrane narzędzia programistyczne i usługi hostingowe, takie jak Cloud VPS i Toolforge.

Podobne decyzje podejmowano za granicą. W Finlandii część państwowych stron internetowych została prewencyjnie wyłączona przez instytucję odpowiedzialną za rządową infrastrukturę informatyczną. Ograniczenia dostępności serwisów odnotowano również w Holandii. Nie oznacza to, że wszystkie te strony zostały zhakowane. W wielu przypadkach administratorzy świadomie poświęcili dostępność usług, aby nie narażać ich użytkowników i przechowywanych danych.

PHP2Shell – dwie luki, które mogą oddać serwer w ręce przestępców

Odkryte podatności otrzymały wspólną nazwę PHP2Shell i identyfikatory CVE-2026-109618 oraz CVE-2026-109619. Każda z nich została oceniona na 9,2 punktu w dziesięciostopniowej skali CVSS 4.0, co oznacza krytyczny poziom zagrożenia. Obie dotyczą błędów w zarządzaniu pamięcią przez silnik PHP, jednak mechanizmy prowadzące do ich wykorzystania są nieco inne.

Pierwsza podatność, CVE-2026-109618, jest związana z obsługą sytuacji, w której procesowi PHP kończy się dostępna pamięć operacyjna. W pewnych okolicznościach przetwarzanie żądania zostaje przerwane, zanim wszystkie wewnętrzne struktury danych zostaną prawidłowo przygotowane. Późniejsze procedury czyszczenia mogą potraktować nieprawidłowe informacje jako poprawne i doprowadzić do uszkodzenia pamięci procesu. Odpowiednio przygotowany atak może wykorzystać ten mechanizm do wykonania kodu.

Druga luka, CVE-2026-109619, dotyczy sytuacji, w której PHP zachowuje odwołania do danych pochodzących z wcześniej obsłużonego żądania, chociaż zajmowana przez nie pamięć została już zwolniona. Następne żądanie obsługiwane przez ten sam proces może doprowadzić do wykorzystania takich nieaktualnych odwołań. W bezpieczeństwie oprogramowania tego rodzaju problem określa się jako use-after-free. Pod odpowiednimi warunkami może prowadzić zarówno do odczytu niedozwolonych danych, jak i wykonania kodu kontrolowanego przez atakującego.

Najbardziej niepokojące jest to, że atak nie musi wymagać logowania do panelu administracyjnego, posiadania konta użytkownika ani wykorzystania podatnej wtyczki. W niektórych konfiguracjach serwera wystarczy odpowiednio przygotowany ruch HTTP, aby wykorzystać błąd występujący na poziomie samego PHP. Twórcy języka wskazują szczególnie duże zagrożenie dla instalacji wykorzystujących Apache z modułem mod_php, gdzie potwierdzono możliwość skutecznego ataku jeszcze przed uruchomieniem kodu aplikacji internetowej. Zagrożenia dotyczą również innych sposobów uruchamiania PHP, choć konkretne warunki wykorzystania podatności mogą się różnić.

Czy haker może faktycznie przejąć kontrolę nad całym serwerem?

Tak, skuteczne wykorzystanie podatności może dać napastnikowi możliwość wykonywania poleceń na serwerze, ale zakres kontroli zależy od uprawnień procesu PHP oraz konfiguracji całego środowiska. Nie oznacza to automatycznie zdobycia najwyższych uprawnień administratora systemu. Nawet dostęp ograniczony do konta obsługującego aplikację internetową może jednak stanowić ogromne zagrożenie.

W praktyce przestępca może uzyskać możliwość odczytywania plików aplikacji, przejmowania danych uwierzytelniających do baz danych, modyfikowania zawartości strony internetowej czy instalowania złośliwego oprogramowania w obszarach dostępnych dla procesu. Jeżeli infrastruktura nie jest odpowiednio odseparowana, zdobyte w ten sposób informacje mogą posłużyć do przejmowania kolejnych usług. W przypadku sklepów internetowych potencjalnym celem mogą stać się bazy klientów, zamówienia, dane kontaktowe czy klucze dostępowe do zewnętrznych systemów. Rzeczywista skala strat zależałaby od uprawnień i zabezpieczeń konkretnego serwera.

Co istotne, badacze wykazali również możliwość odczytywania fragmentów pamięci procesu PHP bez konieczności uzyskania pełnego zdalnego wykonania kodu. W takiej pamięci mogą znajdować się poufne dane przetwarzane przez aplikacje internetowe, w tym tokeny sesji, klucze API lub informacje uwierzytelniające. To właśnie dlatego PHP2Shell stanowi zagrożenie nie tylko dla dostępności witryn, lecz również dla poufności przechowywanych i przetwarzanych danych.

Problem może dotyczyć ogromnej części internetu. Nawet aktualny WordPress nie wystarczy

PHP pozostaje jednym z najpowszechniej wykorzystywanych języków programowania po stronie serwera. Według danych W3Techs z października 2026 roku korzysta z niego około 69% witryn, dla których udało się zidentyfikować język wykorzystywany po stronie serwera. Nie oznacza to, że 69% wszystkich serwerów internetowych można automatycznie przejąć, ale dobrze pokazuje potencjalną skalę problemu.

Na PHP opierają się między innymi WordPress, WooCommerce, Joomla, Drupal, Magento oraz wiele autorskich systemów zarządzania treścią i platform sprzedażowych. Dlatego luka występująca w samym PHP jest znacznie groźniejsza od typowego błędu w pojedynczej wtyczce. Nawet wzorowo aktualizowany WordPress może działać na podatnej wersji PHP, ponieważ aktualizacja aplikacji nie oznacza automatycznej aktualizacji interpretera zainstalowanego na serwerze.

Nie jest również prawdą, że podatność dotyczy wyłącznie przestarzałych stron internetowych. Zagrożone były także aktualne przed wydaniem poprawek wersje PHP, wykorzystywane w nowych i regularnie rozwijanych projektach. Eksperci Wiz potwierdzili skuteczność przygotowanych demonstracji ataków na instalacjach WordPressa, Drupala i Joomli. Oczywiście nie oznacza to, że każda możliwa konfiguracja tych systemów jest równie łatwa do zaatakowania, ale sam fakt posiadania najnowszej wersji popularnego CMS-a nie stanowi zabezpieczenia przed PHP2Shell.

Luki istniały od lat. W ich odkryciu pomogła sztuczna inteligencja

Historia wykrycia PHP2Shell jest równie interesująca, jak sama podatność. Badacze bezpieczeństwa odkryli, że część problemów wynika z mechanizmów zarządzania pamięcią obecnych w PHP od wielu lat. Nowszy komunikat CERT Polska wskazuje na podatność wersji od PHP 5.4, wydanej jeszcze w 2012 roku. Oznacza to, że błędy pozostawały niezauważone lub nie były wcześniej rozpoznawane jako praktycznie wykorzystywalne zagrożenie przez ponad dekadę.

W odkryciu i analizie podatności istotną rolę odegrały nowoczesne modele sztucznej inteligencji. Firma Wiz poinformowała, że podczas badań wykorzystywała między innymi własne narzędzia Wiz Atlas oraz modele Gemini 4 Argon i GPT-5.6 Sol. Niezależnie nad problemem pracowała również firma Calif, wykorzystująca narzędzia AI udostępniane przez OpenAI. Badania te były następnie częścią skoordynowanego procesu przygotowania poprawek, w którym uczestniczyli twórcy PHP oraz przedstawiciele branży cyberbezpieczeństwa.

Według osi czasu przedstawionej przez Wiz pierwsze odkrycia nastąpiły już 19 sierpnia 2026 roku, a w kolejnych dniach badacze potwierdzili możliwość wykorzystania luk przeciwko aplikacjom internetowym. Informacje przekazano zespołowi PHP 24 sierpnia. Następne tygodnie poświęcono analizie, testowaniu oraz przygotowaniu poprawek przed ich publicznym ujawnieniem 21 października.

To ważny przykład zmieniającej się roli sztucznej inteligencji w cyberbezpieczeństwie. Modele AI mogą pomagać badaczom odkrywać błędy, których analiza byłaby wcześniej wyjątkowo czasochłonna. Jednocześnie podobne możliwości mogą ułatwiać przestępcom dostosowywanie ataków do różnych konfiguracji oprogramowania. Problem nie polega więc wyłącznie na istnieniu podatności, lecz także na tym, jak szybko szczegółowa wiedza o niej może zostać wykorzystana na masową skalę.

Ataki już się rozpoczęły. Cloudflare potwierdza podejrzany ruch

Zagrożenie nie pozostało wyłącznie teoretyczne. Cloudflare, jeden z największych na świecie dostawców usług ochrony i obsługi ruchu internetowego, potwierdził zaobserwowanie prób wykorzystania PHP2Shell. Firma przygotowała i wdrożyła dodatkowe reguły ochronne, analizując między innymi modyfikacje żądań wysyłanych przez napastników próbujących obejść zastosowane zabezpieczenia.

Cloudflare poinformował, że jego mechanizmy ochronne były przygotowywane jeszcze przed pełnym publicznym ujawnieniem podatności. Jednocześnie eksperci podkreślają, że zapory aplikacyjne, czyli WAF, mogą ograniczać ryzyko, ale nie stanowią pełnego rozwiązania problemu. Wykrycie prób ataków w internecie nie jest jednak równoznaczne z potwierdzeniem, że przestępcom udało się włamać na Wykop, do TVP lub do którejkolwiek z instytucji, które zdecydowały się czasowo wyłączyć swoje usługi. Takich wniosków nie można wyciągać jedynie z informacji o niedostępności stron.

Aktualizacje PHP już dostępne. Starsze wersje wymagają szczególnej uwagi

Twórcy PHP udostępnili 21 października 2026 roku poprawione wydania czterech oficjalnie wspieranych gałęzi oprogramowania. Bezpieczne wersje to PHP 8.2.35, PHP 8.3.36, PHP 8.4.27 oraz PHP 8.5.12. Administratorzy korzystający z wcześniejszych wydań tych serii powinni możliwie szybko wdrożyć aktualizacje i upewnić się, że wszystkie procesy obsługujące aplikacje działają już na poprawionym oprogramowaniu.

Sytuacja jest bardziej skomplikowana w przypadku starszych gałęzi PHP. Wersje 8.1 i wcześniejsze nie otrzymują już zwykłych aktualizacji bezpieczeństwa bezpośrednio od projektu PHP. Nie oznacza to jednak, że dla każdej takiej instalacji jedyną opcją jest natychmiastowa zmiana wersji. Część dostawców dystrybucji Linuksa i komercyjnego wsparcia długoterminowego przygotowuje poprawki przeniesione do starszych wydań, czyli tzw. backporty. Sam zespół PHP udostępnił również ograniczone poprawki źródłowe dla gałęzi 7.4, 8.0 i 8.1, aby ułatwić ich wdrożenie administratorom i dostawcom.

Właściciele stron korzystających z PHP 5.6, 7.x lub starszych wydań PHP 8 powinni więc niezwłocznie skontaktować się z dostawcą hostingu i ustalić, czy wykorzystywane środowisko otrzymało właściwą poprawkę. Szczególne znaczenie ma to w przypadku usług utrzymywanych na własnych serwerach, przestarzałych aplikacji biznesowych oraz stron, których właściciele od lat nie aktualizowali konfiguracji technicznej. Należy pamiętać, że poprawki dostawców systemów operacyjnych nie zawsze zmieniają główny numer wersji PHP, dlatego sama informacja o numerze interpretera może nie wystarczyć do oceny bezpieczeństwa.

Na czas oczekiwania na aktualizację CERT Polska przedstawił również zalecenia dotyczące ograniczenia ryzyka, obejmujące między innymi konfigurację limitów pamięci, rozmiaru przesyłanych danych oraz wyłączenie mechanizmu śledzenia postępu przesyłania plików przez sesje PHP. Zmiany takie powinny być jednak wprowadzane świadomie przez administratorów, ponieważ mogą wpływać na stabilność i funkcjonalność aplikacji. Zarówno CERT Polska, jak i twórcy PHP podkreślają, że żadne z tych tymczasowych zabezpieczeń nie zastępuje instalacji poprawionej wersji oprogramowania.

Masz stronę internetową lub sklep na WooCommerce? Sprawdź PHP, a nie tylko wtyczki

Właściciele stron opartych na WordPressie mogą sprawdzić informacje o środowisku serwerowym w panelu administracyjnym, przechodząc do sekcji Narzędzia → Stan witryny → Informacje → Serwer. W przypadku hostingu współdzielonego dane dotyczące wersji PHP są często dostępne również w panelu klienta dostawcy. Najważniejsze jest jednak potwierdzenie, czy rzeczywiście wdrożono poprawki związane z CVE-2026-109618 i CVE-2026-109619. Nie należy zakładać, że codzienne automatyczne aktualizacje WordPressa lub jego rozszerzeń rozwiązują problem.

Jeżeli strona korzysta z nieaktualnej wersji PHP, warto pilnie ustalić możliwość przeprowadzenia aktualizacji. W przypadku starszych sklepów internetowych może to wymagać wcześniejszego sprawdzenia zgodności oprogramowania, ale ryzyko problemów technicznych podczas migracji nie powinno być pretekstem do bezterminowego pozostawiania podatnego serwera dostępnego publicznie. Administratorzy powinni również monitorować logi, nietypowe błędy procesów PHP i inne sygnały mogące świadczyć o próbach wykorzystania luk. Jeżeli istnieje podejrzenie skutecznego włamania, sama późniejsza aktualizacja nie wystarczy – konieczna może być analiza incydentu, sprawdzenie integralności systemu i zabezpieczenie potencjalnie przejętych danych dostępowych.

Czy zwykli użytkownicy mają powody do obaw?

Dla przeciętnego internauty najważniejsza jest informacja, że czasowa niedostępność strony nie oznacza automatycznie wycieku jego danych. Jeżeli Wykop, sklep internetowy czy portal instytucji publicznej został wyłączony z przyczyn bezpieczeństwa, może to świadczyć o odpowiedzialnej decyzji administratorów. Sam użytkownik nie ma możliwości zainstalowania poprawki PHP na cudzym serwerze i nie powinien podejmować żadnych działań tylko dlatego, że dana strona przez pewien czas nie działa.

Warto natomiast zachować ostrożność wobec komunikatów podszywających się pod administratorów serwisów. Przestępcy mogą próbować wykorzystać zainteresowanie awariami do rozsyłania fałszywych informacji o konieczności weryfikacji kont, ponownego logowania czy potwierdzania danych. Nie ma podstaw, aby w związku z samym ujawnieniem PHP2Shell przekazywać komukolwiek hasła lub kody uwierzytelniające.

21 października 2026 roku internet nie przestał działać z powodu jednego globalnego włamania. Część jego infrastruktury została celowo wyłączona, ponieważ ujawniono zagrożenie pozwalające atakującym ominąć zabezpieczenia wielu aplikacji internetowych. PHP2Shell pokazuje, jak duże konsekwencje może mieć błąd ukryty przez lata w podstawowym komponencie oprogramowania. I dlaczego w pewnych sytuacjach znacznie rozsądniej jest na chwilę wyłączyć stronę niż pozostawić przestępcom otwartą drogę do serwera.