Jesteśmy oficjalnie wolni od PHP. Oto czego nauczył nas październik (jak dotąd)

Tydzień od 19 do 24 października 2026 r., od poniedziałku do soboty, przyniósł nieprzerwaną serię poważnych wiadomości o bezpieczeństwie w całej branży. Jeśli coś Ci umknęło, nasz przegląd tego tygodnia omawia szczegóły. W skrócie: w kilku przypadkach napastnicy ruszyli szybciej niż poprawki.

Taki tydzień nie odsyła nas z powrotem do deski kreślarskiej, ale wyostrza linie, które już na niej są. Czym innym jest wyznawać zasadę, a czym innym obserwować, przypadek po przypadku, co dzieje się tam, gdzie tej zasady brakuje. Dlatego zamiast wyliczać techniczne kroki, chcemy wyjaśnić zasady, według których pracujemy, bo dla Ciebie jako klienta podejście znaczy więcej niż jakakolwiek pojedyncza aktualizacja. Jedna z tych zasad właśnie osiągnęła swój kamień milowy: jesteśmy teraz oficjalnie wolni od PHP.

Dlaczego łatanie po fakcie to przegrany wyścig?

Przez lata standardowa rada była prosta: łataj szybko, a wszystko będzie dobrze. Trend już wtedy działał przeciwko tej radzie. Zespół Mandiant należący do Google zmierzył średni czas między ujawnieniem podatności a jej wykorzystaniem: 63 dni w latach 2018 i 2019, 32 dni w latach 2021 i 2022 oraz pięć dni w 2023 roku, licząc średnią po odrzuceniu wartości skrajnych.

Pięć dni to wynik z 2023 roku, zanim narzędzia AI stały się częścią codziennej pracy nad oprogramowaniem. Ten miesiąc dał nam świeży pomiar tego wyścigu, wykonany z trzech różnych punktów obserwacyjnych wokół ujawnienia PHP2Shell z 21 października 2026 r.

Zespół analizy zagrożeń Amazon zaobserwował próbę wykorzystania PHP2Shell 17 października, cztery dni przed publicznym ujawnieniem, i podaje, że gdy embargo zostało zniesione i wydano łatkę, kolejne exploity typu proof-of-concept pojawiły się w ciągu godzin. F5 Labs zaobserwowało pierwsze skanowanie pod kątem PHP2Shell ponad pięć godzin przed publikacją dwóch CVE, a w ciągu godzin od ujawnienia jego czujniki rejestrowały tysiące prób wykorzystania luki. Dyrektor generalny Cloudflare, Matthew Prince, powiedział 22 października, że Cloudflare widział tysiące prób przed ogłoszeniem, dziesiątki tysięcy w ciągu 45 minut po nim, setki tysięcy w ciągu dwóch godzin i miliony do czasu publikacji jego wpisu. Były to próby, nie potwierdzone włamania, ale pokazują, jak szybko sprawdzano drzwi: okno mierzy się teraz w minutach i godzinach, a dla niektórych zamknęło się, zanim łatka w ogóle istniała.

Wykorzystanie luki, zanim powstanie jakakolwiek poprawka, też nie jest rzadkością. W 2023 roku 70% wykorzystanych podatności śledzonych przez Mandiant, 97 ze 138, zostało wykorzystanych jako luki typu zero-day, czyli zanim istniała jakakolwiek poprawka.

Jeśli wykorzystanie luki może zacząć się, zanim łatka będzie dostępna, i nadejść masowo w ciągu minut od jej publikacji, to łatanie, choćby najbardziej zdyscyplinowane, nie może być całym planem. Obrońca, który polega tylko na nim, przystąpił do wyścigu, który często rozstrzyga się, zanim się zacznie. Dlatego zakładamy, że ten wyścig będzie czasem przegrany, i projektujemy z myślą o przegranej. To założenie zamienia się w trzy pytania. Dopóki luka jest otwarta, jak wiele naszych systemów może zostać trafione? Jeśli coś zostanie trafione, jak wiele można stracić? A gdy poprawka już istnieje, jak szybko możemy się odbudować i zamknąć lukę? Każda z naszych zasad odpowiada na jedno z tych pytań i wszystko poniżej jest wokół nich uporządkowane.

Dlaczego usuwamy oprogramowanie, zamiast łatać wokół niego?

