PHP2Shell: dve kritické chyby PHP a kompletný návod na opravu hostingu, VPS aj Dockeru

PHP2Shell je dôvod aktualizovať PHP hneď, aj keď sa vášho WordPressu, e-shopu alebo internej aplikácie posledné mesiace nikto nedotkol. Dve chyby v samotnom interpreteri môžu za určitých podmienok umožniť vzdialené spustenie kódu bez prihlásenia. Aktualizácia pluginov ani composer update tento problém nevyriešia.

Opravy vyšli 21. októbra 2026. Tento návod zachytáva stav overený 23. októbra 2026. Pokrýva PHP od historických radov 5.4 po aktuálny stabilný rad 8.5, hosting, vlastné servery aj kontajnery. Uvedené verzie sú minimálne opravené vydania v danom zdroji; nasledujúce bezpečnostné aktualizácie nevynechávajte.

Moje odporúčanie: najskôr opravte používanú vetvu a obnovte bežiace procesy. Prechod starej aplikácie na nové PHP riešte ako nadväzujúcu úlohu. Čakať na kompletný prepis aplikácie nie je rozumný dôvod nechať verejný server bez opravy.

Čo sa pokazilo a čo môže útočník získať

CVE-2026-109618 sa týka spracovania nedostatku pamäte: predčasne prerušená požiadavka môže zanechať neplatné interné dáta, s ktorými PHP následne pracuje pri upratovaní. CVE-2026-109619 súvisí so stavom ponechaným v procese po uvoľnení pamäte predchádzajúcej požiadavky. Ďalšia požiadavka môže tento stav použiť. Obe chyby majú hodnotenie CVSS 4.0 9,2. Podrobnosti uvádza prvé bezpečnostné advisory PHP a druhé advisory PHP.

Praktický dosah závisí od oprávnení PHP procesu. Útočník môže získať prístup k tomu, čo smie čítať alebo meniť webový používateľ: ku konfigurácii s heslom databázy, zákazníckym dátam, API kľúčom, súborom aplikácie či zapisovateľnému úložisku. Môže narušiť prevádzku a využiť dostupné prihlasovacie údaje na prístup k ďalším systémom. Neznamená to automaticky prístup root; slabé oddelenie aplikácií a príliš široké oprávnenia však zväčšujú následky.

Typický príklad: malý zabudnutý PHP formulár beží pod rovnakým účtom ako hlavný e-shop. Nízka návštevnosť ani jednoduchosť nie sú bezpečnostnou hranicou. Ak tento účet vidí konfiguráciu e-shopu, problém sa netýka iba formulára.

Koho sa to týka: FPM nie je výnimka

PHP odporúča aktualizovať všetky inštalácie obsluhujúce webové požiadavky: Apache s mod_php, PHP-FPM, CGI, FrankenPHP aj LiteSpeed. Pri mod_php je doložený útok pred spustením aplikačného kódu. Pri FPM záleží na konkrétnej ceste a aplikácii; kombináciu Nginx + FPM preto nemožno automaticky považovať za bezpečnú. Podmienky zneužitia nie sú rovnaké pre všetky verzie a konfigurácie.

Rozsah siaha späť k PHP 5.4, ako uvádza aj bezpečnostné oznámenie Dockeru. Skontrolujte produkciu, staging dostupný z internetu, administračné nástroje, staré subdomény aj interné weby. Interná sieť obmedzuje dostupnosť pre útočníka, nenahrádza opravu. Čisto príkazový skript bez webového vstupu nemá automaticky rovnakú útočnú plochu; balíčky a dlho bežiace workery napriek tomu zahrňte do inventúry.

Ktoré verzie obsahujú opravu

Pre štandardné vydania projektu PHP platia nasledujúce minimá. Verzie porovnávajte v rámci príslušnej vetvy.

Vetva PHP	Prvé opravené upstream vydanie
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	Mimo upstream podpory; existujú minimálne zdrojové backporty a opravy niektorých dodávateľov
7.3 až 5.4	Bez nového štandardného upstream vydania; rozhoduje konkrétny dodávateľ a zostavenie

Zdrojom sú oznámenia PHP. Pre vlastné zostavenia sú dostupné vetvy PHP 7.4, PHP 8.0 a PHP 8.1. Sú určené ľuďom, ktorí vedia udržiavať zostavenia, rozšírenia a regresné testy. Neobnovujú všeobecnú podporu týchto vetiev.

