Trenutno stanje: PHP2Shell. Dve kritični ranljivosti PHP (CVSS 9,2) omogočata izvedbo škodljive kode brez prijave. Popravki od 21. 10. 2026.Kaj je zdaj treba storiti →

cPanel in WHM: zaščita PHP

cPanel upravlja PHP prek EasyApache 4 z lastnimi paketi za vsako različico. Tako preverite stanje, znova zaženete vse procese in pravilno nastavite vmesne vrednosti.

Stanje 5 min branjaStrežniki in gostovanje

Na kratko: Posodobitev PHP v cPanelu po PHP2Shell obsega tri korake: vse pakete ea-php in po potrebi alt-php dvigniti na odpravljeno stanje, popolnoma znova zagnati PHP-FPM in Apache ter dokumentirati stanje paketov. Stranke na strežniku najpomembnejših vmesnih vrednosti ne morejo nastaviti same, to mora storiti skrbnik WHM.

Izhodišče na strežnikih cPanel

PHP2Shell obsega ranljivosti CVE-2026-109618 in CVE-2026-109619 v samem PHP. Obe omogočata izvajanje škodljive kode brez prijave in imata po CVSS v4.0 oceno 9,2. Prizadeti so PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP in LiteSpeed. Projekt PHP je 21. 10. 2026 objavil različice 8.5.12, 8.4.27, 8.3.36 in 8.2.35.

cPanel PHP ne dostavlja kot en sam paket, temveč prek EasyApache 4 z enim naborom paketov za vsako različico, na primer ea-php83 ali ea-php84. Na nekaterih strežnikih se pridružijo še paketi operacijskega sistema, na CloudLinuxu pa različice alt-php. Vsak vir ima svoje stanje. Popolno sliko dobite šele, ko preverite vse tri.

Posodobitev PHP v cPanelu: preverite zalogo in dodelitve

Začnite s popisom. Spodnji ukazi samo berejo in ničesar ne spreminjajo. Poti in imena paketov so primeri in se lahko glede na namestitev razlikujejo.

# Nameščene različice PHP po API-ju WHM
whmapi1 php_get_installed_versions

# Različica vsake namestitve ea-php
for p in /opt/cpanel/ea-php*/root/usr/bin/php; do echo "$p"; "$p" -v | head -1; done

# Stanje paketov (sistemi na osnovi RPM, primer)
rpm -qa | grep -E '^ea-php[0-9]+-php-(cli|fpm|common)' | sort

V MultiPHP Manager vidite, katera domena uporablja katero različico in ali je PHP-FPM omogočen. Zapišite različice, ki so nameščene, a niso dodeljene nobeni domeni. Tudi te je treba posodobiti ali odstraniti.

Pravilno ovrednotite backporte

Kot pri drugih ponudnikih velja: prikazana številka različice ni edino merilo. Če se popravek dostavi kot backport, lahko številka ostane nespremenjena. Zato dodatno preverite dnevnik sprememb paketa in napotke ponudnika.

# V dnevniku sprememb paketa poiščite številke CVE (primer)
rpm -q --changelog ea-php84-php-cli | grep -iE 'CVE-2026-1096(18|19)'

Če ni nobenega zapisa, to samodejno ne pomeni, da popravka ni. Pomeni pa, da potrebujete pisno potrditev, preden strežnik označite kot popravljen. Kako pravilno brati različice, opisuje stran Preverjanje različice PHP in stanja popravkov.

Posodobitev, ponovni zagon in kontrola

Posodobitev namestite v WHM prek sistemske posodobitve ali upravitelja paketov. Nato znova zaženite vse procese PHP. Same nove datoteke ne zadoščajo, dokler v pomnilniku tečejo stari procesi.

# Znova zaženite storitve PHP-FPM vseh različic (skripta cPanel)
/scripts/restartsrv_apache_php_fpm

# Popolnoma znova zaženite Apache
/scripts/restartsrv_httpd

# Preverite čas zagona procesov PHP
ps -eo pid,lstart,cmd | grep -E 'php-fpm|lsphp|php-cgi' | grep -v grep

Vsak proces PHP bi moral imeti čas zagona po posodobitvi. Če ga nima, ga ciljno ustavite prek pripadajoče storitve. Pri več strežnikih se splača za vsak računalnik pripraviti kratek zapisnik, ki ga pozneje uporabite kot dokaz.

Pomembno

Posodobitev CMS z orodji cPanel, kot je WP Toolkit, ranljivosti PHP ne zapre. Je smiselna, vendar ne nadomesti ne posodobitve PHP ne ponovnega zagona.

Osrednje nastavite vmesne vrednosti

