PHP2Shell: dvě kritické chyby PHP a kompletní návod na opravu hostingu, VPS i Dockeru

PHP2Shell je důvod aktualizovat PHP hned, i když se vašeho WordPressu, e-shopu nebo interní aplikace poslední měsíce nikdo nedotkl. Dvě chyby v samotném interpretu mohou za určitých podmínek umožnit vzdálené spuštění kódu bez přihlášení. Aktualizace pluginů ani composer update tento problém neřeší.

Opravy vyšly 21. října 2026. Tento návod zachycuje stav ověřený 23. října 2026. Zabývá se PHP od historických řad 5.4 až po aktuální stabilní řadu 8.5, hostingem, vlastními servery i kontejnery. Přehled verzí berte jako minimální opravené vydání v daném zdroji; pozdější bezpečnostní aktualizace nevynechávejte.

Moje doporučení: nejprve opravte používanou větev a obnovte běžící procesy. Přechod staré aplikace na nové PHP řešte jako navazující práci. Čekat na kompletní přepis aplikace není rozumný způsob, jak nechat veřejný server bez opravy.

Co se pokazilo a co může útočník získat

CVE-2026-109618 se týká zpracování nedostatku paměti: předčasně přerušený požadavek může zanechat neplatná interní data, se kterými PHP následně pracuje při úklidu. CVE-2026-109619 souvisí se stavem ponechaným v procesu po uvolnění paměti předchozího požadavku. Další požadavek může tento stav použít. Obě chyby mají hodnocení CVSS 4.0 9,2. Podrobnosti uvádějí první bezpečnostní advisory PHP a druhé advisory PHP.

Praktický dopad závisí na oprávněních PHP procesu. Útočník může získat přístup k tomu, co smí číst nebo měnit webový uživatel: konfiguraci s heslem databáze, zákaznickým datům, API klíčům, souborům aplikace nebo zapisovatelnému úložišti. Může poškodit provoz a využít dostupné přístupy k dalším systémům. Neznamená to automaticky přístup root; špatně oddělené aplikace a příliš široká oprávnění ale zvětšují následky.

Typický příklad: malý zapomenutý PHP formulář běží pod stejným účtem jako hlavní e-shop. Jeho nízká návštěvnost ani jednoduchost nejsou bezpečnostní hranice. Pokud tento účet vidí konfiguraci e-shopu, problém se netýká jen formuláře.

Koho se to týká: FPM není výjimka

PHP doporučuje aktualizaci všech instalací obsluhujících webové požadavky: Apache s mod_php, PHP-FPM, CGI, FrankenPHP i LiteSpeed. U mod_php je doložen útok před spuštěním aplikačního kódu. U FPM záleží na konkrétní cestě a aplikaci; nelze z toho odvodit, že kombinace Nginx + FPM je bezpečná. Způsob zneužití není pro všechny verze a konfigurace totožný.

Rozsah sahá zpět k PHP 5.4, jak shrnuje také bezpečnostní oznámení Dockeru. Zkontrolujte produkci, staging přístupný z internetu, administrační nástroje, staré subdomény i interní weby. Interní síť snižuje dostupnost útočníkovi, nenahrazuje opravu. Čistě příkazový skript bez webového vstupu nemá automaticky stejnou útočnou plochu; balíčky a dlouho běžící workery přesto zahrňte do inventury.

Které verze obsahují opravu

Pro standardní vydání projektu PHP platí následující minima. Porovnávejte vždy uvnitř konkrétní větve.

Větev PHP	První opravené upstream vydání
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1, 8.0, 7.4	Již mimo upstream podporu; dostupné jsou minimální zdrojové backporty a opravy některých dodavatelů
7.3 až 5.4	Bez nového standardního upstream vydání; rozhoduje konkrétní dodavatel a sestavení

