Krytyczne luki w PHP z października 2026: co zrobić ze starą aplikacją?

21 października 2026 roku projekt PHP opublikował poprawki dwóch krytycznych podatności, które mogą prowadzić do zdalnego wykonania kodu bez logowania. Poprawione wersje to PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Oficjalne zalecenie jest jednoznaczne: użytkownicy PHP powinni zaktualizować środowisko natychmiast.

Jeżeli Twoja firma korzysta ze starszej aplikacji PHP, nie oznacza to automatycznie, że trzeba ją od razu przepisać. Najpierw trzeba zastosować poprawkę do środowiska. Dopiero test zgodności pokaże, czy aplikacja może dalej działać bez zmian, wymaga aktualizacji bibliotek, etapowej modernizacji czy kontrolowanej przebudowy.

Przepisanie kodu nie zastępuje poprawki bezpieczeństwa w interpreterze PHP. Z kolei sama aktualizacja PHP nie gwarantuje, że stara aplikacja będzie zgodna z nowym środowiskiem. To dwa osobne problemy i dwa osobne etapy decyzji.

Ostatnia weryfikacja źródeł: 23.10.2026. Przed wykonaniem zmian sprawdź aktualny komunikat projektu PHP oraz informacje dostawcy systemu operacyjnego, hostingu lub obrazu kontenera.

Co dokładnie ogłosił projekt PHP?

Komunikat z 21 października dotyczy podatności CVE-2026-109618 i CVE-2026-109619. Projekt PHP wskazuje, że ryzyko dotyczy instalacji obsługujących żądania internetowe, między innymi PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Najwyższe ryzyko opisano dla mod_php, gdzie potwierdzono możliwość wywołania ataku jeszcze przed uruchomieniem kodu aplikacji.

Poprawki znalazły się w wersjach:

• PHP 8.5.12;
• PHP 8.4.27;
• PHP 8.3.36;
• PHP 8.2.35.

Niższy numer wersji w jednej z tych gałęzi wymaga sprawdzenia. W dystrybucjach Linuksa poprawka może zostać dostarczona jako backport w pakiecie dostawcy bez przejścia na identyczny numer wydania jak w projekcie PHP. Dlatego nie wystarczy porównać samego ciągu wersji. Trzeba również ustalić źródło pakietu i sprawdzić komunikat jego dostawcy.

PHP 8.1 i starsze gałęzie nie otrzymują już aktualizacji od projektu PHP. Wybrani dostawcy systemów i usług LTS mogą dostarczać własne poprawki, ale ich obecność trzeba potwierdzić. Według tabeli wsparcia PHP gałąź 8.2 otrzymuje już tylko krytyczne poprawki bezpieczeństwa i kończy wsparcie 31 grudnia 2026 roku. Nawet po zastosowaniu bieżącej poprawki warto więc zaplanować przejście na nowszą, wspieraną gałąź.

Dodatkowa informacja z 23 października 2026

23 października projekt PHP opublikował osobny komunikat dotyczący mało prawdopodobnego wektora związanego z funkcją śledzenia postępu wysyłania plików w sesji. Projekt PHP zasugerował wyłączenie session.upload_progress.enabled do czasu kolejnego regularnego wydania, aby domknąć ochronę przed tym rzadkim wektorem.

Ten przypadek wymaga nietypowego połączenia ustawień i zachowania aplikacji. Oficjalny komunikat wskazuje też, że aplikacje, które nie zmieniają w czasie działania sposobu serializacji sesji, mogą pozostawić tę funkcję włączoną. Nie warto więc kopiować ustawienia w ciemno. Administrator powinien sprawdzić faktyczną konfigurację, sposób obsługi sesji i aktualne zalecenie dla używanego pakietu PHP.

Pierwszy krok: sprawdź środowisko używane przez stronę

Polecenie php -v pokazuje wersję używaną przez interfejs wiersza poleceń. Strona internetowa może działać przez inny interfejs PHP, na przykład PHP-FPM albo moduł Apache. Oficjalna dokumentacja PHP rozróżnia te interfejsy jako SAPI.

Do pierwszej oceny potrzebne są cztery informacje:

1. wersja PHP rzeczywiście obsługująca żądania strony lub aplikacji;
2. sposób uruchamiania PHP, na przykład FPM, mod_php, CGI albo LiteSpeed;
3. źródło pakietu lub obrazu, z którego pochodzi PHP;
4. osoba albo firma odpowiedzialna za aktualizację serwera i restart procesów.

