Wersje PHP i daty wsparcia — która wersja jest bezpieczna [2026]

Które wersje PHP są jeszcze bezpieczne, a które są już po końcu wsparcia?

Ta strona zbiera pełny harmonogram wsparcia PHP — daty premier, końce poprawek błędów i bezpieczeństwa — oraz praktyczną odpowiedź, na jaką wersję powinien celować projekt w 2026 roku. Traktuj to jako punkt odniesienia przy planowaniu aktualizacji, audytach bezpieczeństwa i rozmowach z hostingiem.

Najważniejsze: W 2026 roku bezpieczne są trzy wersje: PHP 8.4 i 8.5 (pełne wsparcie) oraz 8.3 (tylko poprawki bezpieczeństwa do końca 2027). PHP 8.2 kończy wsparcie 31 grudnia 2026. Wszystko starsze — 8.1, 8.0, 7.x, 5.6 — jest po EOL i nie dostaje żadnych łatek.

Jak działa cykl wydawniczy PHP

PHP wydaje nową wersję główną raz w roku, w listopadzie lub grudniu. Każda gałąź dostaje cztery lata wsparcia — cykl wydłużono z trzech do czterech lat w marcu 2024 roku (RFC „release cycle update"):

• lata 1–2: pełne wsparcie (active support) — poprawki błędów i bezpieczeństwa,
• lata 3–4: wsparcie bezpieczeństwa (security support) — wyłącznie krytyczne poprawki bezpieczeństwa, bez poprawek błędów,
• po 4 latach: end of life (EOL) — żadnych poprawek, żadnych wydań.

Wydania pomniejsze (8.4.1, 8.4.2…) pojawiają się co kilka tygodni w ramach aktywnej gałęzi. Po EOL gałąź nie dostaje już nawet krytycznych łatek — to fundamentalna różnica między „starą wersją" a „wersją bez wsparcia".

• ## Tabela: wersje PHP i daty wsparcia

Daty pochodzą z oficjalnego harmonogramu php.net i zestawienia endoflife.date (stan: październik 2026). Kolejna premiera — PHP 8.6 — spodziewana jest pod koniec 2026 roku.

Uwaga: Jeśli Twój system działa na PHP 8.2, zostały dwa miesiące do końca wsparcia bezpieczeństwa. Jeśli na 8.3 — rok. Każda wersja poniżej 8.2 jest dziś bez łatek bezpieczeństwa. Sprawdź wersję przez php -v albo w panelu hostingu.

Na jaką wersję PHP powinien celować projekt

Wybór wersji to kompromis między nowością a kompatybilnością zależności. Praktyczne rekomendacje dla 2026 roku.

Zasada praktyczna jest prosta: celuj w wersję z pełnym wsparciem, jeśli pozwalają na to zależności. Jeśli nie — wybierz najnowszą, którą wspiera cały stack, i zaplanuj kolejny krok. „Zostanie na starej wersji, bo działa" to odkładanie kosztu, nie jego unikanie.

Co się dzieje z systemem po EOL wersji PHP

Sam system nie przestaje działać — interpreter wykonuje kod dalej. Zmienia się natomiast otoczenie.

• Podatności zostają bez łaty. Każda nowa luka w interpreterze i bibliotekach standardowych pozostaje otwarta na zawsze. Część luk da się wykorzystać zdalnie, bez dostępu do serwera.

• Zależności przestają się aktualizować. Nowe wersje bibliotek wymagają nowszego PHP — bez migracji tracisz też poprawki bezpieczeństwa w zależnościach, nie tylko w interpreterze.

• Hostingi wygaszają stare wersje. Po EOL wersje utrzymują się na serwerach zwykle rok–dwa, potem znikają albo stają się płatnym dodatkiem. Migracja pod presją terminu hostingu jest droższa niż zaplanowana.

• Rosną koszty ludzi. Programistów znających stare wersje jest coraz mniej — stawki za utrzymanie rosną, a znalezienie wykonawcy trwa.

• Pojawiają się wymogi formalne. Audyty bezpieczeństwa, RODO, wymagania klientów B2B i ubezpieczycieli coraz częściej pytają o wspierane wersje komponentów. System po EOL to pozycja ryzyka w każdym takim przeglądzie.

• Odwrotna strona medalu: każda aktualizacja to też zysk. PHP 8.x jest istotnie szybsze od 7.x i 5.6 (optymalizacje silnika, JIT), a nowsze wersje dostają funkcje, które upraszczają kod — od enums i readonly po property hooks. Migracja to nie tylko „łatki", to także wydajność i nowsze biblioteki.

Jak zaplanować aktualizację krok po kroku

Kolejność działań jest zawsze taka sama, niezależnie od wersji startowej.

1. Sprawdź stan — wersja PHP, wersja frameworka/platformy, lista zależności i ich wymagania. composer outdated, panel hostingu, php -v.
2. Zrób audyt zgodności — PHPCompatibility i PHPStan pokażą, co przestanie działać na docelowej wersji. Wynik to lista blokad, czyli plan migracji.
3. Zabezpiecz się testami — testy ścieżek krytycznych przed migracją; bez nich każda zmiana zachowania wyjdzie na produkcji.
4. Zrefaktoryzuj automatycznie — Rector ma rulesety dla przejść między wersjami i robi 80–90% mechanicznej pracy.
5. Wdróż przez staging — docelowa wersja z tymi samymi rozszerzeniami co produkcja, testy, potem produkcja poza szczytem z planem wycofania.

Dokładny opis każdego etapu — z komendami i konfiguracją — znajdziesz w przewodniku o migracji PHP na 8.x. Jeśli działasz na 8.2 i patrzysz na deadline 31 grudnia 2026, scenariusz i plan czasowy opisuję w artykule o końcu wsparcia PHP 8.2.

Wersje PHP w liczbach — co mówią dane

Warto wiedzieć, jak wygląda adopcja wersji w praktyce, bo to wpływa na wsparcie bibliotek i hostingów.

• PHP 5.6 zakończył życie w 2018 roku, ale jeszcze przez lata pojawiał się na produkcji — dziś to wersja spotykana już rzadko, głównie w systemach wewnętrznych i „zamrożonych" wdrożeniach.
• PHP 7.x dominował w latach 2016–2022 — wiele aplikacji z tego okresu nadal działa, często na 7.4.
• PHP 8.x to obecny standard — 8.1 i starsze 8.x są stopniowo wypierane przez 8.2–8.4.
• WordPress od wersji 6.x rekomenduje PHP 8.x, a PrestaShop 8/9 wspiera 8.1–8.4 — platformy ciągną ekosystem w górę.

Dla właściciela systemu wniosek jest jeden: im dalej od aktualnych wersji, tym mniejsza dostępność wsparcia — bibliotek, wykonawców, hostingów. Aktualizacja „o jedną wersję" raz na dwa lata jest znacznie tańsza niż skok przez trzy generacje raz na sześć lat.

Najczęściej zadawane pytania

Która wersja PHP jest najbezpieczniejsza w 2026 roku?

PHP 8.5 i 8.4 — obie mają pełne wsparcie (poprawki błędów i bezpieczeństwa). PHP 8.3 dostaje tylko poprawki bezpieczeństwa do końca 2027. Wszystkie wersje 8.2 i starsze są w fazie security support z kończącym się terminem (8.2) albo po EOL.

Czy PHP 7.4 jest jeszcze wspierane?

Nie. PHP 7.4 zakończyło wsparcie bezpieczeństwa 28 listopada 2022 roku. System na 7.4 działa, ale nie dostaje żadnych łatek — ani w interpreterze, ani (przez wymagania wersji) w większości aktualizowanych bibliotek. Migracja z 7.4 na 8.x to typowo 1–2 tygodnie pracy.

Co to jest end of life (EOL) wersji PHP?

EOL to moment, w którym gałąź PHP przestaje dostawać jakiekolwiek aktualizacje — również krytyczne poprawki bezpieczeństwa. Po EOL nowo odkryte podatności pozostają bez łaty. Data EOL jest znana z góry, co odróżnia PHP od wielu projektów open source — można się do niej przygotować.

Czy hosting może zmusić mnie do aktualizacji PHP?

Pośrednio tak. Hostingi wygaszają obsługę wersji po EOL — najpierw przestają je aktualizować, potem usuwają z serwerów albo przenoszą do płatnych „dodatków legacy". Jeśli system nie działa na nowszej wersji, zmiana hostingu to dodatkowy koszt i ryzyko przenosin.

Czy po EOL wersji PHP można kupić przedłużone wsparcie?

Tak — firmy takie jak Zend czy TuxCare sprzedają komercyjne łaty bezpieczeństwa dla wersji po EOL (extended support). To rozwiązanie buforowe dla dużych systemów w trakcie migracji, kosztuje zwykle kilka–kilkanaście tysięcy złotych rocznie i nie zastępuje docelowej aktualizacji.

Jak często trzeba aktualizować PHP?

• Realistycznie: raz na 2–3 lata, przeskakując o jedną–dwie wersje. Każda aktualizacja pojedynczej wersji jest tania (dni pracy), a skok przez trzy generacje naraz — drogi i ryzykowny. Najlepszy rytm to aktualizacja na rok–dwa przed EOL aktualnej wersji, gdy biblioteki są już gotowe.

Źródła

• PHP.net — wspierane wersje
• PHP.net — wersje po zakończeniu wsparcia (EOL)
• endoflife.date — harmonogram PHP
• PHP RFC — wydłużenie cyklu wydawniczego do 4 lat
• PHP.Watch — status i zmiany wersji PHP