Zdrojem podporovaných vydání jsou oznámení PHP. Pro vlastní sestavení existují větve PHP 7.4, PHP 8.0 a PHP 8.1. Jsou určeny lidem, kteří umějí sestavení, rozšíření a regresní testy udržovat. Neobnovují obecnou podporu těchto větví.

Distribuční balíček může mít nižší číslo PHP a přesto obsahovat opravu. Například Ubuntu 24.04 opravuje PHP v balíčku 8.3.6-0ubuntu0.24.04.13. Samotné „8.3.6“ proto nestačí k rozhodnutí. Stejně tak samotné „8.0.30“ nepotvrzuje bezpečnost starého PHP.

Webhosting: co udělat bez přístupu root

V administraci zjistěte PHP pro každou doménu, subdoménu a aplikaci. Verze pro web, cron a SSH mohou být různé. Pokud poskytovatel nabízí opravené vydání používané větve, přepněte na něj a otestujte web. Přechod například ze 7.4 na 8.5 nejdřív vyzkoušejte na kopii aplikace.

Podpoře pošlete konkrétní požadavek:

Prosím potvrďte opravu CVE-2026-109618 a CVE-2026-109619 pro PHP, které skutečně obsluhuje naše domény. Potřebuji úplnou verzi balíčku nebo identifikaci vendor buildu, zdroj opravy a potvrzení restartu všech příslušných PHP workerů. Pokud zůstáváme na PHP 8.0 či starší větvi, potvrďte backport obou oprav a dobu další podpory. Ověřte také oddělené PHP pro cron a administrační panel.

Odpověď „máme aktuální WordPress“ nestačí. Ani označení „PHP 8.3“ v nabídce neříká, zda jde o opravené sestavení. Pokud hosting opravu nedokáže doložit, dohodněte přesun na opravený handler nebo jiný hosting. Při nedostupné opravě omezte přístup před PHP, případně web dočasně odstavte. Maintenance plugin uvnitř zranitelného PHP není dostatečná hranice.

Plesk má navíc vlastní PHP pro panel. Jeho advisory uvádí opravy panelu v 18.0.80 Update 11 a 18.0.81 Update 4. Linuxové PHP 7.4.33, 8.0.30 a 8.1.34 má opravené buildy z 21. října se stejným základním číslem verze. Aktualizujte panel i používané handlery. U cPanelu, DirectAdminu či spravovaného LiteSpeedu postupujte přes jejich dodavatele; aktualizace systémového PHP nemusí změnit jejich vlastní binárky.

Vlastní VPS: nejdřív zjistit, co opravdu běží

Nezačínal bych náhodným přidáním repozitáře. Nejprve sepište OS, původ balíčků, webový handler, FPM pooly, kontejnery a aplikace. Na Debianu/Ubuntu pomůže:

cat /etc/os-release
php -v
php --ini
dpkg-query -W -f='${binary:Package} ${Version}\n' 'php*' 'libapache2-mod-php*'
systemctl list-units --all --type=service 'php*fpm*'

php -v popisuje CLI z aktuální cesty. Ověřte také konfiguraci virtualhostu a socket, na který proxy předává požadavky. Web může používat PHP 8.0, zatímco příkaz v SSH vypíše 8.3. V panelu kontrolujte handler konkrétní domény.

Potřebujete-li kontrolu přes HTTP, použijte dočasný diagnostický endpoint přístupný jen správci, který vypíše pouze PHP_VERSION a PHP_SAPI. Po kontrole jej odstraňte. Veřejně vystavené phpinfo() zbytečně odhaluje konfiguraci. Ani údaj přes HTTP sám nepotvrzuje distribuční backport: spojte ho s identifikací balíčku, běžící služby a zdroje opravy.

Před změnou ověřte obnovitelnou zálohu databáze, souborů a konfigurace. Snapshot je užitečný, ale bez konzistence databáze nenahrazuje její zálohu. U více uzlů aktualizujte postupně a vyřazujte je z provozu při výměně workerů.

Ubuntu a Debian: konkrétní opravené balíčky