Takie dane można uzyskać z panelu hostingu, konfiguracji wdrożenia albo od administratora. Tymczasowych stron diagnostycznych z konfiguracją PHP nie należy pozostawiać publicznie dostępnych, ponieważ mogą ujawniać niepotrzebne informacje o środowisku.

Pilna aktualizacja i modernizacja aplikacji to dwa różne zadania

Aktualizacja środowiska usuwa podatność w PHP, jeżeli została prawidłowo dostarczona i uruchomiona. Modernizacja dotyczy kodu aplikacji, frameworka, bibliotek, integracji oraz sposobu wdrażania i testowania zmian.

W praktyce kolejność powinna wyglądać tak:

1. Potwierdź podatne środowisko. Ustal wersję, SAPI i dostawcę pakietu.
2. Wyznacz osobę odpowiedzialną za serwer. Może to być administrator, hosting, obecny wykonawca albo zespół wewnętrzny.
3. Sprawdź możliwość powrotu. Kopia plików i bazy jest przydatna tylko wtedy, gdy wiadomo, jak ją odtworzyć.
4. Uruchom test na poprawionej wersji. Środowisko testowe powinno możliwie dobrze odwzorować produkcję, zwłaszcza wersje rozszerzeń i usług.
5. Sprawdź krytyczne procesy. Logowanie, formularze, płatności, importy, zadania cykliczne, wysyłkę wiadomości i integracje trzeba dobrać do rzeczywistej roli systemu.
6. Wdróż poprawkę i potwierdź działające procesy. Aktualizacja pakietu bez uruchomienia nowych procesów PHP może nie zakończyć zmiany.
7. Zapisz problemy zgodności jako osobny zakres. Nie blokuj pilnej poprawki nieograniczonym projektem przebudowy, ale nie ukrywaj błędów, które ujawniły testy.

Jeżeli są oznaki, że system mógł zostać naruszony, sama instalacja poprawki nie zastępuje osobnej obsługi incydentu. Zakres takiego działania trzeba uzgodnić z osobą odpowiedzialną za bezpieczeństwo i infrastrukturę.

Cztery możliwe kierunki po zabezpieczeniu środowiska

Numer wersji PHP nie wystarcza do wyboru jednego z tych kierunków. Ta sama stara wersja może oznaczać prostą aktualizację w jednej aplikacji i większy projekt zgodności w innej.

Kiedy może wystarczyć sama aktualizacja?

Najprostszy wariant jest możliwy, gdy aplikacja korzysta ze wspieranego frameworka i bibliotek, ma powtarzalne wdrożenie, a najważniejsze procesy można sprawdzić przed zmianą. Wtedy zakres może ograniczyć się do przygotowania kopii, testu na poprawionej wersji, aktualizacji środowiska i kontroli po wdrożeniu.

Nawet w tym wariancie nie warto pomijać zadań uruchamianych poza przeglądarką. Harmonogramy, kolejki, importy i skrypty mogą używać innej konfiguracji niż część obsługująca stronę.

Kiedy trzeba zaktualizować framework lub biblioteki?

Stara aplikacja może zawierać składnię usuniętą z nowego PHP, niewspierany framework albo pakiety porzucone przez autorów. Problemem bywają także własne moduły i rozszerzenia, których nie da się po prostu podmienić.

W takim przypadku warto najpierw ustalić najmniejszy bezpieczny zakres zgodności. Czasem wystarczy podnieść kilka zależności i poprawić ograniczoną część kodu. Czasem kolejne wersje frameworka wymagają etapowej migracji. Tego nie da się rzetelnie ocenić na podstawie samego komunikatu o błędzie.

Kiedy modernizować etapami?

Etapowa modernizacja jest rozsądna, gdy aplikacja nadal realizuje ważne procesy, przechowuje potrzebne dane i ma części, które mogą działać bez większych zmian. Zamiast odtwarzać wszystko jednocześnie, można najpierw zabezpieczyć krytyczne zachowania testami, ustabilizować wdrożenie i wymieniać najbardziej problematyczne elementy.

Każdy etap powinien mieć własny rezultat, kryteria odbioru i sposób wycofania. Dzięki temu dalsze decyzje opierają się na działającym systemie, a nie tylko na założeniach.

Szersze kryteria opisujemy w poradniku Modernizacja istniejącego systemu czy budowa od zera.

Kiedy przebudowa może być uzasadniona?