Zacznijmy od pierwszego pytania: jak wiele może zostać trafione. Każda organizacja gromadzi oprogramowanie, które źle się zestarzało: narzędzia, których opiekunowie odeszli, komponenty tkwiące na starych wersjach, bo coś innego od nich zależy, kod, którego nikt nie chce dotykać. Typowa reakcja to owinąć takie oprogramowanie w obejścia i reguły zapory sieciowej i liczyć na szczęście.

My patrzymy na to inaczej. Oprogramowanie, którego nie da się utrzymywać w aktualności, jest usuwane, a nie obudowywane łatami. Nie utrzymujemy go przy życiu tymczasowymi poprawkami, bo tymczasowa poprawka na nieutrzymywanym kodzie to obietnica, która w końcu zostanie złamana. Albo komponent może być aktualizowany tak długo, jak go używamy, albo nie działa u nas wcale.

Dlaczego obejścia zawodzą? Bo obejście blokuje tylko te luki, które są już znane. Nieutrzymywane oprogramowanie nie przestaje mieć słabości w dniu, w którym jego opiekunowie odchodzą. Badacze i napastnicy wciąż znajdują nowe, rok po roku, a teraz nie ma już nikogo, kto napisałby poprawki. Każde odkrycie wymusza kolejną regułę, kolejny filtr, kolejną warstwę przykręconą na poprzedniej, a cała sterta robi się z każdym dodatkiem coraz bardziej krucha. Prędzej czy później pojawia się luka, której żadna zewnętrzna warstwa nie odsieje, albo dwie warstwy zaczynają sobie przeszkadzać, i ochrona po cichu ustępuje. Obejście kupuje czas, a na porzuconym kodzie nie ma na co tego czasu sensownie wydać, bo podstawowy problem nigdy nie zostanie naprawiony.

Wróćmy do opisanego wyżej wyścigu, rozgrywanego teraz w minutach i godzinach. Przeciwko utrzymywanemu oprogramowaniu wyścig jest brutalnie krótki, ale przynajmniej da się go biec. Przeciwko porzuconemu oprogramowaniu nie ma żadnego wyścigu, bo poprawka, która powinna go zakończyć, nigdy nie nadejdzie. Zapisane na papierze brzmi to oczywiście. W praktyce to trudniejsza droga, bo usunięcie czegoś zwykle oznacza przebudowę tego, co na tym polegało. Uważamy, że ten koszt warto ponieść. Napastnik nie może wykorzystać słabości w systemie, który już nie istnieje.

Jak naprawdę wygląda mała powierzchnia ataku?

Usuwanie to najprostszy sposób na zmniejszenie tego, co może zostać trafione. Szerszy nawyk, który za tym stoi, ma techniczną nazwę: utrzymywanie małej powierzchni ataku. Powierzchnia ataku to prosta idea, suma wszystkich miejsc, w których napastnik mógłby spróbować klucza w zamku. Każda wystawiona usługa, każda zewnętrzna biblioteka, każda wtyczka to jeden zamek więcej do obrony. Nasza definicja dobrego bezpieczeństwa zaczyna się tutaj: najmocniejszy kod to ten, którego nie uruchamiasz, a najbezpieczniejsze dane to te, których nigdy nie przechowywałeś.

Zastanówmy się, czym naprawdę jest zewnętrzna biblioteka lub wtyczka. Gdy programista ją dołącza, ufa obcej osobie, często nieopłacanemu wolontariuszowi, że będzie dbać o bezpieczeństwo tego kodu tak długo, jak on działa. Biblioteka potrzebuje własnych aktualizacji, własnych poprawek bezpieczeństwa, własnego uważnego opiekuna. Jeśli ten opiekun straci zainteresowanie, zmieni pracę albo po prostu przestanie odpowiadać, kod działa dalej, ale nikt już go nie pilnuje. Luka znaleziona po tym momencie zostaje otwarta na dobre, czyli problem porzucenia z poprzedniej sekcji wchodzi bocznymi drzwiami. Pomnóżmy to przez liczne komponenty, od których zależy typowa aplikacja, a obraz staje się jasny. Każda zależność to mała obietnica złożona przez kogoś, kogo nigdy nie spotkałeś, a niektóre z tych obietnic po cichu wygasają. Uruchamianie mniejszej ich liczby oznacza, że swoje bezpieczeństwo zawdzięczasz mniejszej liczbie obcych.

Systemy, do których się logujesz, przez które płacisz i z którymi rozmawiają nasze aplikacje, są napisane w Go. PHP zniknął, a wraz z nim długi ogon bibliotek, wtyczek i zależności, który aplikacje PHP zwykle ciągną za sobą.