Následující tabulka platí pro oficiální distribuční balíčky, nikoli pro PPA, Surý, Plesk nebo vlastní kompilaci.

Systém	PHP / minimální opravená verze balíčku	Zdroj
Ubuntu 26.10	`8.5.9-0ubuntu2.1`	USN-8948-1
Ubuntu 26.04 LTS	`8.5.4-0ubuntu1.5`	USN-8948-1
Ubuntu 24.04 LTS	`8.3.6-0ubuntu0.24.04.13`	USN-8948-1
Ubuntu 22.04 LTS	`8.1.2-1ubuntu2.28`	USN-8948-1
Ubuntu 20.04 LTS	`7.4.3-4ubuntu2.29+esm5`	USN-8948-2, Ubuntu Pro
Ubuntu 18.04 LTS	`7.2.24-0ubuntu0.18.04.17+esm14`	USN-8948-2, Ubuntu Pro
Ubuntu 16.04 LTS	`7.0.33-0ubuntu0.16.04.16+esm22`	USN-8948-2, Pro + Legacy Support
Ubuntu 14.04 LTS	`5.5.9+dfsg-1ubuntu4.29+esm18`	USN-8948-2, Pro + Legacy Support
Debian 13 trixie	`8.4.27-1~deb13u1`	Balíček stable-security
Debian 12 bookworm	`8.2.35-1~deb12u1`	DLA-4848-1

Starší Ubuntu potřebuje odpovídající aktivní přístup k rozšířené podpoře. Na takovém serveru ověřte pro status. Přítomnost čísla v tabulce neznamená, že balíček získá každý server obyčejným apt upgrade.

Příklad pro server s PHP 8.3-FPM; názvy přizpůsobte zjištěné větvi. Příkazy spusťte po záloze a kontrole dopadu:

sudo apt update
apt-cache policy php8.3-common php8.3-fpm php8.3-cli
apt-mark showhold
sudo apt-get -s upgrade
sudo apt upgrade
sudo systemctl restart php8.3-fpm
systemctl status php8.3-fpm --no-pager
dpkg-query -W -f='${binary:Package} ${Version}\n' 'php8.3*'

Simulaci skutečně přečtěte. Pokud chybí kandidát s opravou, hledejte neaktivní security repozitář, chybu podpisu, pinning, držený balíček, nepodporované vydání nebo zpožděný build pro architekturu. Neobcházejte ověřování podpisů. Zahrňte všechny instalované větve a rozšíření, ne jen metabalíček php.

U Apache s mod_php restartujte po aktualizaci Apache (sudo systemctl restart apache2). U Nginx + FPM restartujte FPM; restart samotného Nginxu PHP nevymění. Aktualizujte a obnovte také dlouho běžící queue workery, Octane/FrankenPHP a další procesy podle jejich správce služeb. Prosté vymazání OPcache neopraví binárku interpretu.

Balíčky Ondřeje Surého: pomoc i pro PHP 8.0 a starší

Ano, český vývojář Ondřej Surý, dlouholetý správce PHP balíčků v Debianu, připravil backporty i pro staré větve. Výchozí rozcestník je deb.sury.org, balíčky jsou v repozitáři packages.sury.org a pro Ubuntu také v PPA ondrej/php. Řiďte se aktuálním README repozitáře a skutečným původem balíčků na serveru; během změn infrastruktury se mohou lišit přípony verzí.

Stará větev	Revize backportu, kterou kontrolovat
PHP 8.1	`8.1.34-9` + přípona pro vaši distribuci
PHP 8.0	`1:8.0.30-25` + přípona
PHP 7.4	`1:7.4.33-31` + přípona
PHP 7.3	`7.3.33-35` + přípona
PHP 7.2	`7.2.34-66` + přípona
PHP 7.1	`7.1.33-81` + přípona, včetně následného doplnění multipart limitu
PHP 7.0	`7.0.33-93` + přípona, včetně následného doplnění multipart limitu
PHP 5.6	`5.6.40-105` + přípona, včetně následného doplnění multipart limitu