Če neka različica še ni odpravljena, php.net priporoča vmesne ukrepe, ki ne nudijo popolne zaščite. V cPanelu jih nastavite v MultiPHP INI Editor v načinu za skrbnike ali neposredno v php.ini posamezne različice ea-php. Vrednosti v .user.ini strankinih računov za session.upload_progress.enabled ne zadoščajo.

; strežniška php.ini prizadete različice (primer)
session.upload_progress.enabled = 0
post_max_size = 32M
upload_max_filesize = 24M

Brez funkcije nalaganja datotek php.net navaja post_max_size = 8M. Pri PHP 8.5 se doda fatal_error_backtraces=0. Nato znova zaženite vse delavce. Omejitev pomnilnika nastavite prek cgroups, na primer z omejitvami CloudLinux, ne prek RLIMIT_AS ali RLIMIT_DATA. Več podrobnosti je na strani Takojšnji ukrepi brez popravka.

Odgovornost med upravljavcem strežnika in imetniki računov

Na strežniku cPanel z mnogo računi je za PHP, storitve in strežniško konfiguracijo odgovoren skrbnik WHM. Imetniki posameznih računov so odgovorni za svoje aplikacije, vtičnike in dostopne podatke. Imetnikom računov sporočite, kdaj in kako je bil strežnik popravljen, in jim priporočite, naj svoje aplikacije preverijo glede nenavadnosti. Kako je stanje videti z vidika stranke, opisuje stran Shared hosting.

Hranite dnevnike od 20. 10. 2026 naprej. Popravek ne odstrani škodljive programske opreme, ki je bila vnesena prej.

Za dokaz zadošča preprost zapisnik za vsak strežnik: datum in ura posodobitve, seznam paketov ea-php in alt-php z različico pred in po, seznam procesov s časi zagona po ponovnem zagonu in po potrebi potrditev dobavitelja paketov glede backportov. Zapisnik shranite zunaj strežnika. Pozneje služi kot dokaz stranki, zavarovalnici ali revizorjem in olajša naslednjo nujno posodobitev, ker so koraki že opisani. Če upravljate več strežnikov cPanel, se splača ukaze za branje s te strani združiti v majhno skripto, ki se na vseh računalnikih izvede enako in zbere rezultate. Tako odstopanja med strežniki, na primer pozabljeno različico PHP, opazite na prvi pogled.

Kako PHP SOS konkretno pomaga?

  • Popišemo pakete ea-php, alt-php in sistemske pakete ter vse račune povežemo z njihovo različico PHP.
  • Prek naše storitve popravljanja PHP posodobimo, znova zaženemo vse storitve in stanje dokažemo s seznami paketov in časi procesov.
  • Kjer je potrebno, vmesne vrednosti nastavimo strežniško in tako, da jih ni mogoče prepisati.
  • Račune preverimo glede tipičnih sledi kompromitacije in ob najdbi sprožimo odstranjevanje škodljive programske opreme.
  • Nato zmanjšamo število različic PHP in utrdimo konfiguracijo.

Pogosta vprašanja

Kje v WHM vidim, katera domena uporablja katero različico PHP?

V MultiPHP Manager v WHM za vsako domeno vidite dodeljeno različico in ali je PHP-FPM aktiven. Za popoln seznam je smiselna še poizvedba v ukazni vrstici. Zapišite tudi različice, ki niso dodeljene nobeni domeni.

Ali stranka cPanel vmesne vrednosti lahko sama nastavi v .user.ini?

Za session.upload_progress.enabled php.net izrecno navaja, da .user.ini in ini_set() ne zadoščata. Vrednost sodi v php.ini, pool FPM ali konfiguracijo strežnika. To lahko stori samo skrbnik strežnika.

Ali zadošča graceful restart Apacheja?

Pri PHP-FPM je treba znova zagnati same storitve FPM, ponovno nalaganje Apacheja jih ne obnovi. Pri handlerjih PHP, ki temeljijo na Apachu, je varna pot popoln ponovni zagon. Nato preverite čas zagona vseh procesov PHP.

Kaj pa CloudLinux in alt-php?

Na strežnikih CloudLinux spletne strani deloma tečejo z lastnimi paketi alt-php namesto ea-php. Ti imajo svoje stanje paketov in jih je treba preveriti ter posodobiti posebej.

Viri

Takojšnji stik

Vsaka ura šteje. Pišite nam zdaj.

Na kratko opišite sistem, različico PHP in opažanje. Odzovemo se, razjasnimo stanje in delamo na daljavo, dokler incident ni zaključen in dokumentiran.

Takojšnja pomoč