PHP2Shell ogroža tudi slovenske strani, popravek pa je že na voljo

Urad Vlade Republike Slovenije za informacijsko varnost (URSIV) je 21. oktobra 2026 izdal odredbo o nujnih ukrepih, ker je ogroženost slovenskih omrežij in informacijskih sistemov zaradi dveh kritičnih ranljivosti PHP ocenil kot visoko; popravki so na voljo v izdajah PHP 8.2.35, 8.3.36, 8.4.27 in 8.5.12. Za upravljavca slovenske spletne strani ali trgovine je odločilna različica PHP, ki dejansko obdeluje spletne zahteve, ne zgolj podatek o nameščenem paketu na strežniku.

Evropska komisija, ENISA, CERT-EU, Europol EC3 in mreža nacionalnih skupin CSIRT so 21. oktobra 2026 v skupnem opozorilu pozvali k ukrepanju zaradi ranljivosti CVE-2026-109618 in CVE-2026-109619, ki lahko omogočita oddaljeno izvajanje kode brez prijave. Prednost imajo spletni sistemi, dostopni prek interneta, tudi kadar PHP zanje vzdržuje ponudnik gostovanja ali je vključen v izdelek drugega proizvajalca.

Na katero različico PHP je treba posodobiti

Za vsako podprto vejo obstaja najnižja izdaja, ki odpravlja obe ranljivosti: 8.2.35 za vejo 8.2, 8.3.36 za vejo 8.3, 8.4.27 za vejo 8.4 in 8.5.12 za vejo 8.5. Starejša izdaja znotraj iste veje ne zadošča. Pri paketu distribucije Linuxa je lahko prikazana osnovna različica nižja, ker distributer popravek vključi v svoj paket; v tem primeru je treba preveriti njegovo varnostno obvestilo in natančno izdajo paketa.

Najprej je treba ugotoviti različico v okolju, ki streže produkcijsko stran. Ista namestitev ima lahko drugačen PHP v ukazni vrstici, spletnem procesu, vsebniku ali nadzorni plošči gostovanja. Pri PHP 8.1 in starejših vejah rednih varnostnih izdaj projekta PHP ni več, zato pridejo v poštev popravljen paket distributerja, podaljšana podpora ali prehod na podprto vejo. Če aplikacija uporablja vgrajeni PHP, mora popravek zagotoviti proizvajalec te aplikacije; posodobitev ločenega sistemskega paketa njegove kopije ne spremeni.

Katere spletne postavitve so izpostavljene

V operativnem pregledu NCSC-NL so med izpostavljenimi načini obdelave spletnih zahtev navedeni PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP in LiteSpeed; njegov mednarodni seznam izdelkov, posodobljen 30. oktobra 2026, je spremljal 929 izdelkov, od katerih je bilo 217 označenih kot ranljivih in 165 kot popravljenih. Največje tveganje je pri Apache z mod_php, kjer lahko zahteva sproži napad še pred izvedbo aplikacijske kode. Oznaka popravljenosti posameznega izdelka velja za navedeno različico in je ni mogoče samodejno prenesti na drugo namestitev.

Pri spletni trgovini pregled zato zajema javne strani, prijavo, upravljavski del in druge poti, ki jih obdeluje PHP. Spletni strežnik lahko zahteve posreduje različnim procesom ali vsebnikom, za posamezne dele storitve pa lahko skrbi več ponudnikov. Upravljavec mora za vsako pot ugotoviti, katera namestitev PHP jo obdeluje in kdo zanjo izdaja popravek. Če posodobitev vgrajene kopije še ni na voljo, omejitev javnega dostopa zmanjša izpostavljenost, vendar ne odpravi ranljivosti.

Kako potrditi, da posodobitev deluje

Po namestitvi popravljenega paketa je treba znova zagnati vse delovne procese PHP in preveriti različico procesa, ki odgovarja na zahteve produkcijske strani. Če promet sprejema več strežnikov ali vsebnikov, je treba potrditi stanje vsakega posebej. Stari proces lahko namreč še naprej uporablja ranljivo kodo, čeprav je na disku že nameščen nov paket. Podatek iz ukazne vrstice je uporaben za orientacijo, vendar sam ne potrdi stanja spletnega procesa.

Nato pride na vrsto kratek preizkus poti, ki so pomembne za delovanje konkretne strani: odpiranje javnih strani, prijava v upravljavski del, oddaja obrazcev in nalaganje datotek, če jih storitev omogoča. Pri trgovini je treba preveriti še košarico in zaključek nakupa. Ti preizkusi pokažejo, ali je storitev po spremembi še uporabna; za potrditev varnostnega popravka je še vedno potreben podatek o različici oziroma popravljenem paketu v produkcijskem okolju. Če PHP upravlja gostitelj, naj potrditev izrecno zajema spletni proces za zadevno stran.

Kaj v dnevnikih lahko kaže na zlorabo

Posodobitev odpravi ranljivosti v prihodnjih zahtevah, sama pa ne razjasni dogajanja pred namestitvijo. Pri sistemih, ki so bili ob izdaji popravkov še ranljivi, je treba ohraniti dnevnike in pregledati usodne napake zaradi pomanjkanja pomnilnika, zlasti ob zahtevah za nalaganje datotek. Pozornost zahtevajo tudi sesutja ali nepričakovani izhodi procesov PHP-FPM oziroma spletnega strežnika ter neznani procesi in datoteke pod računom spletnega strežnika. Posamezna napaka še ni dokaz vdora, je pa razlog za podrobnejši pregled povezanih zahtev in sprememb.

Če se pokaže spletna lupina, druga zadnja vrata ali nepojasnjena sprememba datotek, je treba obravnavati tudi morebitno kompromitacijo sistema. Dnevnike je treba zavarovati pred prepisom, ugotoviti, katere datoteke in računi so bili dosegljivi napadalcu, ter slediti postopku za odziv na incident. Upravljavec lahko varnostni popravek šteje za nameščen šele, ko ga uporablja vsak spletni proces; morebitni znaki zlorabe iz časa pred posodobitvijo zahtevajo ločeno preiskavo.

Preberite tudi:

• DeepL ali Google Prevajalnik: slovenščina še vedno potrebuje pregled
• GitHubov ReviewBench meri tudi hrup pregledovalcev kode
• OpenSSL popravlja ranljivosti: možen je oddaljeni izpad storitve