Konkrétní ověřený příklad pro Ubuntu 24.04 v PPA: 1:8.0.30-25+ubuntu24.04.1+deb.sury.org+1. Přímé changelogy pro PHP 8.0, PHP 8.1 a PHP 7.4 uvádějí obě CVE. Část 1: je součástí Debian verze, ne překlep.

Pozor na první tabulky kolující po internetu. U PHP 5.6–7.1 chyběl ve starším backportu multipart limit související s CVE-2023-0662. Správce to potvrdil a 22. října oznámil výše uvedené následné revize v issue #146. Za cílový stav bych proto nepovažoval původní 5.6.40-104, 7.0.33-92 ani 7.1.33-80.

Zveřejněný zdrojový balíček také neznamená, že už existuje každý binární build. Průběžné oznámení správce upozorňuje na odlišné načasování architektur. Rozhoduje to, co apt-cache policy nabízí pro váš OS a CPU, a co je opravdu nainstalováno. U PHP 7.2/7.3 kontrolujte rovněž publikované zdroje 7.2 a 7.3 a jejich changelog.

Nepřenášejte balíček pro Ubuntu 24.04 přímo na 20.04 nebo Debian. Starší OS může potřebovat jiný podporovaný zdroj, například PHP LTS od Freexianu, případně migraci. Ověřte konkrétní smluvně podporovanou kombinaci OS/PHP; dostupný soubor není automaticky příslib bezpečnostní údržby. PHP 5.4 a 5.5 nejsou pokryté uvedenou Surý tabulkou. Bez doloženého vendor fixu je nevystavujte veřejně.

Alpine Linux a Docker: dvě různé aktualizace

Alpine s PHP instalovaným přes apk: například oficiální katalog potvrzuje pro Alpine 3.23, x86_64, php83-fpm balíček 8.3.36-r0. Nejde o důkaz dostupnosti pro všechny větve Alpine a architektury. Zkontrolujte vlastní repozitáře a všechny související balíčky.

cat /etc/alpine-release
apk info -v | grep '^php'
apk update
apk policy php83 php83-common php83-fpm
apk upgrade --simulate
apk upgrade

Příklad předpokládá administrátorský shell a PHP 8.3 z apk. Potom obnovte FPM/Apache správným správcem procesů. Na hostiteli s OpenRC nejprve zjistěte jméno služby přes rc-status; v kontejneru typicky nasazujte nový image. Nemíchejte stable a edge repozitáře jen proto, abyste získali jedno nové PHP.

Oficiální image php:…-alpine je jiný případ. PHP je v něm sestavené samostatně, typicky pod /usr/local, a samotné apk upgrade tuto binárku neopraví. Podobně apt upgrade uvnitř oficiálního Debianového PHP image nemusí změnit PHP. Ověřte původ image a jeho Dockerfile; oficiální zdroje Docker PHP ukazují způsob sestavení.

Docker oznámil opravené oficiální a Hardened Images 22. října. Připnutý starý tag nebo digest se sám neopraví. U vlastní aplikace změňte základ na opravené vydání odpovídající větve a varianty, znovu sestavte rozšíření, spusťte testy a nasaďte nový image.

Pro službu pojmenovanou php ve vašem Compose projektu:

# Pokud používáte hotový image: po opravě tagu/digestu v konfiguraci
docker compose pull php
docker compose up -d --no-deps php

# Pokud image sestavujete sami: po opravě FROM v Dockerfile
docker compose build --pull --no-cache php
docker compose up -d --no-deps php

# Kontrola procesu a CLI v novém kontejneru
docker compose ps php
docker compose exec php php -v