Distribučný balíček môže mať nižšie číslo PHP a pritom obsahovať opravu. Ubuntu 24.04 napríklad opravuje PHP v balíčku 8.3.6-0ubuntu0.24.04.13. Samotné „8.3.6“ teda na rozhodnutie nestačí. Rovnako ani „8.0.30“ nepotvrdzuje bezpečnosť starého PHP.

Webhosting: čo urobiť bez prístupu root

V administrácii zistite PHP pre každú doménu, subdoménu a aplikáciu. Web, cron a SSH môžu používať rôzne inštalácie. Ak poskytovateľ ponúka opravené vydanie vašej vetvy, prepnite naň a otestujte web. Prechod napríklad zo 7.4 na 8.5 najskôr vyskúšajte na kópii aplikácie.

Podpore pošlite konkrétnu požiadavku:

Prosím potvrďte opravu CVE-2026-109618 a CVE-2026-109619 pre PHP, ktoré skutočne obsluhuje naše domény. Potrebujem úplnú verziu balíčka alebo identifikáciu vendor buildu, zdroj opravy a potvrdenie reštartu všetkých príslušných PHP workerov. Ak zostávame na PHP 8.0 alebo staršej vetve, potvrďte backport oboch opráv a dobu ďalšej podpory. Overte aj samostatné PHP pre cron a administračný panel.

Odpoveď „máme aktuálny WordPress“ nestačí. Ani označenie „PHP 8.3“ v ponuke nehovorí, či ide o opravené zostavenie. Ak hosting opravu nevie doložiť, dohodnite presun na opravený handler alebo iný hosting. Kým oprava nie je dostupná, obmedzte prístup ešte pred PHP alebo web dočasne odstavte. Maintenance plugin spúšťaný zraniteľným PHP nie je dostatočnou hranicou.

Plesk má navyše vlastné PHP pre panel. Jeho advisory uvádza 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. októbra s rovnakým základným číslom verzie. Aktualizujte panel aj používané handlery. Pri cPaneli, DirectAdmine alebo spravovanom LiteSpeede postupujte cez dodávateľa; aktualizácia systémového PHP nemusí zmeniť ich vlastné binárky.

Vlastná VPS: najprv zistiť, čo naozaj beží

Nezačínal by som náhodným pridaním repozitára. Najprv spíšte OS, pôvod balíčkov, webový handler, FPM pooly, kontajnery a aplikácie. Na Debiane alebo 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 opisuje CLI binárku nájdenú v aktuálnej ceste. Skontrolujte aj konfiguráciu virtualhostu a socket, na ktorý proxy posiela požiadavky. Web môže používať PHP 8.0, kým príkaz v SSH vypíše 8.3. V paneli kontrolujte handler konkrétnej domény.

Ak potrebujete kontrolu cez HTTP, použite dočasný diagnostický endpoint prístupný iba správcovi, ktorý vypíše len PHP_VERSION a PHP_SAPI. Potom ho odstráňte. Verejné phpinfo() zbytočne odhaľuje konfiguráciu. Ani údaj cez HTTP sám nepotvrdzuje distribučný backport: spojte ho s identifikáciou balíčka, bežiacej služby a zdroja opravy.

Pred zmenou overte obnoviteľnú zálohu databázy, súborov a konfigurácie. Snapshot je užitočný, ale bez konzistencie databázy nenahrádza jej zálohu. Pri viacerých uzloch aktualizujte postupne a počas výmeny workerov ich vyraďujte z prevádzky.

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

Nasledujúca tabuľka platí pre oficiálne distribučné balíčky, nie pre PPA, Surý, Plesk alebo vlastnú kompiláciu.

Systém	Minimálna opravená verzia PHP balíčka	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šie Ubuntu potrebuje zodpovedajúci aktívny prístup k rozšírenej podpore. Na takom serveri overte pro status. Číslo v tabuľke neznamená, že balíček získa každý server obyčajným apt upgrade.

Príklad pre server s PHP 8.3-FPM; názvy prispôsobte zistenej vetve. Príkazy spúšťajte po zálohe a kontrole dosahu:

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*'

Simuláciu si naozaj prečítajte. Ak chýba kandidát s opravou, hľadajte neaktívny security repozitár, chybu podpisu, pinning, podržaný balíček, nepodporované vydanie alebo oneskorený build pre architektúru. Neobchádzajte overovanie podpisov. Zahrňte všetky nainštalované vetvy a rozšírenia, nielen metabalíček php.