Wybraliśmy Go dla naszych najbardziej krytycznych systemów, bo odpowiada on na problem zależności na poziomie języka. Go jest bezpieczny pamięciowo: język zarządza pamięcią za programistę, co wyklucza całą klasę błędów, takich jak przepełnienia bufora, a CISA (amerykańska agencja ds. cyberbezpieczeństwa) wymienia Go wśród języków bezpiecznych pamięciowo w dokumencie The Case for Memory Safe Roadmaps. Ta klasa jest większa, niż się wydaje: projekt Chromium stwierdza, że około 70% jego poważnych błędów bezpieczeństwa to problemy z bezpieczeństwem pamięci. Biblioteka standardowa Go pokrywa dużą część potrzeb usługi internetowej, w tym kryptografię, więc usługa w Go potrzebuje mniej zewnętrznych pakietów, a to oznacza mniej tych obietnic od obcych. Kryptografia jest traktowana na tyle poważnie, że własny moduł kryptograficzny Go jest zwalidowany według standardu rządu USA FIPS 140-3, certyfikat CMVP nr 5247. A gdy luka pojawi się w szerszym ekosystemie, zespół bezpieczeństwa Go prowadzi bazę podatności, a jego narzędzie govulncheck zgłasza tylko podatności w kodzie, który program faktycznie wywołuje, dzięki czemu alerty są mało szumne i nadają się do działania.

Ma to znaczenie z powodu tego, jak rozpowszechnione, i jak stare, są wdrożenia PHP. W3Techs podaje, że PHP jest używany przez 69,2% wszystkich stron internetowych, których język serwerowy jest znany, przy czym 26,6% stron PHP wciąż działa na PHP 7, a 7,7% na PHP 5, według pomiaru z 27 października 2026 r. Sam projekt PHP wspiera każdą gałąź wydania przez dwa lata poprawek błędów i bezpieczeństwa, a potem przez kolejne dwa lata tylko krytycznych poprawek bezpieczeństwa. PHP 7 i PHP 5 mają to wszystko już za sobą. Duża część sieci działa na kodzie, którego nie chronią już nawet jego twórcy, czyli dobrowolnie przystępuje do przegranego wyścigu z pierwszej sekcji.

Nasza strona internetowa to statyczne strony zbudowane z wyprzedzeniem, bez kodu po stronie serwera, który generowałby je podczas Twojej wizyty. Strona, która jest po prostu plikiem, daje bardzo niewiele do zaatakowania. Na pytanie, jak wiele może zostać trafione, to nasza odpowiedź: tak mało, jak tylko potrafimy.

Jakie dane o Tobie przechowujemy?

Mała powierzchnia ogranicza to, jak napastnik mógłby się dostać do środka. Drugie pytanie dotyczy tego, co by znalazł, gdyby pewnego dnia któremuś się to jednak udało. Nasza odpowiedź: uczynić znalezisko jak najnudniejszym, mniej danych, przechowywanych krócej.

Prosimy tylko o to, co jest potrzebne do prowadzenia konta. Nasza polityka prywatności (w języku angielskim) wymienia to wprost: nazwa użytkownika, adres e-mail, zaszyfrowane hasło i adres IP użyty przy rejestracji. Płatności przechodzą przez zewnętrznych operatorów płatności, więc dane Twojej karty są u specjalistów, których całym biznesem jest ich ochrona, a nie u nas.

Zaostrzamy też to, co dzieje się z upływem czasu. Stare, nieużywane konta będą usuwane automatycznie. Dane, które nie istnieją, nie mogą wyciec, nie mogą zostać skradzione i nie można ich zażądać. Konto porzucone przez Ciebie lata temu nie powinno leżeć jako obciążenie z Twoim nazwiskiem. Jeśli wyścig zostanie kiedykolwiek przegrany po naszej stronie płotu, nagroda na stole powinna być tak mała, jak tylko potrafimy ją uczynić.

Ta sama logika obowiązuje poza nami, bo inne firmy też przegrywają wyścigi. Wiele wycieków, które dotykają ludzi, zdarza się w sklepach, na forach i w usługach, do których zapisali się dawno temu. Dlatego oferujemy alerty o wyciekach danych: nasz Data Breach Scanner sprawdza znane wycieki danych pod kątem Twojego adresu e-mail i wysyła Ci wiadomość, jeśli się w nich pojawi, abyś mógł zmienić hasła, zanim wyciek zostanie wykorzystany.

