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 →

Strežnik Plesk: preverjanje različic PHP in popravljanje

Na strežnikih Plesk pogosto vzporedno teče več različic PHP. Tako preverite vsak handler, namestite posodobitev PHP in znova zaženete vse delavce.

Stanje 5 min branjaStrežniki in gostovanje

Na kratko: Posodobitev PHP v Plesku je končana šele, ko je vsaka nameščena različica PHP na odpravljenem stanju, so vse storitve PHP-FPM znova zagnane in lahko to dokažete s stanjem paketov in časom zagona procesov. Številka različice, prikazana v upravljalni plošči, sama ne zadošča, ker jo backporti pogosto pustijo nespremenjeno.

Kaj PHP2Shell pomeni za strežnike Plesk

PHP2Shell označuje dve kritični ranljivosti v samem PHP (CVE-2026-109618 in CVE-2026-109619, vsaka CVSS v4.0 9,2). Napadalcem omogočata izvajanje kode na strežniku brez prijave. Prizadeta sta med drugim PHP-FPM in Apache z mod_php, torej prav načina delovanja, ki ju Plesk nastavi za spletne strani.

    1. 2026 je projekt PHP objavil odpravljene različice 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Za PHP 8.1 in starejše uradnih posodobitev ni več. Strežniki Plesk imajo posebnost: tu pogosto vzporedno teče več različic PHP, deloma od samega Plesk, deloma od operacijskega sistema. Vsako je treba preveriti posebej.
Pomembno

Posodobitev v upravljalni plošči zamenja datoteke na disku. Dokler v pomnilniku tečejo stari procesi PHP, ostane ranljivost odprta. Brez ponovnega zagona vseh delavcev popravek ni učinkovit.

Posodobitev PHP v Plesku: najprej popišite stanje

Preden karkoli posodobite, si pripravite seznam vseh handlerjev PHP in domen, ki jih uporabljajo. To lahko storite v upravljalni plošči (Orodja in nastavitve, Nastavitve PHP) ali v ukazni vrstici. Spodnji ukazi ničesar ne spreminjajo, samo berejo.

# Vsi registrirani handlerji PHP z različico in potjo
plesk bin php_handler --list

# Različica vsake različice PHP, ki jo je namestil Plesk (pot kot primer)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done

Za vsak handler zapišite: različico, način delovanja (FPM, FastCGI, modul Apache) in število domen. Handlerji brez domene niso razlog za olajšanje. Pozneje jih lahko dodelite ali pa tečejo na testnih poddomenah.

Preverite stanje paketov, ne prikaza

Plesk prikazuje številko različice, ki jo sporoča sam PHP. Če Plesk ali distribucija popravek dostavita kot backport, lahko tam še vedno piše na primer 8.2.34, čeprav je popravek vsebovan. Obratno lahko navidez aktualna številka zavaja, če paket še ni bil posodobljen. Odločilna sta nameščeno stanje paketa in pisna potrditev ponudnika.

# Debian/Ubuntu (imena paketov kot primer)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'

# AlmaLinux/Rocky/RHEL (imena paketov kot primer)
rpm -qa | grep -E 'plesk-php|^php' | sort

Različice paketov primerjajte z navedbami v dnevnikih sprememb Plesk in z napotki vaše distribucije. Če tam ni nedvoumno dokumentirano, da sta CVE-2026-109618 in CVE-2026-109619 odpravljena, vprašajte ponudnika. Predlogo za to najdete na strani Vprašajte ponudnika gostovanja za stanje popravkov.

Namestite posodobitev in znova zaženite vse delavce

Sama posodobitev poteka prek namestitvenega programa Plesk ali upravitelja paketov v sistemu. Sledi korak, ki ga najpogosteje zmanjka: ponovni zagon. Vsaka različica PHP ima v Plesku svojo storitev FPM. Znova zaženite vse, ne samo storitve glavne domene.

# Naštejte vse storitve PHP-FPM (imena storitev kot primer)
systemctl list-units --type=service | grep -i 'php.*fpm'

# Znova zaženite vsako storitev, npr.:
systemctl restart plesk-php84-fpm

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