Pri Apache s mod_php po aktualizácii reštartujte Apache (sudo systemctl restart apache2). Pri Nginx + FPM reštartujte FPM; samotný reštart Nginxu PHP nevymení. Aktualizujte a obnovte aj dlho bežiace queue workery, Octane/FrankenPHP a ďalšie procesy podľa ich správcu služieb. Vymazanie OPcache neopraví binárku interpretera.

Balíčky Ondřeja Surého: pomoc aj pre PHP 8.0 a staršie

Áno, český vývojár Ondřej Surý, dlhoročný správca PHP balíčkov v Debiane, pripravil backporty aj pre staré vetvy. Začnite na deb.sury.org, v repozitári packages.sury.org a pre Ubuntu aj v PPA ondrej/php. Riaďte sa aktuálnym README repozitára a skutočným pôvodom balíčkov na serveri; počas zmien infraštruktúry sa prípony verzií môžu líšiť.

Stará vetva	Revízia backportu, ktorú treba kontrolovať
PHP 8.1	`8.1.34-9` + prípona pre vašu distribúciu
PHP 8.0	`1:8.0.30-25` + prípona
PHP 7.4	`1:7.4.33-31` + prípona
PHP 7.3	`7.3.33-35` + prípona
PHP 7.2	`7.2.34-66` + prípona
PHP 7.1	`7.1.33-81` + prípona, vrátane následného doplnenia multipart limitu
PHP 7.0	`7.0.33-93` + prípona, vrátane následného doplnenia multipart limitu
PHP 5.6	`5.6.40-105` + prípona, vrátane následného doplnenia multipart limitu

Konkrétny overený príklad pre Ubuntu 24.04 v PPA: 1:8.0.30-25+ubuntu24.04.1+deb.sury.org+1. Priame changelogy pre PHP 8.0, PHP 8.1 a PHP 7.4 uvádzajú obe CVE. Časť 1: patrí do Debian verzie, nejde o preklep.

Pozor na prvé tabuľky kolujúce po internete. V skorších backportoch pre PHP 5.6–7.1 chýbal multipart limit súvisiaci s CVE-2023-0662. Správca to potvrdil a 22. októbra oznámil vyššie uvedené následné revízie v issue #146. Za cieľový stav by som preto nepovažoval pôvodné 5.6.40-104, 7.0.33-92 ani 7.1.33-80.

Zverejnený zdrojový balíček navyše neznamená, že už existuje každý binárny build. Priebežné oznámenie správcu upozorňuje na rozdielne načasovanie architektúr. Rozhoduje to, čo apt-cache policy ponúka pre váš OS a CPU a čo je skutočne nainštalované. Pri PHP 7.2/7.3 skontrolujte aj publikované zdroje 7.2 a 7.3 a ich changelogy.

Neinštalujte balíček pre Ubuntu 24.04 priamo na 20.04 alebo Debian. Starší OS môže potrebovať iný podporovaný zdroj, napríklad PHP LTS od Freexianu, alebo migráciu. Overte konkrétnu zmluvne podporovanú kombináciu OS/PHP; dostupný súbor nie je automaticky prísľubom bezpečnostnej údržby. PHP 5.4 a 5.5 nie sú pokryté uvedenou Surý tabuľkou. Bez doloženého vendor fixu ich nevystavujte verejne.

Alpine Linux a Docker: dve rôzne aktualizácie

Alpine s PHP nainštalovaným cez apk: oficiálny katalóg napríklad potvrdzuje pre Alpine 3.23, x86_64, php83-fpm balíček 8.3.36-r0. Nie je to dôkaz dostupnosti pre všetky vetvy Alpine a architektúry. Skontrolujte vlastné repozitáre a všetky súvisiace 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

Príklad predpokladá administrátorský shell a PHP 8.3 z apk. Potom obnovte FPM/Apache správnym správcom procesov. Na hostiteľovi s OpenRC najprv zistite názov služby cez rc-status; v kontajneri spravidla nasaďte nový image. Nemiešajte stable a edge repozitáre iba kvôli jednému novému PHP.

Oficiálny image php:…-alpine je iný prípad. PHP je v ňom zostavené samostatne, typicky pod /usr/local, a samotné apk upgrade túto binárku neopraví. Podobne apt upgrade v oficiálnom Debianovom PHP image nemusí vymeniť PHP. Overte pôvod image a jeho Dockerfile; oficiálne zdroje Docker PHP ukazujú spôsob zostavenia.

