PHP w panice: dwie krytyczne luki stawiają 70% internetu w zagrożeniu, a wszyscy wpadają w panikę

Jeśli w ogóle byłeś dziś online, widziałeś panikę: krytyczna luka bezpieczeństwa grozi „zhakowaniem” niemal każdej strony internetowej na planecie.

Finlandia właśnie zaczęła w środę odłączać rządowe strony internetowe, NSA zaleca wszystkim organizacjom korzystającym z PHP wyłączenie swoich stron, a Holandia i Francja zrobiły to samo. I nie, to nie była cyberwojna.

Winowajcą było PHP, język programowania, o którym większość ludzi nigdy nie słyszała. Prawie na pewno użyłeś go dzisiaj, choćby nieświadomie: obsługuje około 70% wszystkich stron internetowych, których język po stronie serwera jest znany, według W3Techs.

PHP to oprogramowanie działające za kulisami na serwerze strony internetowej — komputerze, który przechowuje stronę i buduje każdą żądaną przez Ciebie podstronę. Każda strona WordPress, na przykład, działa na serwerze PHP, według firmy zajmującej się bezpieczeństwem WordPressa Wordfence.

Aha, a propos, Wordfence też nie działa.

Dwie nowo odkryte luki w samym PHP pozwalają obcej osobie uruchomić własne polecenia na tym serwerze bez konieczności logowania się. Specjaliści od bezpieczeństwa nazywają to nieuwierzytelnionym zdalnym wykonaniem kodu. Wszyscy inni mogą to nazwać „teraz ktoś inny prowadzi”.

Jeśli ten serwer przechowuje Twoje konto, Twój adres lub historię zamówień, cóż, to również jest ich. Dostawca hostingu GoDaddy ostrzegł, że luki mogą pozwolić atakującym na kradzież danych, zniekształcenie stron lub całkowite przejęcie serwerów.

„Taka luka mogłaby pozwolić atakującemu na uruchomienie własnego kodu na dotkniętym serwerze przez internet, co może prowadzić do kradzieży danych, zniekształcenia strony lub całkowitego przejęcia”, twierdzi GoDaddy.

Co ogłosiło PHP

PHP Foundation, organizacja non-profit finansująca rozwój tego języka, wszczęła alarm we wtorek. W oświadczeniu udostępnionym na X stwierdziła: „Zespół ds. bezpieczeństwa PHP przekazuje wcześniejszą informację: Nadchodzące wydanie bezpieczeństwa w środę, 21 października 2026 r., 14:00 UTC, dwie krytyczne luki, obie ocenione na CVSSv4 9.2. Zachęcamy użytkowników PHP do przygotowania się na aktualizację. Wcześniejsze wydanie, jeśli szczegóły staną się publiczne lub pojawią się dowody aktywnego wykorzystania.”

Ta ocena 9.2 pochodzi z CVSS, Common Vulnerability Scoring System, który ocenia, jak niebezpieczna jest luka, na podstawie takich czynników, jak łatwość dostępu do niej przez internet i jakie szkody może wyrządzić. Skala wynosi od 0 do 10, a wszystko od 9.0 wzwyż jest oznaczone jako krytyczne — więc te dwie są mniej więcej tak złe, jak to tylko możliwe, nie osiągając idealnej dziesiątki.

Poprawka pojawiła się około 13:35 UTC w środę, kilka minut wcześniej, jako wersje PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Biuletyn bezpieczeństwa nie bawił się w subtelności: „Zdecydowanie zachęcamy wszystkich użytkowników PHP do natychmiastowej aktualizacji.”

Jednak wydanie poprawki i wdrożenie rozwiązania przez wszystkich to nie to samo, więc zaleca się ostrożność.

Jak działają błędy

Pierwszy błąd, CVE-2026-109618, pojawia się, gdy PHPowi kończy się pamięć w połowie obsługi żądania, a następnie traktuje te na wpół zbudowane dane tak, jakby były ukończone. Drugi, CVE-2026-109619, pozwala pozostałościom z żądania jednego odwiedzającego zalegać w pamięci po tym, jak powinny zostać wyrzucone, gdzie następne żądanie może się o nie potknąć.