Przebudowę warto rozważyć, gdy kluczowe zależności nie są wspierane, aplikacji nie da się odtworzyć w kontrolowanym środowisku, drobne zmiany powodują trudne do przewidzenia błędy albo architektura nie pozwala oddzielić procesów potrzebnych firmie.

Nadal nie oznacza to jednego dużego przełączenia. Można najpierw odtworzyć jeden proces, porównać dane i dopiero później rozszerzać zakres. Pełna budowa od zera bez rozpoznania reguł biznesowych często przenosi stare problemy do nowego kodu albo usuwa zachowania, o których nikt nie pamiętał podczas tworzenia specyfikacji.

Dwa przykłady, dwie różne drogi

W projekcie OBIBOOK najpierw naprawiliśmy niedziałający import CSV i działanie na urządzeniach mobilnych. Dopiero po poznaniu procesu wykonaliśmy pełną przebudowę katalogu książek. Naprawa i przebudowa były odrębnymi etapami.

W przypadku Sprawdzeni.pl wcześniejsza aplikacja była trudna w użyciu i regularnie zgłaszała błędy. Jej stan przemawiał za napisaniem systemu od podstaw z zachowaniem i rozwinięciem koncepcji wizualnej właściciela.

Żaden z tych projektów nie został rozpoczęty z powodu podatności opisanych w tym artykule. Pokazują jedynie, że po rozpoznaniu istniejącego systemu właściwą decyzją może być naprawa, praca etapowa albo przebudowa. Nie ma jednej odpowiedzi dla każdej starej aplikacji.

Co przygotować do pierwszej oceny?

Nie musisz znać wszystkich szczegółów technicznych. Przydatne będą:

• adres i krótki opis roli aplikacji w firmie;
• treść komunikatu od hostingu lub administratora, bez danych dostępowych;
• wersja PHP i sposób jego uruchamiania, jeśli są znane;
• nazwa oraz wersja frameworka lub CMS, jeśli są znane;
• informacja, skąd pochodzi kod i czy odpowiada wersji produkcyjnej;
• informacja o kopiach, środowisku testowym i sposobie wdrażania;
• lista procesów, które trzeba sprawdzić po aktualizacji;
• lista integracji i zadań wykonywanych w tle;
• oczekiwany rezultat pierwszego etapu.

Nie wysyłaj przez formularz haseł, kluczy API, kopii bazy ani danych klientów. Bezpieczny sposób przekazania materiałów ustalamy po uzgodnieniu zakresu.

Możesz wcześniej skorzystać z checklisty przejęcia aplikacji. Pomaga uporządkować dostępne informacje, ale nie zastępuje technicznej diagnozy.

Czego nie da się obiecać przed sprawdzeniem aplikacji?

Przed analizą konkretnego systemu nie można odpowiedzialnie zagwarantować, że:

• aktualizacja PHP nie będzie wymagała żadnej zmiany w kodzie;
• wszystkie biblioteki mają bezpieczne i zgodne zamienniki;
• kopia pozwoli odtworzyć system w wymaganym czasie;
• każdą część aplikacji warto zachować;
• przebudowa będzie tańsza niż modernizacja;
• sama poprawka PHP rozwiąże wszystkie problemy bezpieczeństwa aplikacji.

Jeśli potrzebujesz szerszego rozpoznania ryzyk, zobacz audyt bezpieczeństwa aplikacji. Jeżeli po ustabilizowaniu systemu potrzebna jest stała opieka, można osobno uzgodnić utrzymanie aplikacji lub sklepu.

Sprawdźmy, czego wymaga Twoja aplikacja

Napisz, do czego firma używa systemu, jaki komunikat wywołał potrzebę zmiany i czego nie można utracić podczas aktualizacji. Jeżeli znasz wersję PHP, framework, sposób uruchamiania oraz stan dostępu do kodu i hostingu, możesz je podać. Brak tych informacji nie blokuje pierwszej rozmowy.

Nie wysyłaj sekretów ani danych klientów. Na początku potrzebujemy opisu sytuacji i pierwszego oczekiwanego rezultatu.

Sprawdźmy, czego wymaga Twoja aplikacja albo najpierw uporządkuj materiały w checkliście.

Źródła

Źródła sprawdzone 23.10.2026:

• PHP: Security advisory - Critical remote code execution vulnerabilities, update now
• PHP: Informational advisory - Session upload progress
• PHP: Supported Versions
• PHP security advisory: CVE-2026-109618, RCE via OOM corruption
• PHP security advisory: CVE-2026-109619, RCE via stale global state
• PHP Manual: php_sapi_name
• PHP Manual: phpversion