Inwentarz aplikacji
Wersja PHP, rozszerzenia, biblioteki i zależności, także te bez opiekuna.
Aktualizacja aplikacji PHP do wersji 8, krok po kroku i z testami
Dla PHP 8.2 poprawki bezpieczeństwa kończą się 31.12.2026, dla PHP 8.1 i starszych już się skończyły (stan: 2026-10). Przenosimy rozbudowywane od lat aplikacje PHP, także z szablonami Smarty i frontendem w jQuery, na PHP 8.4 lub 8.5. Testujemy każdy etap.
- Od 2012 r. PHP, Smarty i Slim
- Odpowiedź w ciągu jednego dnia roboczego
Gdy dostawca hostingu, ubezpieczyciel lub audyt pytają o wersję PHP
Wiele aplikacji PHP działa latami bez opieki, aż ktoś zapyta o wersję. Typowe powody aktualizacji to:
- Dostawca hostingu pobiera dopłatę za Państwa wersję PHP albo zapowiada jej wyłączenie.
- Klient, audyt lub ubezpieczyciel pyta o obsługiwane wersje.
- Wcześniejsza próba aktualizacji się nie udała i od tamtej pory nikt nie dotyka aplikacji.
- Programista odszedł, a aplikacja nadal działa na PHP 7.4 lub starszym.
Wersję, która działa, pokazuje panel hostingu albo polecenie php -v na serwerze. Terminy wsparcia wszystkich wersji podajemy niżej i na stronie Wersje PHP i koniec wsparcia.
Dlaczego warto aktualizować PHP na bieżąco: PHP2Shell w październiku 2026
21 października 2026 roku projekt PHP opublikował poprawki dwóch krytycznych luk w rdzeniu PHP, znanych jako PHP2Shell. Szczegóły krążyły w sieci już dzień wcześniej. Zagrożona była każda instalacja PHP obsługująca żądania WWW, niezależnie od tego, czy działa z PHP-FPM, Apache mod_php, php-cgi, FrankenPHP czy LiteSpeed. Atakujący nie potrzebował konta ani danych dostępowych, wystarczyło mu żądanie do serwera WWW.
- CVE-2026-109618, zdalne wykonanie kodu po wyczerpaniu pamięci: gdy PHP zabraknie pamięci w trakcie żądania, może przerwać pracę w połowie przygotowywania wewnętrznych danych żądania. Procedura porządkująca traktuje potem te niedokończone dane jako poprawne.
- CVE-2026-109619, zdalne wykonanie kodu przez nieaktualny stan: wewnętrzny stan żądania może przetrwać zwolnienie pamięci, w której był zapisany. Kolejne żądanie obsługiwane przez ten sam proces roboczy może go użyć, zanim zostanie wyzerowany.
Jeszcze tego samego dnia zaobserwowano próby ataków. Ponieważ dla wielu serwerów brakowało zaktualizowanych pakietów, urzędy, portale policji i duży szpital uniwersytecki w Niemczech zapobiegawczo wyłączyły swoje strony, podobnie jak instytucje w innych krajach Europy. Niemiecki federalny urząd bezpieczeństwa informatycznego BSI zalecał wyłączenie stron do czasu aktualizacji.
Na wspieranej wersji wystarczyła niewielka aktualizacja do PHP 8.5.12, 8.4.27, 8.3.36 lub 8.2.35. PHP 8.1 i starsze nie dostały oficjalnego wydania, tylko minimalne poprawki w kodzie źródłowym albo pakiety od dostawców LTS (stan: 2026-10).
Źródła: komunikat bezpieczeństwa projektu PHP z 21.10.2026 (otwiera się w nowym oknie), GHSA-w8hw-w9fx-j79w (otwiera się w nowym oknie) i GHSA-6wmf-4rv5-p3rp (otwiera się w nowym oknie).
Wniosek: przy bieżących aktualizacjach nowe wydanie poprawkowe testuje się i wdraża w kilka godzin. Skok o kilka wersji zajmuje od kilku dni do kilku tygodni.
Jak przebiega migracja do PHP 8: od inwentarza do przełączenia
-
Przegląd: co w aplikacji trzeba zmienić dla PHP 8
Spisujemy wersję, rozszerzenia, biblioteki, Smarty, jQuery, bazę danych i serwer. Sprawdzamy kod pod kątem niezgodności i pokazujemy, co przestaje działać w PHP 8. Wynikiem jest plan etapów z nakładem pracy w dniach roboczych.
-
Środowisko testowe i przypadki testowe
Uruchamiamy środowisko testowe z kopią kodu i bazy danych, a system produkcyjny zostawiamy bez zmian. Dla krytycznych procesów tworzymy przed każdą zmianą przypadki testowe, żeby odchylenia od dotychczasowego działania były widoczne.
-
Aktualizacja etapami
Podnosimy wersję aplikacji etapami, zwykle o jedną wersję naraz, na przykład z 7.4 przez 8.0 i 8.1 do wersji docelowej. Po każdym etapie uruchamiamy przypadki testowe, żeby aplikacja pozostała sprawna.
-
Przełączenie z możliwością wycofania
Przełączamy produkcję w oknie serwisowym o niskim ruchu i mamy gotowy, sprawdzony plan wycofania. Potem obserwujemy logi błędów i czasy odpowiedzi oraz poprawiamy zauważone problemy.
Co zawiera wynik przeglądu
-
-
Lista niezgodności
Miejsca w kodzie, które przestają działać w PHP 8, uporządkowane według ryzyka i nakładu pracy.
-
Plan etapów z wersją docelową
Kolejność kroków, wersja docelowa 8.4 lub 8.5 i nakład pracy w dniach roboczych.
-
Raport z testów po każdym etapie
Co sprawdzono, co się zmieniło i co pozostaje otwarte.
-
Wycofanie i przekazanie
Przebieg przełączenia, sprawdzona droga powrotu i dokumentacja nowego stanu.
Do kiedy poszczególne wersje PHP dostają poprawki bezpieczeństwa
| Data | Zdarzenie | Źródło |
|---|---|---|
| 2018-12-31 | PHP 5.6: koniec poprawek bezpieczeństwa. | php.net (otwiera się w nowym oknie) |
| 2019-01-10 | PHP 7.0: koniec poprawek bezpieczeństwa. | php.net (otwiera się w nowym oknie) |
| 2019-12-01 | PHP 7.1: koniec poprawek bezpieczeństwa. | php.net (otwiera się w nowym oknie) |
| 2020-11-30 | PHP 7.2: koniec poprawek bezpieczeństwa. | php.net (otwiera się w nowym oknie) |
| 2021-12-06 | PHP 7.3: koniec poprawek bezpieczeństwa. | php.net (otwiera się w nowym oknie) |
| 2022-11-28 | PHP 7.4: koniec poprawek bezpieczeństwa. | php.net (otwiera się w nowym oknie) |
| 2023-11-26 | PHP 8.0: koniec poprawek bezpieczeństwa. | php.net (otwiera się w nowym oknie) |
| 2025-12-31 | PHP 8.1: koniec poprawek bezpieczeństwa. | php.net (otwiera się w nowym oknie) |
| 2026-12-31 | PHP 8.2: koniec poprawek bezpieczeństwa. | php.net (otwiera się w nowym oknie) |
| 2027-12-31 | PHP 8.3: koniec poprawek bezpieczeństwa. | php.net (otwiera się w nowym oknie) |
| 2028-12-31 | PHP 8.4: koniec poprawek bezpieczeństwa. Możliwa wersja docelowa. | php.net (otwiera się w nowym oknie) |
| 2029-12-31 | PHP 8.5: koniec poprawek bezpieczeństwa. Możliwa wersja docelowa. | php.net (otwiera się w nowym oknie) |
Co zwykle przestaje działać przy zmianie wersji
| Skok wersji | Co zwykle przestaje działać | Co sprawdzamy |
|---|---|---|
| Z PHP 5.6 na 7.x | Stary interfejs mysql i funkcje ereg zostały usunięte, a mcrypt od wersji 7.2 nie należy już do rdzenia. Warstwa bazy danych wymaga mysqli lub PDO. | Wszystkie dostępy do bazy danych, szyfrowanie i biblioteki pomocnicze. |
| Z PHP 7.4 na 8.0 | Porównania liczb z tekstem dają inne wyniki, wiele dawnych ostrzeżeń staje się błędami, a funkcje takie jak each() i create_function() zostały usunięte. | Walidację, obsługę błędów, dostępy do bazy danych i konstruktory w starym stylu PHP 4. |
| Między PHP 8.1 a 8.5 | Zwykle aplikacja działa dalej, ale w logu pojawiają się ostrzeżenia o przestarzałych konstrukcjach, na przykład null jako argument funkcji, właściwości dynamiczne lub utf8_encode(). | Zbieramy ostrzeżenia i usuwamy je, zanim konstrukcje znikną z języka. |
| Wokół kodu | Kodowanie znaków (latin1 lub utf8mb4), biblioteki bez opiekuna do PDF, Excela lub SOAP, zaplanowane zadania i wersja bazy danych. | Te punkty sprawdzamy już w inwentarzu, nie dopiero w teście. |
Smarty, jQuery i bazę danych sprawdzamy razem z kodem
Smarty. Projekt Smarty wydaje poprawki bezpieczeństwa tylko dla najnowszych wersji pobocznych Smarty 4 i 5, a Smarty 2 i 3 nie są już rozwijane (stan: 2026-10). Najwięcej pracy wymagają szablony z własnymi wtyczkami lub blokami {php}.
jQuery. Działa w przeglądarce i nie zależy od PHP, ale często tkwi w tych samych szablonach. jQuery 1.x i 2.x nie są już wspierane (stan: 2026-10). Zwykle wystarcza droga przez jQuery 3 lub 4 z jQuery Migrate.
Baza danych. Wersję MySQL lub MariaDB sprawdzamy w tym samym inwentarzu co kod.
Wszystkie zmiany w poszczególnych wersjach wymieniają przewodniki migracyjne z podręcznika PHP (otwiera się w nowym oknie) (po angielsku). Więcej o pracy naszych inżynierów z PHP znajdą Państwo na stronie Aplikacje PHP: przejęcie, aktualizacja i dalsze utrzymanie, a typy systemów na stronie Doświadczenie.
Doświadczenie naszych inżynierów z PHP, Smarty i bazami danych
- PHP
- Od 2012 r., ze Smarty, Slim i WordPress
- Full stack i DevOps
- Od 2012 r., od kodu po serwer
- Bazy danych
- MySQL i MariaDB, także w klastrze Galera; migracje na przykład z Firebird na MariaDB
- Serwery
- Linux, Nginx, Apache i Docker
Jak zaczynamy aktualizację PHP
- Kod, dane dostępowe i dokumentacja zostają u Państwa.
- Na końcu otrzymują Państwo dokumentację przekazania, na podstawie której może pracować dalej także inny dostawca.
- Mówimy też wprost, gdy aktualizacja się nie opłaca, na przykład dlatego, że aplikacja wkrótce zostanie zastąpiona.
A co, jeśli u nas ktoś będzie niedostępny? Dokumentację sporządzamy na życzenie. Repozytorium z reguły znajduje się u Państwa. Zastępstwo organizujemy na życzenie.
Aktualizacja PHP należy do naszej usługi Migracja i modernizacja.
Pierwszy krok: przegląd systemu legacy lub skan zgodności z PHP 8
Przegląd systemu legacy
Dla firm z systemem, którego nikt już dokładnie nie zna: przed aktualizacją, przed migracją lub przy zmianie dostawcy.
- Inwentarz wersji i zależności
- Mapa aplikacji, bazy danych, serwera i poczty e-mail
- Rejestr ryzyk dotyczących bezpieczeństwa, wsparcia i wiedzy
- Ocena kopii zapasowych i odtwarzania danych
- Rekomendacja „zostać przy obecnej wersji, podnieść wersję lub migrować” z macierzą opcji, która obejmuje także „przeniesienie do kontenera” i „udostępnienie jako API”
- Oszacowanie nakładu pracy w dniach
Cena obejmuje jeden system, czyli jedną aplikację wraz z jej bazą danych i serwerem. Kolejne systemy wyceniamy osobno.
Co zawiera wynik
Pisemny raport z inwentaryzacją, rejestrem ryzyk, rekomendacją i oszacowaniem nakładu pracy. Raport należy do Państwa.
Skan zgodności z PHP 8
Dla firm z rozbudowywaną latami aplikacją PHP, które przed aktualizacją do PHP 8 chcą wiedzieć, co przestanie działać i ile pracy to wymaga.
- Inwentarz wersji PHP, rozszerzeń, bibliotek i bazy danych
- Sprawdzenie kodu pod kątem miejsc, które w PHP 8 przestają działać
- Szablony Smarty i frontend w jQuery w tym samym przebiegu
- Lista niezgodności według ryzyka i nakładu pracy
- Plan etapów do wersji docelowej z oszacowaniem nakładu pracy w dniach roboczych
Zakres i cenę ustalamy w rozmowie wstępnej i potwierdzamy na piśmie przed rozpoczęciem pracy. Samą aktualizację wykonujemy na życzenie jako osobne zlecenie.
Co zawiera wynik
Pisemna lista niezgodności z planem etapów i oszacowaniem nakładu pracy. Lista należy do Państwa.
Przypadek z naszej pracy
-
PHP 8.2 i limit 30 sekund: strony czekały na blokadę sesji
Portale internetowe · 4 godziny
Po migracji z PHP 7.4 na PHP 8.2 ta sama strona raz ładowała się normalnie, a raz kończyła się błędem po 30 sekundach. Odtworzyliśmy obie wersje obok siebie i znaleźliśmy przyczynę: około 20 równoległych wywołań AJAX jednego użytkownika czekało po kolei na blokadę pliku sesji. Naprawione jedną linią na skrypt, bez przepisywania aplikacji.
Pytania o aktualizację do PHP 8
Czy musimy przepisać naszą aplikację PHP od nowa, żeby działała na PHP 8?
Zazwyczaj nie. Jeśli problemem jest tylko wersja PHP, aktualizujemy aplikację etapami i nie zmieniamy jej logiki. Przepisanie od nowa rzadko się opłaca.
Przepisanie wchodzi w grę, gdy framework nie jest już rozwijany, brakuje testów, a reguły biznesowe da się spisać. Czy dotyczy to Państwa aplikacji, pokaże Przegląd systemu legacy. Otrzymają Państwo rekomendację i oszacowanie nakładu pracy w dniach roboczych.
Ile kosztuje aktualizacja do PHP 8 i jak długo trwa?
Wiarygodną liczbę podamy dopiero po zapoznaniu się z Państwa aplikacją. Nakład pracy i czas zależą od jej stanu, a nie tylko od rozmiaru. Decydują wersja wyjściowa, rozszerzenia i biblioteki bez opiekuna, Smarty, baza danych, kodowanie znaków i istniejące testy.
Stałe ceny podajemy dla produktów wejściowych, tutaj dla Przeglądu systemu legacy z inwentaryzacją pod kątem PHP 8. Jego wynikiem jest oszacowanie nakładu pracy w dniach roboczych. Potem przygotowujemy ofertę na aktualizację: za stałą cenę, jeśli zakres jest jasny, w przeciwnym razie z rozliczeniem według czasu.
Czy po aktualizacji aplikacja będzie działać tak samo jak wcześniej?
Taki jest cel, a testy potwierdzają go dla procesów, które nimi objęliśmy. Zanim cokolwiek zmienimy, przygotowujemy przypadki testowe dla krytycznych funkcji. Po każdym etapie uruchamiamy je ponownie i od razu widzimy odchylenia.
Gwarancji dla procesów, których nikt nie sprawdzał, przy oprogramowaniu rozwijanym latami nie ma. Dlatego środowisko testowe i droga powrotu są stałą częścią naszego sposobu pracy. Produkcję przełączamy dopiero wtedy, gdy przypadki testowe kończą się powodzeniem, a droga powrotu do starego stanu pozostaje otwarta do czasu stabilnej pracy.
Co się stanie, jeśli aktualizacja nie zostanie ukończona na czas?
Aplikacja nadal działa. Dla PHP 8.2 po 31.12.2026 nie będą jednak wydawane aktualizacje bezpieczeństwa (stan: 2026-10), a z każdą później ujawnioną luką ryzyko rośnie.
Jeśli zabraknie czasu na pełną aktualizację, są dwa rozwiązania pomostowe. Cel pośredni, na przykład PHP 8.3, otrzymuje aktualizacje bezpieczeństwa do 31.12.2027 (stan: 2026-10) i daje dodatkowy rok. Dodatkowo można ograniczyć dostęp do aplikacji, ustawić przed nią zaporę aplikacyjną (WAF) i dopuścić dostęp administracyjny tylko przez VPN. To zmniejsza ryzyko, ale go nie usuwa.
Czy Extended Support u naszego dostawcy hostingu to alternatywa dla aktualizacji PHP?
Krótkoterminowo Extended Support może dać czas, ale nie zastępuje aktualizacji. Obowiązuje tylko u danego dostawcy hostingu i kończy się najpóźniej wraz z wycofaniem danej wersji PHP. Nie mówi też nic o tym, czy Państwa aplikacja działa na nowej wersji.
Dopłata jest sygnałem ostrzegawczym: dostawca hostingu uważa Państwa wersję za wygasającą. Kto i tak zamierza odejść od klasycznego hostingu, znajdzie drogę na stronie Z hostingu do kontenera.
Czy WAF wystarczy?
Samodzielnie nie. WAF, czyli zapora aplikacji internetowych, filtruje typowe ataki przed aplikacją i daje czas, ale nie zamyka luki w kodzie. Dlatego łączymy go z usuwaniem znanych podatności, segmentacją sieci i dostępem administracyjnym wyłącznie przez VPN.
WAF z regułami dopasowanymi do Państwa aplikacji wywołuje mniej fałszywych alarmów i zwykle chroni skuteczniej niż konfiguracja domyślna. Jeśli kodu nie da się szybko zmienić, WAF z izolacją systemu jest rozwiązaniem pomostowym do czasu aktualizacji. Ryzyko maleje wtedy, ale nie znika.
Kiedy mogą Państwo zacząć?
Pierwszą odpowiedź otrzymają Państwo w ciągu jednego dnia roboczego. Kiedy zaczniemy pracę, zależy od bieżącego obłożenia i od zakresu. Powiemy to Państwu wiążąco podczas rozmowy wstępnej. Jeśli sprawa jest pilna, Ocena awaryjna w 48 godzin rozpoczyna się z chwilą, gdy uzyskamy dostęp do systemu.
Jaka wersja PHP działa u Państwa?
Wystarczy podać wersję, dostawcę hostingu i powód w kilku zdaniach. Odpowiadamy w ciągu jednego dnia roboczego i proponujemy odpowiedni pierwszy krok.