# Konec podpory PHP: rizika zastaralých verzí

> Konec podpory PHP: co se děje po skončení podpory, proč jsou PHP 8.1 a starší po PHP2Shell kritické a jak naplánovat přechod na verzi 8.2 a novější.

Zdroj: https://phpsos.de/cs/ratgeber/php-end-of-life-risiken/  
Stav: 25.10.2026  
Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**Stručně:** Konec podpory PHP znamená: projekt PHP pro tuto větev už nevydává bezpečnostní aktualizace. PHP2Shell následky jasně ukazuje, protože pro PHP 8.1 a starší neexistuje žádná oficiální oprava a PHP 8.2 končí 31. 12. 2026. Kdo dnes běží na staré větvi, měl by přechod plánovat už nyní, a ne až při příští nouzi.

## Co znamená konec podpory PHP

Každá větev PHP, například 8.2 nebo 8.3, je projektem PHP udržována jen po omezenou dobu. Nejdřív vycházejí opravy chyb a bezpečnostní aktualizace, později už jen bezpečnostní aktualizace. Poté podpora končí úplně. Aktuální období zveřejňuje php.net na stránce o podporovaných verzích.

Po skončení podpory software sice dál běží. Pokud se ale objeví nová zranitelnost, projekt PHP už záplatu nevydá. Server zůstává zranitelný, dokud nezasáhne někdo jiný nebo dokud nepřejdete na podporovanou větev.

Pro vedení a IT management je to především otázka plánování. Přechod lze v klidu připravit. Pod časovým tlakem po kritickém hlášení je drahý a riskantní.

## Co PHP2Shell ukazuje o zastaralých verzích

Dne 21. 10. 2026 vydal projekt PHP záplaty pro dvě kritické zranitelnosti, CVE-2026-109618 a CVE-2026-109619. Obě umožňují spuštění škodlivého kódu na dálku bez přihlášení a jsou hodnoceny CVSS v4.0 9.2. Podle odborného tisku jsou postiženy téměř všechny verze zpětně až po PHP 5.4.

| Větev | Stav podle projektu PHP | Oprava PHP2Shell |
|---|---|---|
| PHP 8.5 | podporována | 8.5.12 |
| PHP 8.4 | podporována | 8.4.27 |
| PHP 8.3 | podporována | 8.3.36 |
| PHP 8.2 | podporována do 31. 12. 2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | žádné oficiální aktualizace | jen minimální zdrojové backporty |
| PHP 7.3 a starší | žádné oficiální aktualizace | žádný backport od projektu PHP |