Vyberte jednu odpovídající cestu, ne obě naslepo. Služba může mít jiné jméno. Ověřte také webový požadavek a identitu nasazeného image; CLI uvnitř kontejneru není jediný důkaz. Pouhý docker restart starého kontejneru nechá starou binárku. V Kubernetes změňte image/digest a dokončete rollout všech replik; samotný restart Podů se starým digestem nepomůže. U hotového Nextcloudu, WordPressu nebo jiného aplikačního image potřebujete opravený image jeho dodavatele, ne jen nový PHP image vedle něj.

Alpine ani musl nejsou ochrana proti chybě v PHP. A nový kontejner na nepodporovaném hostiteli neopravuje hostitelský kernel.

RHEL, Rocky, AlmaLinux, Remi a problém CentOS 7

Na podporované distribuci nejprve určete původ balíčků a aktivní stream. Systémové PHP, Remi, Software Collections a PHP z panelu jsou odlišné instalace.

cat /etc/os-release
rpm -qa 'php*' | sort
dnf repolist
sudo dnf upgrade --refresh --assumeno

Po kontrole transakce proveďte sudo dnf upgrade --refresh a restartujte skutečně používané služby. Pro systémové FPM to bývá php-fpm, pro Apache httpd; Software Collections mají vlastní názvy. Ověřte všechny aktivní instalace. U vendor backportu porovnávejte plnou RPM verzi s advisory dodavatele, nikoli jen s upstream tabulkou.

Remi 22. října zveřejnil PHP 8.2.35, 8.3.36, 8.4.27 a 8.5.12 pro Enterprise Linux 8+ a Fedora 43+, také jako Software Collections. Starší informace z dne vydání PHP, že Remi ještě opravu nemá, už proto není aktuální. Tohle oznámení ale nepokrývá CentOS 7 ani automaticky všechny EOL větve PHP.

CentOS Linux 7 skončil s aktualizacemi 30. června 2024. Projekt CentOS to výslovně uvádí. Přesměrování repozitářů na Vault zpřístupní archiv, ne nové bezpečnostní opravy. Na takovém serveru nelze slibovat, že yum update problém vyřeší. U ještě starších serverů je situace přinejmenším stejně problematická.

Pro legacy server bych zvolil tento postup:

Omezit přístup k PHP na proxy/firewallu nebo aplikaci dočasně odstavit.
Zjistit, zda váš konkrétní dodavatel poskytuje ověřený backport pro přesný OS, PHP a architekturu. Vyžádat si pokrytí obou CVE a identifikaci sestavení.
Připravit novou podporovanou VPS, přenést kopii aplikace a databáze, otestovat potřebná rozšíření a oprávnění. Podle kompatibility nasadit podporované PHP, nebo dočasně udržovaný legacy runtime s jasným termínem ukončení.
Přepnout provoz a starý server vyřadit. Oprava samotného PHP neřeší neudržovaný OpenSSL, webserver a kernel.

RHEL 7 s odpovídajícím placeným rozšířením podpory není totéž co CentOS 7. Neinstalujte RPM pro EL8/EL9 přímo do EL7. U aplikací závislých na starém ionCube či proprietárním rozšíření ověřte podporu u jejich autora; změna PHP může vyžadovat novou verzi aplikace nebo loaderu.

Cloudflare proxy a WAF: ochranná vrstva před opravou

Cloudflare pomáhá jen u provozu, který přes něj skutečně prochází. Changelog Free Rulesetu z 22. října uvádí sedm blokovacích pravidel pro obě CVE. Šlo o upřesnění názvů a metadat existujících pravidel, nikoliv novou detekční logiku. Obdobná změna je v Managed Rulesetu. Zkontrolujte jejich účinnost ve své zóně a případné výjimky Skip. WAF není oprava PHP ani záruka zachycení každé varianty útoku.

Praktický postup pro běžný web:

