Na kratko: Kdor še upravlja PHP 8.1 ali starejši, od projekta PHP ne prejema več uradnih varnostnih posodobitev, tudi ne za PHP2Shell. Nadgradnja s PHP 8.1 na podprto različico zato ni dodatek, ampak prava rešitev. Preverimo vaše aplikacije, preizkusimo na kopiji, nadzorovano preselimo in zavarujemo čas do tedaj.
Zakaj sta PHP 8.1 in starejši zdaj akutno tveganje
Ranljivosti PHP2Shell CVE-2026-109618 in CVE-2026-109619 omogočata izvajanje kode brez prijave. Odpravljeni sta v PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Za PHP 8.1 in starejše uradnih posodobitev ni več, samo minimalni backporti izvorne kode za 7.4, 8.0 in 8.1. Po poročilih strokovnega tiska so prizadete skoraj vse različice nazaj do PHP 5.4.
Nekatere distribucije in ponudniki gostovanja nameščajo lastne backporte. Ali vaš sistem sodi zraven, mora ponudnik potrditi za vaše konkretno stanje paketa. Brez te potrditve izhajajte iz tega, da je strežnik odprt. Kaj to pomeni v podrobnostih, opisuje stran PHP 8.1 in starejši: kaj velja zdaj.
Nadgradnja s PHP 8.1: katera ciljna različica?
Cilj naj bo različica, ki jo projekt PHP še podpira in jo vaša aplikacija potrjuje. Aktualno stanje podpore objavlja php.net na strani podprtih različic. PHP 8.2 se konča 31. 12. 2026; prehod na 8.2 bi bil torej samo vmesni korak z bližnjim nadaljnjim projektom.
Katero različico PHP podpira vaš CMS ali sistem trgovine, preverimo na podlagi sistemskih zahtev proizvajalca, na primer na wordpress.org, shopware.com ali typo3.org, ne po spominu. Pogosto je treba najprej posodobiti sam CMS. Stare trgovine so tipičen primer, glejte Shopware 5: stare trgovine na stari različici PHP.
Kako konkretno pomaga PHP SOS?
- Popis in zavarovanje: zabeležimo vse aplikacije, njihovo različico PHP, stanje CMS-ja, razširitve in lastno kodo. Vzporedno uvedemo vmesne ukrepe po php.net, da tveganje do selitve upade; podrobnosti na strani WAF in virtualno popravljanje.
- Preveriti združljivost: uskladimo sistemske zahteve proizvajalcev, z Composerjem preverimo odvisnosti in v lastni kodi iščemo zastarele funkcije. Kako to izgleda pri odvisnostih, opisuje stran Preverjanje odvisnosti Composer glede ranljivosti.
- Preizkus na kopiji: aplikacija najprej teče v testnem okolju z novo različico PHP. Napake tam odpravimo ali jih dokumentiramo za vašo agencijo.
- Preklop s potjo nazaj: preklop v živo poteka v usklajenem oknu vzdrževanja z aktualno varnostno kopijo in določeno potjo nazaj.
- Naknadna kontrola: po preklopu preverimo dnevnike napak in osrednje funkcije ter odstranimo staro različico PHP, če je ne potrebujemo več.
Neškodljiv pogled na to, katere spletne strani uporabljajo katero različico PHP, je na številnih sistemih mogoč prek tekočih poolov FPM:
# prikaži tekoče glavne procese in pool PHP-FPM
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# nameščene različice PHP (Debian/Ubuntu)
ls /etc/php/
Nadgradnja na novo različico PHP ne odstrani škodljive programske opreme, ki je bila vnesena prej. Če je bil strežnik od 17. 10. 2026 nezaščiten na omrežju, sodi zraven pregled sledi.
Tipične ovire pri nadgradnji
Večina težav pri zamenjavi različice PHP je predvidljivih, če veste, kje iskati:
- Zastarele razširitve: vtičniki ali moduli, ki se ne vzdržujejo več, na novejših različicah PHP pogosto ne tečejo. Zanje je potrebno nadomestilo ali prilagoditev.
- Lastna koda: funkcije, ki jih je PHP medtem označil za zastarele ali odstranil, povzročijo opozorila ali prekinitve. Strožja preverjanja tipov razkrijejo stare programerske napake.
- Odvisnosti: knjižnice, vključene prek Composerja, včasih same zahtevajo nove različice in potegnejo za sabo nadaljnje spremembe.
- Razširitve PHP na strežniku: vsaka razširitev, nameščena pod staro različico, ni samodejno na voljo za novo.
- Cron opravila in ukazna vrstica: spletna stran že teče na novi različici, načrtovana opravila pa še kličejo staro različico PHP.
Kdor te točke preveri vnaprej, skrajša preklop in se izogne presenečenjem v živem obratovanju.
Kaj dobite in kaj potrebujemo
Dobite pregled vseh aplikacij z izhodiščno in ciljno različico, načrt selitve z vrstnim redom in tveganji, zapisnik preizkusa, dokumentacijo preklopa in seznam točk, ki jih mora še opraviti vaša agencija ali razvijalec.
Od vas potrebujemo:
- dostop do strežnika ali panela in dostop do zaledij CMS-jev
- dostop do izvorne kode in repozitorija pri lastnih razvojih
- stik z agencijo ali razvijalcem, ki aplikacijo pozna
- testno okolje ali dovoljenje, da ga ustvarimo
- okna vzdrževanja in kontaktno osebo za prevzem
Česa ne obljubljamo
Ne obljubljamo, da vsaka stara aplikacija brez sprememb teče na novi različici PHP. Pri sistemih brez nadaljnjega razvoja je lahko potrebna večja predelava ali zamenjava; to odkrito povemo, ko se pokaže. Izjave o združljivosti opiramo na podatke proizvajalcev. In vmesni ukrepi niso nadomestilo za selitev, ampak čas samo premostijo. Dolgoročna tveganja zastarelih različic opisuje stran PHP End of Life: tveganja zastarelih različic.
Pogosta vprašanja
Ali je PHP 8.1 prizadet zaradi PHP2Shell?
Po poročilih strokovnega tiska so prizadete skoraj vse različice nazaj do PHP 5.4. Za PHP 8.1 in starejše projekt PHP ne izdaja več uradnih posodobitev, samo minimalne backporte izvorne kode za 7.4, 8.0 in 8.1. Nekatere distribucije nameščajo lastne backporte, kar mora potrditi zadevni ponudnik.
Na katero različico PHP naj nadgradim?
Na različico, ki jo projekt PHP še aktivno podpira in jo vaša aplikacija po sistemskih zahtevah proizvajalca potrjuje. PHP 8.2 doseže konec podpore 31. 12. 2026 in je zato kot cilj le pogojno smiseln.
Ali ne morem preprosto zamenjati različice PHP v panelu gostovanja?
Tehnično je to pogosto mogoče z enim klikom. Ali aplikacija potem še deluje, je odvisno od različice CMS-ja, razširitev in lastne kode. Brez preizkusa tvegate izpade ali napačno delovanje funkcij, na primer v blagajni trgovine.
Kaj če moj CMS nove različice PHP ne podpira?
Takrat je treba najprej posodobiti CMS, po možnosti na novo glavno različico. Pri sistemih brez nadaljnjega razvoja je lahko potrebna zamenjava. Do takrat strežnik zavarujemo z vmesnimi ukrepi.