Če domena teče z Apacheem in mod_php, Apache znova zaženite v celoti. Če je čas zagona procesa PHP pred posodobitvijo, še ni bil obnovljen. Več o tem koraku najdete na strani Ponovni zagon PHP-FPM in vseh delavcev.

Vmesna zaščita, dokler posodobitve ni

Če za neko različico popravka še ni, php.net priporoča vmesne ukrepe. Niso popolna zaščita. V Plesku vrednosti, ki jih aplikacije ne smejo prepisati, nastavite kot php_admin_value v dodatnih direktivah FPM domene ali strežniško v datoteki php.ini posamezne različice.

; Primer dodatnih direktiv PHP-FPM v Plesku
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M

Pri nalaganju datotek je po php.net predviden post_max_size = 32M, upload_max_filesize pa pod tem. Pri PHP 8.5 se doda fatal_error_backtraces=0. Omejitev pomnilnika z memory_limit=-1 se sme uporabiti samo skupaj z mejo na ravni vsebnika ali cgroup. Nato spet sledi ponovni zagon vseh delavcev. Podrobnosti so na strani Takojšnji ukrepi brez popravka. BSI priporoča, da spletne strežnike začasno odklopite z omrežja, če posodobitev ni takoj mogoča.

Po popravku: zavarujte dnevnike in preverite sledi

Popravek zapre ranljivost za prihodnost. Ne odstrani škodljive programske opreme, ki je bila vnesena prej, in ne dokazuje, da se ni zgodilo nič. Zato hranite dnevnike spletnega strežnika od 20. 10. 2026 naprej. Plesk jih za vsako domeno shrani v imeniku logs; v tem položaju hrambe ne krajšajte.

Bodite pozorni na nove ali spremenjene datoteke PHP v imenikih za nalaganje, neznana načrtovana opravila in nove administratorske račune. Objavljenih, potrjenih indikatorjev ogroženosti (Indicators of Compromise) zaenkrat ni; zaznavanje temelji na analizi vedenja. Če opazite kaj sumljivega, na lastno pest ne nadaljujte z delom, temveč najprej zavarujte stanje.

Kako PHP SOS konkretno pomaga?

  • Popišemo vse handlerje PHP na vašem strežniku Plesk, jih povežemo z domenami in preverimo dejansko stanje paketov za vsako različico.
  • V okviru naše storitve popravljanja PHP namestimo posodobitve, znova zaženemo vse storitve in čase zagona procesov dokumentiramo kot dokaz.
  • Kjer popravka ni, vmesne ukrepe po php.net nastavimo strežniško in tako, da jih aplikacije ne morejo prepisati.
  • Zavarujemo dnevnike in poiščemo sledi kompromitacije, ob najdbi s Incident Response.
  • Nato strežnik trajno utrdimo in odstranimo nepotrebne različice PHP.

Pogosta vprašanja

Zakaj Plesk po posodobitvi še vedno prikazuje PHP 8.2.34?

Distribucije in ponudniki varnostne popravke včasih prevzamejo kot backport, ne da bi spremenili številko različice. Takrat štejeta stanje paketa in potrditev ponudnika. Sam prikaz ne dokazuje ne popravka ne njegove odsotnosti.

Ali zadostuje, da v upravljalni plošči Plesk kliknem Posodobi?

Posodobitev sicer odloži nove datoteke, vendar delujoči procesi PHP v pomnilniku še naprej uporabljajo staro kodo. Novo stanje je aktivno šele po ponovnem zagonu vseh storitev PHP-FPM in spletnega strežnika. Nato preverite čas zagona procesov.

Ali moram popraviti tudi različice PHP, ki jih nobena domena ne uporablja?

Da, če ostanejo nameščene. Neuporabljen handler lahko pozneje pomotoma dodelite ali pa je dosegljiv prek testnih okolij. Različice, ki jih ne potrebujete, raje v celoti odstranite.

Ali posodobitev WordPress v orodju Plesk Toolkit pomaga proti PHP2Shell?

Ne. PHP2Shell zadeva sam PHP, ne CMS. Posodobitev CMS je kljub temu smiselna, vendar te ranljivosti ne odpravi.

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č