Sepište všechny webové domény a subdomény na serveru: hlavní doménu, www, API, administraci, staging i staré aliasy v jiných DNS zónách. U záznamů A, AAAA a CNAME používaných pro web zapněte Proxied, tedy oranžový obláček. Po přesunu DNS ověřte aktivaci zóny a zachování poštovních záznamů. Viz proxy status.
Nastavte SSL/TLS Full (strict) a platný certifikát na originu. Tento režim ověřuje i spojení Cloudflare–server; sám o sobě ale přímý přístup nezakazuje. Nastavení Full (strict).
Uzavřete cestu mimo proxy. Na webových portech originu povolte jen potřebný provoz z aktuálních rozsahů Cloudflare, pro IPv4 i IPv6. Zvlášť vyřešte správu přes SSH, monitoring a obnovu certifikátů, abyste se neodřízli. Alternativou je Tunnel s odchozím připojením a bez veřejně otevřeného vstupu k aplikaci. Ochrana originu.
Otestujte web, formuláře, uploady a integrace. Z jiné sítě ověřte také přístup přímo na IP se správným hostname/SNI: nesmí jít obejít ochranu a spustit PHP. Chyba certifikátu nebo odpověď výchozího virtuálního hostu sama o sobě takový test nenahrazuje.

Za proxy musí být všechny veřejné webové cesty k chráněnému serveru, nebo musí být zablokované. Jeden zapomenutý DNS-only web, IPv6 adresa či alternativní port může omezení obejít. Neznamená to zapnout obláček u pošty: MX a TXT se takto neproxují a běžná webová proxy nepokrývá SMTP ani SSH. Pošta na stejné IP navíc adresu serveru prozradí. Utajení IP proto nenahrazuje firewall. Viz odhalená IP originu. Na sdíleném hostingu musí omezení originu vyřešit poskytovatel.

Interní systém nemusí zhasnout: Access, Google účet nebo VPN

Pokud systém potřebují jen zaměstnanci, dočasně bych raději zavřel veřejný vstup než vypínal celý server. Například veřejný portál může zobrazovat statickou odstávku a interní administrace dál fungovat za SSO. Odstávku musí vracet proxy nebo webserver před předáním požadavku PHP. Vlastní PHP stránka „probíhá údržba“ ani běžný login aplikace tento problém neřeší.

Cloudflare Access umí před web postavit přihlášení bez VPN klienta. Pro firemní účty použijte Google Workspace integraci, která umožňuje i skupiny; pro konkrétní jednotlivce existuje běžné Google přihlášení. Přihlásit se Google účtem a mít povolený přístup jsou dvě různé věci.

Postup pro interní administraci:

V Zero Trust → Integrations → Identity providers připojte vybraného poskytovatele podle jeho návodu. U Google nastavíte OAuth klienta a přesměrování pro svou Access organizaci.
V Access controls → Applications vytvořte Self-hosted aplikaci pro interní hostname. Povolte pravidlem Allow jen konkrétní zaměstnance nebo firemní skupinu. Nepoužívejte Everyone ani plošný Bypass. Nastavte rozumnou délku relace a vícefaktorové přihlášení. U Google vynucujte MFA v organizaci, případně použijte nezávislé MFA Access; nepředpokládejte, že Google integrace podporuje stejné předávání MFA atributů jako každý jiný IdP. MFA v Access.
Preferujte ochranu celého interního hostname. Samotné /admin může zapomenout na přihlašovací endpoint, upload nebo API administrace. Veřejné části samostatně odstavte před PHP; ponechání veřejného zranitelného endpointu na stejném serveru může ohrozit i chráněný admin.
Zajistěte kontrolu Access tokenu na originu. U Tunnel lze zapnout Protect with Access, případně token ověřuje origin. Samotný Tunnel nezapíná SSO a pouhé povolení IP Cloudflare nedokazuje průchod vaší Access politikou. Oficiální postup pro self-hosted aplikaci.
Ověřte anonymní návštěvu, nepovolený Google účet, oprávněného zaměstnance i přímý origin. První dvě nesmějí dostat odpověď aplikace, zaměstnanec musí zvládnout skutečnou práci.