Docker oznámil opravené Official a Hardened Images 22. októbra. Pripnutý starý tag alebo digest sa sám neopraví. Pri vlastnej aplikácii zmeňte základ na opravené vydanie zodpovedajúcej vetvy a variantu, znova zostavte rozšírenia, spustite testy a nasaďte nový image.

Pre službu s názvom php vo vašom Compose projekte:

# Hotový image: najprv opravte tag/digest v konfigurácii
docker compose pull php
docker compose up -d --no-deps php

# Vlastné zostavenie: najprv opravte FROM v Dockerfile
docker compose build --pull --no-cache php
docker compose up -d --no-deps php

# Kontrola procesu a CLI v novom kontajneri
docker compose ps php
docker compose exec php php -v

Vyberte zodpovedajúcu cestu, nie obe naslepo. Služba môže mať iný názov. Overte aj webovú požiadavku a identitu nasadeného image; CLI kontrola je iba časť dôkazu. Samotný docker restart starého kontajnera ponechá starú binárku. V Kubernetes zmeňte image/digest a dokončite rollout všetkých replík; reštart Podov so starým digestom nestačí. Pri hotovom Nextcloude, WordPresse alebo inom aplikačnom image potrebujete opravený image jeho dodávateľa. Stiahnutie samostatného PHP image vedľa neho nič neopraví.

Alpine ani musl nechránia pred chybou v PHP. Nový kontajner na nepodporovanom hostiteľovi zároveň neopravuje jeho kernel.

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

Na podporovanej distribúcii najprv určite pôvod balíčkov a aktívny stream. Systémové PHP, Remi, Software Collections a PHP z panelu sú samostatné inštalácie.

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

Po kontrole transakcie vykonajte sudo dnf upgrade --refresh a reštartujte skutočne používané služby. Pri systémovom FPM to býva php-fpm, pri Apache httpd; Software Collections majú vlastné názvy. Overte všetky aktívne inštalácie. Pri vendor backporte porovnávajte plnú RPM verziu s advisory dodávateľa, nie iba s upstream tabuľkou.

Remi 22. októbra zverejnil PHP 8.2.35, 8.3.36, 8.4.27 a 8.5.12 pre Enterprise Linux 8+ a Fedora 43+, aj ako Software Collections. Staršie informácie z dňa vydania PHP, že Remi ešte opravu nemá, už nie sú aktuálne. Oznámenie však nepokrýva CentOS 7 ani automaticky všetky EOL vetvy PHP.

CentOS Linux 7 skončil s aktualizáciami 30. júna 2024. Projekt CentOS to výslovne uvádza. Presmerovanie repozitárov na Vault sprístupní archív, nie nové bezpečnostné opravy. Na takom serveri nemožno sľúbiť, že yum update problém vyrieši. Pri ešte starších serveroch je situácia prinajmenšom rovnako problematická.

Pre legacy server by som zvolil tento postup:

Obmedziť prístup k PHP na proxy/firewalle alebo aplikáciu dočasne odstaviť.
Zistiť, či konkrétny dodávateľ poskytuje overený backport pre presný OS, PHP a architektúru. Vyžiadať si pokrytie oboch CVE a identifikáciu zostavenia.
Pripraviť novú podporovanú VPS, preniesť kópiu aplikácie a databázy, otestovať potrebné rozšírenia a oprávnenia. Podľa kompatibility nasadiť podporované PHP alebo dočasne udržiavaný legacy runtime s jasným termínom ukončenia.
Prepnúť prevádzku a starý server vyradiť. Oprava samotného PHP nerieši neudržiavaný OpenSSL, webserver a kernel.

RHEL 7 so zodpovedajúcim plateným rozšírením podpory nie je to isté ako CentOS 7. Neinštalujte RPM pre EL8/EL9 priamo do EL7. Pri aplikáciách závislých od starého ionCube alebo proprietárneho rozšírenia overte podporu u autora; zmena PHP môže vyžadovať novú verziu aplikácie alebo loaderu.

Cloudflare proxy a WAF: ochranná vrstva pred opravou

Cloudflare pomáha len pri prevádzke, ktorá cez neho skutočne prechádza. Changelog Free Rulesetu z 22. októbra uvádza sedem blokovacích pravidiel pre obe CVE. Išlo o spresnenie názvov a metadát existujúcich pravidiel, nie o novú detekčnú logiku. Podobná zmena je v Managed Rulesete. Skontrolujte ich účinné nastavenie vo svojej zóne aj výnimky Skip. WAF neopravuje PHP a nezaručuje zachytenie každého variantu útoku.