Pomyśl o kucharzu, który wciąż odczytuje zamówienia z kart, które już są w koszu. Podrzuć fałszywą kartę do kosza, a kucharz zrobi wszystko, co na niej napisałeś. W tym przypadku „zamówieniem” jest kod atakującego, a serwer go wykonuje.

PHP stwierdziło, że ryzyko jest najwyższe na serwerach korzystających z powszechnej konfiguracji Apache zwanej mod_php, gdzie zademonstrowany exploit działa „zanim uruchomi się jakikolwiek kod aplikacji”. Innymi słowy, własne zabezpieczenia strony, takie jak ekrany logowania i wtyczki bezpieczeństwa WordPressa, nawet się nie budzą.

Badacze z fundacji PHP wskazali funkcję postępu przesyłania w PHP, czyli mechanizm śledzący, jak dużą część pliku już wysłano, jako jedną z potwierdzonych dróg wejścia. Jest ona włączona domyślnie od ponad dekady, a niewiele stron faktycznie z niej korzysta.

Wyciek, a potem ataki

Nic z tego nie miało jeszcze być publiczne. We wtorek ktoś napisał na forum Hacker News, że dwa błędy PHP zostaną ujawnione w czwartek, przyznając jednocześnie, że nie ma „żadnych dowodów poza ‚źródło: zaufaj mi, bracie’”.

Okazuje się, że brachu miał rację. Firma bezpieczeństwa watchTowr potwierdziła, że błędy są prawdziwe i objęte embargiem — umową o zachowaniu szczegółów w tajemnicy do czasu gotowości poprawki — a PHP przyspieszyło swoje wydanie o dzień.

„Widzimy pojawiające się wczesne ataki i aktualizujemy środki zaradcze, gdy pojawiają się nowe wektory” — napisał wczesnym rankiem w środę na X dyrektor techniczny Cloudflare, Dane Knecht, na X, prawie sześć godzin przed wydaniem łatki. Cloudflare wdrożyło awaryjne reguły zapory sieciowej, filtry blokujące znane wzorce ataków, u wszystkich klientów, ale Knecht nazwał je „wyłącznie środkiem doraźnym”.

Rządy wyłączają zasilanie

Fińskie państwowe centrum IT, Valtori, zaczęło wyłączać publiczne usługi internetowe w ramach środka ostrożności, jak podał nadawca publiczny Yle, podczas gdy holenderska krajowa agencja cyberbezpieczeństwa wyłączyła własną stronę internetową.

Francuskie Ministerstwo Spraw Wewnętrznych poinformowało, że strony internetowe prefektur zostały „tymczasowo wyłączone w oczekiwaniu na wydanie poprawki bezpieczeństwa przez wydawcę frameworka”.

CERT-EU, unijny zespół ds. cybernetycznych sytuacji kryzysowych, powiedział organizacjom, które nie mogły zainstalować poprawki, aby „rozważyły odizolowanie aplikacji wystawionych na internet od sieci publicznych do czasu udostępnienia poprawki”. To biurokratyczny język oznaczający „odłącz to”. Agencje w Australii, Japonii i Wielkiej Brytanii przekazały w zasadzie to samo, według Reutersa.

Co wiralowe posty podały błędnie

Wiralowe wątki na X twierdziły, że wersje PHP „sięgające 2004 roku” były podatne na lukę. To nawiązuje do wczesnych szacunków, że wszystko od PHP 5 było dotknięte problemem, co CERT-EU przyznał, opiera się na postach w mediach społecznościowych.

Firma zajmująca się bezpieczeństwem e-commerce Sansec określa zakres na PHP 5.4 i nowsze. Czyli 2012, a nie 2004—wciąż wystarczająco stare.

PHP dostarcza oficjalne wydania tylko dla wersji 8.2 i nowszych, co sprawia, że twierdzenie „brak poprawki dla starych wersji” jest w połowie prawdziwe. Biorąc pod uwagę, jak poważna jest ta sytuacja, jego zespół ds. bezpieczeństwa opublikował również podstawowe poprawki kodu źródłowego dla 7.4, 8.0 i 8.1, a dystrybucje Linuksa przenoszą własne poprawki.