Co się stanie, jeśli coś mimo wszystko zawiedzie?

Trzecie pytanie ma dwie połowy: odbudowę i zamknięcie luki. Najpierw odbudowa. Dobre planowanie bezpieczeństwa zakłada złe dni. Sprzęt zawodzi, dostawcy się zmieniają, a czasem właściwym ruchem jest po prostu odejść od jakiegoś elementu infrastruktury.

Nasze systemy są zbudowane tak, by w razie potrzeby można je było odtworzyć lub przenieść gdzie indziej. Dla Ciebie oznacza to, że awaria albo lokalizacja, która przestała spełniać nasze standardy, nie musi zamienić się w długą przerwę w działaniu, bo dotknięty system można odbudować lub przenieść. Jeśli kiedykolwiek uznamy, że jakieś środowisko nie jest już wystarczająco dobre, możemy je opuścić, zamiast z nim negocjować.

Odporność nie jest widowiskową cechą. Objawia się głównie tym, że rzeczy nadal działają, a w tym ujęciu to ona sprawia, że przegrana runda nie staje się przegranym sezonem.

Jak szybko poprawki trafiają do naszych systemów?

Druga połowa trzeciego pytania to szybkość. Nic z powyższego nie znosi potrzeby łatania; zmienia to, co łatanie musi udźwignąć. Przy małej powierzchni i aktualnym oprogramowaniu zastosowanie poprawki jest rutyną, a nie projektem.

Nasza reguła jest prosta: aktualizacje wychodzą, gdy tylko poprawki istnieją. Październikowe pomiary wyjaśniają dlaczego. Gdy próby wykorzystania luki nadchodzą w ciągu minut i godzin od publikacji poprawki, a czasem zanim ona powstanie, poprawka, która leży i czeka, nie chroni nikogo. Wydaną łatkę traktujemy jak strzał startera. Odcinek między powstaniem poprawki a jej zastosowaniem to jedyna część wyścigu, nad którą obrońca w pełni panuje, więc to jest ta część, której odmawiamy oddać.

A ponieważ nasz stos technologii jest mały, po prostu jest mniej do łatania, i tu właśnie trzy pytania się spotykają: im mniej jest do trafienia, tym szybciej zamyka się luka.

Zestawione obok siebie, pytania i odpowiadające im zasady wyglądają tak:

Co to wszystko oznacza dla Ciebie?

Oznacza to, że trzy pytania mają odpowiedzi, które możesz odczuć. Mniej kodu stoi między Tobą a Twoim kontem, więc jest mniej miejsc, w których coś może pójść źle. Istnieje mniej Twoich danych, więc nawet najgorszy scenariusz ujawnia niewiele. A nasze systemy można odbudować, więc nasz zły dzień nie musi stać się Twoją długą przerwą w dostępie.

Będziemy szczerzy co do granicy tego wszystkiego. Wyścigu, od którego zaczęliśmy, nie da się niezawodnie wygrywać, ani nam, ani nikomu, bo luki są czasem wykorzystywane, zanim ktokolwiek wie o ich istnieniu, i żadna architektura tego nie zmienia. Żaden dostawca nie może obiecać zerowego ryzyka, a każdy, kto to robi, sprzedaje pewność siebie, a nie bezpieczeństwo. Możemy natomiast obiecać kształt straty: niewiele dróg do środka, niewiele do zabrania i szybka droga powrotna. Nie możemy zagwarantować, że wygramy każdą rundę wyścigu. Zbudowaliśmy wszystko tak, by przegranie jednej kosztowało Cię jak najmniej, i uważamy, że ta obietnica, dotrzymywana konsekwentnie, jest warta więcej niż śmiała, której dotrzymać się nie da.

Bezpieczeństwo to także wspólny wysiłek. Najmocniejsza konfiguracja, jaką potrafimy zbudować, i tak zyskuje na dobrych nawykach po Twojej stronie, więc jeśli szukasz praktycznych kroków, zacznij od naszego przewodnika o tym, jak zwiększyć swoje bezpieczeństwo online (w języku angielskim). A jeśli wybierasz VPN, u nas czy u kogokolwiek innego, zapytaj dostawcę, jak myśli, a nie tylko co sprzedaje. Odpowiedź wiele mówi o tym, jak będą wyglądać Twoje spokojne tygodnie, i te głośne.