Praktický postup pre bežný web:

Spíšte všetky webové domény a subdomény na serveri: hlavnú doménu, www, API, administráciu, staging aj staré aliasy v iných DNS zónach. Pri webových záznamoch A, AAAA a CNAME zapnite Proxied, teda oranžový obláčik. Po presune DNS overte aktiváciu zóny a zachovanie poštových záznamov. Pozrite proxy status.
Nastavte SSL/TLS Full (strict) a platný certifikát na origine. Tento režim overuje aj spojenie Cloudflare–server, sám však priamy prístup nezakazuje. Nastavenie Full (strict).
Uzavrite cestu mimo proxy. Na webových portoch originu povoľte len potrebnú prevádzku z aktuálnych rozsahov Cloudflare, pre IPv4 aj IPv6. Samostatne vyriešte správu cez SSH, monitoring a obnovu certifikátov, aby ste sa neodrezali. Alternatívou je Tunnel s odchádzajúcim pripojením bez verejne otvoreného vstupu k aplikácii. Ochrana originu.
Otestujte web, formuláre, uploady aj integrácie. Z inej siete skúste tiež prístup priamo na IP so správnym hostname/SNI: nesmie obísť ochranu a spustiť PHP. Chyba certifikátu ani odpoveď predvoleného virtuálneho hosta tento test nenahrádzajú.

Cez proxy musia ísť všetky verejné webové cesty k chránenému serveru, alebo musia byť zablokované. Zabudnutý DNS-only web, IPv6 adresa či alternatívny port môžu obmedzenie obísť. Neznamená to zapínať obláčik pri pošte: MX a TXT sa takto neproxujú a bežná webová proxy nepokrýva SMTP ani SSH. Pošta na rovnakej IP navyše prezradí adresu servera. Utajenie IP preto nenahrádza firewall. Pozrite odhalená IP originu. Na zdieľanom hostingu musí obmedzenie originu vyriešiť poskytovateľ.

Interný systém nemusí zhasnúť: Access, Google účet alebo VPN

Ak systém potrebujú len zamestnanci, dočasne by som radšej zavrel verejný vstup než vypínal celý server. Verejný portál môže zobrazovať statickú odstávku a interná administrácia ďalej fungovať za SSO. Odstávku musí vracať proxy alebo webserver pred odovzdaním požiadavky PHP. Vlastná PHP stránka „prebieha údržba“ ani bežný login aplikácie tento problém neriešia.

Cloudflare Access vie pred web postaviť prihlásenie bez VPN klienta. Pre firemné účty použite Google Workspace integráciu, ktorá podporuje aj skupiny; pre konkrétnych jednotlivcov existuje bežné Google prihlásenie. Prihlásiť sa Google účtom a mať povolený prístup sú dve odlišné veci.

Postup pre internú administráciu:

V Zero Trust → Integrations → Identity providers pripojte poskytovateľa podľa jeho návodu. Pri Google nastavíte OAuth klienta a presmerovanie pre svoju Access organizáciu.
V Access controls → Applications vytvorte Self-hosted aplikáciu pre interný hostname. Pravidlom Allow povoľte len konkrétnych zamestnancov alebo firemnú skupinu. Nepoužívajte Everyone ani plošný Bypass. Nastavte primeranú dĺžku relácie a viacfaktorové prihlásenie. Pri Google vynucujte MFA v organizácii, prípadne použite nezávislé MFA Access; nepredpokladajte, že Google integrácia odovzdáva rovnaké MFA atribúty ako každý iný IdP. MFA v Access.
Uprednostnite ochranu celého interného hostname. Samotné /admin môže vynechať prihlasovací endpoint, upload či API administrácie. Verejné časti samostatne odstavte pred PHP; verejný zraniteľný endpoint na tom istom serveri môže ohroziť aj chránený admin.
Zaistite kontrolu Access tokenu na origine. Pri Tunnel možno zapnúť Protect with Access, prípadne token overuje origin. Samotný Tunnel nezapína SSO a povolenie IP Cloudflare nedokazuje prechod vašou Access politikou. Postup pre self-hosted aplikáciu.
Overte anonymnú návštevu, nepovolený Google účet, oprávneného zamestnanca aj priamy origin. Prvé dve nesmú dostať odpoveď aplikácie, zamestnanec musí zvládnuť skutočnú prácu.