Pro 8.1 a starší tak zbývá jen cesta přes backporty distribucí nebo poskytovatelů hostingu. Ti často dál zobrazují staré číslo verze, přestože jsou záplatovaní. Zda je backport nasazen, může závazně potvrdit jen poskytovatel. Podrobnosti najdete na stránce [PHP 8.1 a starší: co nyní platí](https://phpsos.de/cs/php2shell/php-8-1-und-aelter/), úplný přehled v článku [Které verze PHP jsou postiženy?](https://phpsos.de/cs/php2shell/betroffene-php-versionen/).

> **Důležité:**
> PHP 8.2 ještě opravu PHP2Shell dostalo, ale 31. 12. 2026 dosáhne konce podpory. Kdo nyní přechází z 8.1, měl by rovnou zamířit na novější větev.

## Rizika zastaralých verzí PHP v přehledu

Bezpečnostní riziko je v popředí, ale není jediné. Zastaralé verze PHP s sebou nesou další problémy:

- **Žádné záplaty pro nové zranitelnosti:** Každá budoucí slabina zůstává otevřená nebo závisí na backportech třetích stran.
- **Zastaralé knihovny:** Aktuální balíčky vyžadují novější větve PHP. Bezpečnostní opravy v knihovnách pak nelze nasadit, jak ukazuje příručka [composer audit](https://phpsos.de/cs/ratgeber/composer-abhaengigkeiten-pruefen/).
- **Závislost na poskytovateli:** Poskytovatelé hostingu si za staré verze někdy účtují příplatky nebo provoz ukončí. Lhůtu pak určuje poskytovatel, nikoli vy.
- **Problémy s doložením:** Vůči pojišťovnám, zadavatelům nebo při auditech lze nepodporovanou verzi těžko obhájit. Zda z toho vyplynou smluvní nebo právní následky, ujasněte s pojišťovnou nebo právníkem.
- **Rostoucí náročnost migrace:** Čím větší odstup od aktuální verze, tím více kódu je nutné upravit.

Nejčastěji jsou postiženy starší systémy e-shopů a dlouho nedotčené individuální vývoje. Typickým příkladem je [Shopware 5](https://phpsos.de/cs/plattformen/shopware-5/), který často stále běží na starších větvích PHP.

## Inventura: které verze PHP u vás běží?

Prvním krokem je úplný obraz. Na mnoha serverech běží paralelně několik verzí PHP, například pro starý web, na který už nikdo nemyslí. Tyto příkazy jen čtou:

```bash
# Verze příkazové řádky
php -v
# Nainstalované verze v Debianu/Ubuntu
ls /etc/php/
# Nainstalované verze v Plesku
ls /opt/plesk/php/ 2>/dev/null
# Běžící procesy PHP s verzí v názvu
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
```

Pro každý web si poznamenejte: doménu, verzi PHP, provozní režim, CMS s verzí, odpovědnou osobu. Tento seznam je zároveň základem vašeho nouzového plánu. Na sdíleném hostingu najdete verze většinou v zákaznickém menu poskytovatele.

## Plánování migrace: jak postupovat

Migrace na podporovanou větev se zpravidla řídí stejnými kroky bez ohledu na systém:

1. **Stanovit cíl:** zvolit větev, která je podle php.net podporována co nejdéle a podle systémových požadavků výrobce vyhovuje vašemu CMS.
2. **Ověřit kompatibilitu:** CMS, rozšíření, šablony a vlastní kód. Údaje uvádí oficiální stránka příslušného výrobce.
3. **Zřídit staging:** kopie webu s novou verzí PHP, včetně databáze.
4. **Testovat:** všechny důležité procesy, od kontaktního formuláře po objednávkový proces, a chybový log na varování.
5. **Přepnout a restartovat:** změnit verzi, restartovat všechny procesy PHP, zkontrolovat funkci a chybový log.

Plánujte realisticky. Malý web s aktuálním CMS bývá přepnut rychle. E-shop, který roky rostl, s mnoha rozšířeními a vlastním kódem může naopak vyžadovat úpravy kódu a rozšíření, až po přechod na novou hlavní verzi systému e-shopu. Včas si ujasněte, kdo uvnitř rozhoduje, jaký rozpočet je k dispozici a zda je nutné zapojit externí vývojáře.

Určete také, jak budete konce podpory sledovat v budoucnu. Pevný termín v roce, kdy seznam svých webů porovnáte s údaji na php.net, zabrání tomu, aby stejné úzké místo vzniklo znovu za dva roky.

Do přechodu byste měli využít přechodná opatření php.net, například `session.upload_progress.enabled=0` v konfiguraci serveru. Nejsou úplnou ochranou, ale snižují riziko.

## Jak konkrétně pomáhá PHP SOS?

- Zjistíme všechny verze PHP, provozní režimy a aplikace na vašich serverech.
- Vyhodnotíme riziko pro každý web a společně s vámi stanovíme pořadí a cílovou verzi.
- Do migrace nasadíme přechodná opatření a u poskytovatele vyžádáme potvrzení backportů.
- Migrujeme přes stagingové prostředí a testování i přechod zdokumentujeme.

Průběh popisuje služba [PHP 8.1 a starší: migrace na podporovanou verzi](https://phpsos.de/cs/leistungen/php-migration-legacy/).


## Časté dotazy

**Kdy končí podpora PHP 8.2?**  
PHP 8.2 dosáhne 31. 12. 2026 konce podpory ze strany projektu PHP. Opravu PHP2Shell tato větev ještě dostala ve verzi 8.2.35, pro pozdější zranitelnosti už se oficiální aktualizace očekávat nedá.

**Dostane PHP 8.1 záplatu proti PHP2Shell?**  
Od projektu PHP už pro 8.1 a starší oficiální aktualizace neexistují. Jsou jen minimální zdrojové backporty pro 7.4, 8.0 a 8.1. Zda a jak je váš poskytovatel hostingu nebo distribuce nasazuje, musíte zjistit u poskytovatele.

**Je stará verze PHP s backporty poskytovatele hostingu bezpečná?**  
Backporty mohou uzavřít konkrétní zranitelnosti, ale nenahrazují podporovanou větev. Závisejí na poskytovateli, často přicházejí později a nepokrývají každou zranitelnost. Jako trvalé řešení se proto nehodí.

**Jak zjistím, zda moje CMS běží s novou verzí PHP?**  
Ověřte systémové požadavky na oficiální stránce výrobce a otestujte ve stagingovém prostředí. Pro rozšíření a šablony platí totéž, protože právě ony jsou často skutečným úzkým místem.

## Zdroje

- [php.net: podporované verze](https://www.php.net/supported-versions.php)
- [php.net: bezpečnostní oznámení](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