Automatizace n8n, monitoring nebo API se interaktivně nepřihlásí. Kde to klient podporuje, použijte úzce omezenou politiku Service Auth a Access service token, uložený jako tajemství s expirací. Veřejný webhook bez potřebné autentizace raději dočasně pozastavte, než mu dát plošný Bypass.

Alternativou je firemní VPN: aplikaci zpřístupnit jen z privátní sítě/VPN, omezit síťová oprávnění a zrušit veřejnou cestu. VPN není další přihlašovací stránka na veřejném PHP. Obě varianty zmenšují okruh lidí, kteří zranitelný runtime mohou oslovit; kompromitovaný povolený účet nebo zařízení stále představuje riziko. Patch a restart všech PHP workerů zůstávají nutné.

Když dnes opravu nemohu nasadit

Bezpečná náhrada patche v konfiguraci neexistuje. Nejspolehlivější dočasné snížení expozice je omezení vstupu před PHP: VPN, IP allowlist na proxy nebo statická odstávková stránka. Zkontrolujte i přímý přístup na origin, který může obcházet CDN.

Oficiální doporučení popisují dílčí opatření: administrativně vypnout session.upload_progress.enabled, v PHP 8.5 také fatal_error_backtraces, a restartovat workery. Neřeší všechny cesty; nastavení až uvnitř aplikace může přijít pozdě. Viz advisory k životnímu cyklu požadavku.

U OOM chyby se objevuje rada memory_limit=-1. Nekopíroval bych ji bez rozmyslu na sdílený hosting nebo malou VPS. Ruší ochranu před spotřebou paměti a neodstraňuje všechny chyby alokace. Vyžaduje promyšlené limity na proxy a izolaci prostředků; limity RLIMIT_AS/RLIMIT_DATA nejsou ekvivalentní řešení. Podrobnosti a omezení vysvětluje OOM advisory.

WAF, skrytá verze PHP, vypnuté zobrazování chyb nebo zakázané exec() nejsou důkaz odstranění chyby paměti. Dočasné opatření evidujte s vlastníkem a termínem instalace patche.

Jak poznat, že je práce dokončená

Za hotové nepovažuji „aktualizace doběhla“, ale následující stav:

U každé domény znáte skutečný runtime a celý opravený balíček nebo image digest.
Oprava pochází ze zdroje pro danou distribuci a pokrývá obě CVE; u starých Surý větví jste ověřili i následné revize.
Všechny FPM pooly, Apache procesy, kontejnery a dlouho běžící PHP služby už běží s opraveným interpretem; nezůstala stará replika.
Funguje přihlášení, formulář, upload, objednávka/platba, odeslání e-mailu, cron a fronta podle toho, co aplikace používá.
Kontrolujete chybovost a logy po nasazení a odstranili jste diagnostické endpointy.
Staré PHP a nepodporovaný OS mají konkrétní plán migrace.

Do testů zahrňte také XML importy a práci s rozšířeními. Pro PHP 8.4.27/8.5.12 existuje hlášení regrese SimpleXML; ověřte aktuální řešení u dodavatele a dopad na vlastní aplikaci. Návrat na zranitelný veřejně dostupný runtime není dobrý výchozí rollback. Při potížích raději omezte provoz a nasaďte opravené kompatibilní sestavení.

Pokud máte podezření, že byl server už napaden, samotný patch nestačí. Izolujte ho, uchovejte logy a potřebné podklady, prověřte změněné soubory, účty a naplánované úlohy. Obnovujte z důvěryhodného základu; přístupové údaje a tokeny rotujte z čistého prostředí. Absence podezřelých záznamů v logu není důkaz, že k útoku nedošlo.

Největší provozní chyba by byla opravit jednu viditelnou instalaci a zapomenout na další tři. Udělejte si jednoduchý seznam doména → server/kontejner → PHP handler → balíček a zdroj → restart → ověření. Ten vám dnes pomůže uzavřít PHP2Shell a příště zkrátí hledání, kde vám vlastně PHP běží.