Automatizácie n8n, monitoring či API sa interaktívne neprihlásia. Kde to klient podporuje, použite úzko obmedzenú politiku Service Auth a Access service token, uložený ako tajomstvo s expiráciou. Verejný webhook bez potrebnej autentizácie radšej dočasne pozastavte, než mu dať plošný Bypass.

Alternatívou je firemná VPN: aplikáciu sprístupniť len z privátnej siete/VPN, obmedziť sieťové oprávnenia a zrušiť verejnú cestu. VPN nie je ďalšia prihlasovacia stránka na verejnom PHP. Obe možnosti zmenšujú okruh ľudí, ktorí môžu osloviť zraniteľný runtime; kompromitovaný povolený účet alebo zariadenie zostávajú rizikom. Patch a reštart všetkých PHP workerov sú stále nevyhnutné.

Keď dnes opravu nemôžem nasadiť

Bezpečná náhrada patche v konfigurácii neexistuje. Najspoľahlivejšie dočasné zníženie expozície je obmedziť vstup pred PHP: VPN, IP allowlist na proxy alebo statická stránka odstávky. Skontrolujte aj priamy prístup na origin, ktorý môže obchádzať CDN.

Oficiálne odporúčania opisujú čiastkové opatrenia: administratívne vypnúť session.upload_progress.enabled, pri PHP 8.5 tiež fatal_error_backtraces, a reštartovať workery. Nepokrývajú všetky cesty a nastavenie až v aplikácii môže prísť neskoro. Pozrite si advisory k životnému cyklu požiadavky.

Pri OOM chybe sa objavuje rada memory_limit=-1. Nekopíroval by som ju bez rozmyslu na zdieľaný hosting alebo malú VPS. Ruší ochranu pred spotrebou pamäte a neodstraňuje všetky chyby alokácie. Vyžaduje premyslené limity na proxy a izoláciu prostriedkov; RLIMIT_AS/RLIMIT_DATA nie sú rovnocenným riešením. Podrobnosti a obmedzenia vysvetľuje OOM advisory.

WAF, skrytá verzia PHP, vypnuté zobrazovanie chýb či zakázané exec() nie sú dôkazom odstránenia chyby pamäte. Dočasné opatrenie evidujte s vlastníkom a termínom inštalácie patche.

Ako zistiť, že je práca dokončená

Za hotové nepovažujem „aktualizácia dobehla“, ale nasledujúci stav:

Pri každej doméne poznáte skutočný runtime a celý opravený balíček alebo image digest.
Oprava pochádza zo zdroja pre danú distribúciu a pokrýva obe CVE; pri starých Surý vetvách ste overili aj následné revízie.
Všetky FPM pooly, Apache procesy, kontajnery a dlho bežiace PHP služby používajú opravený interpreter; nezostala stará replika.
Fungujú prihlásenie, formulár, upload, objednávka/platba, odosielanie e-mailov, cron a fronta podľa toho, čo aplikácia používa.
Po nasadení kontrolujete chybovosť a logy a odstránili ste diagnostické endpointy.
Staré PHP a nepodporovaný OS majú konkrétny plán migrácie.

Do testov zahrňte aj XML importy a prácu s rozšíreniami. Pre PHP 8.4.27/8.5.12 existuje hlásenie regresie SimpleXML; overte aktuálne riešenie u dodávateľa a dosah na vlastnú aplikáciu. Návrat na zraniteľný verejne dostupný runtime nie je vhodný predvolený rollback. Pri problémoch radšej obmedzte prevádzku a nasaďte opravené kompatibilné zostavenie.

Ak máte podozrenie, že server už bol napadnutý, samotný patch nestačí. Izolujte ho, uchovajte logy a potrebné podklady, preverte zmenené súbory, účty a naplánované úlohy. Obnovujte z dôveryhodného základu; prihlasovacie údaje a tokeny rotujte z čistého prostredia. Absencia podozrivých záznamov v logu nie je dôkazom, že k útoku nedošlo.

Najväčšia prevádzková chyba by bola opraviť jednu viditeľnú inštaláciu a zabudnúť na ďalšie tri. Vytvorte si jednoduchý zoznam doména → server/kontajner → PHP handler → balíček a zdroj → reštart → overenie. Pomôže vám uzavrieť PHP2Shell a nabudúce skráti hľadanie, kde vám vlastne PHP beží.