Firma zajmująca się bezpieczeństwem Mallory naliczyła około 884 000 hostów wystawionych na internet, reklamujących PHP 8.1 lub starsze, 20 października, czyli 59% z około 1,5 miliona, które publicznie pokazują wersję. Pojedynczy serwer hostingu współdzielonego może obsługiwać wiele stron internetowych, więc liczba stron za nimi jest wyższa.

Niektóre wątki wrzuciły też Node.js, inną technologię internetową, która przypadkiem zaplanowała własną, niezwiązaną aktualizację bezpieczeństwa na ten sam dzień. Zły timing.

Nawet załatane wersje nie dotrą do każdego serwera naraz. „Jeśli polegasz na utrzymywanym przez wolontariuszy https://rpms.remirepo.net, wzywamy cię, abyś teraz przeszedł na pakiety dystrybucji lub budowanie ze źródeł, dzięki czemu będziesz mógł natychmiast zastosować aktualizacje. Repozytorium nie będzie miało dziś aktualizacji” — powiedziała PHP Foundation w swoim oświadczeniu, odnosząc się do popularnego, prowadzonego przez wolontariuszy źródła pakietów PHP dla serwerów Linux w stylu Red Hat.

Czy naprawdę powinno cię to obchodzić?

Nie powinieneś wpadać w panikę, ale też nie powinieneś tego lekceważyć. Zhakowana strona internetowa, na przykład, nie musi wcale dotykać blockchaina, aby opróżnić twój portfel. W 2024 roku atakujący przekierowali frontendy protokołów DeFi Compound i Celer na strony, które opróżniały podłączone portfele, a Curve Finance doświadczył podobnego ataku w 2025 roku.

To były przejęcia DNS, a nie błędy PHP, ale sztuczka jest ta sama: strona wygląda dobrze, adres URL wygląda dobrze, a przycisk „zatwierdź” wysyła twoje tokeny gdzie indziej. Przejęty serwer może serwować dokładnie taką stronę.

Hakerzy potrafią być bardzo kreatywni, bardzo szybko, jeśli chodzi o exploity zero-day.

Takie błędy stają się też łatwiejsze do znalezienia, ponieważ czołowe modele AI są coraz częściej wykorzystywane do wykrywania podatności w oprogramowaniu, a eksperci powiedzieli Decrypt w czerwcu, że wraz z rozprzestrzenianiem się tych narzędzi może ujawnić się znacznie więcej podatności.

Co dzieje się dalej i co robić

Gdy poprawka stanie się publiczna, atakujący mogą porównać stary i nowy kod, aby dokładnie zobaczyć, co zostało naprawione, a zespół ds. informatyki śledczej w firmie zajmującej się cyberbezpieczeństwem Sansec powiedział, że spodziewa się „masowych ataków w ciągu 15 minut od wydania”. Gdy inna luka w PHP została ujawniona w czerwcu 2024 roku, Akamai odnotowała próby wykorzystania jej przeciwko swoim serwerom-pułapkom w ciągu 24 godzin.

Czy przeciętny użytkownik powinien wpadać w panikę? Niekoniecznie. Twój telefon, przeglądarka i laptop nie potrzebują łatki PHP; zadanie spada na tego, kto prowadzi strony internetowe, z których korzystasz.

Jeśli prowadzisz stronę, zapytaj swojego dostawcę hostingu, czy PHP zostało zaktualizowane, i nie licz na to, że WordPress zrobi to za Ciebie: Wordfence ostrzegł, że automatyczne aktualizacje nie zastosują tej poprawki, i polecił właścicielom stron ustalić, kto odpowiada za aktualizację PHP na ich serwerach. Każdy, kto korzysta z wersji 8.1 lub starszej, musi zaplanować aktualizację.

"Jedyne, co mogę powiedzieć, to że jedynym środkiem zaradczym jest załatanie / aktualizacja PHP" — powiedziała Gina Peter Banyard, deweloperka rdzenia PHP, na Mastodonie. "Niestety wiem zbyt wiele."

A jeśli korzystasz z PHP 8.2, poprawka, którą właśnie otrzymałeś, jest jedną z ostatnich: ta wersja osiąga koniec życia 31 grudnia 2026 roku, po czym nie otrzyma już żadnych poprawek bezpieczeństwa.