Na kratko: Ob varnostni ranljivosti PHP, kot je PHP2Shell, je pri spletnem gostovanju za posodobitev PHP odgovoren ponudnik, ne vi. Vaša naloga je pridobiti pisno potrditev, v meniju za stranke izbrati podprto različico PHP in spletno stran preveriti glede sledi napada. Popravek ponudnika ne odstrani škodljive programske opreme, ki je prej prišla na vašo spletno stran.
Stanje v preprostih besedah
PHP je programski jezik, na katerem teče večina spletnih strani, spletnih trgovin in sistemov CMS, kot je WordPress. PHP2Shell označuje dve kritični napaki v samem PHP (CVE-2026-109618 in CVE-2026-109619). Napadalci lahko prek njiju brez gesla na strežniku izvedejo lastno kodo. BSI (nemški zvezni urad za informacijsko varnost) je razglasil opozorilno stopnjo 3 (oranžna) in priporoča takojšnjo posodobitev.
Pri shared hostingu si strežnik deli veliko strank. Tehniko pod njim, torej operacijski sistem, spletni strežnik in PHP, upravlja ponudnik. Sami upravljate samo svojo spletno stran, zbirko podatkov in dostope. Zato posodobitve PHP ne morete namestiti sami in vam je tudi ni treba.
Spletno gostovanje in ranljivost PHP: kdo je odgovoren?
Razdelitev izhaja iz vaše pogodbe. V večini paketov velja približno naslednja porazdelitev:
| Naloga | Ponudnik | Vi kot stranka |
|---|---|---|
| Posodobitev paketov PHP | da | ne |
| Ponovni zagon procesov PHP | da | ne |
| Strežniško nastavljanje vmesnih vrednosti | da | ne |
| Izbira različice PHP za vašo spletno stran | omogoča | izbere |
| Posodobitev CMS, vtičnikov, tem | ne | da |
| Dostopni podatki in skrbniški računi | ne | da |
| Preverjanje spletne strani glede škodljive kode | delno | da |
| Presoja z vidika varstva podatkov | ne | da |
Pomembna je zadnja vrstica: če na vaši spletni strani pride do incidenta z osebnimi podatki, je praviloma odgovoren vi kot upravljavec, ne ponudnik. Več o tem na strani Obveznost prijave po GDPR.
Kaj naj zdaj storite sami
1. Pridobite potrditev. Ponudnika pisno vprašajte, ali so različice PHP v vašem paketu zaščitene pred obema CVE, od kdaj, in ali so bili vsi procesi PHP znova zagnani. Gotovo predlogo najdete na strani Vprašajte ponudnika gostovanja za stanje popravkov. Ne čudite se, če v meniju za stranke še vedno piše starejša številka različice, na primer 8.2.34: nekateri ponudniki popravke dostavijo kot backport, ne da bi se številka spremenila.
2. Preverite različico PHP. V meniju za stranke poglejte, katero različico PHP uporablja vaša spletna stran. PHP 8.1 in starejše od projekta PHP ne dobijo več uradnih posodobitev. PHP 8.2 doseže konec podpore 31. 12. 2026. Ali vaš CMS podpira novejšo različico, preverite po sistemskih zahtevah proizvajalca, na primer na wordpress.org.
3. Preglejte spletno stran. Bodite pozorni na neznane skrbniške račune, nepričakovane preusmeritve, tuje datoteke v dostopu FTP in opozorila v Google Search Console. Seznam tipičnih znakov je na strani Ali so me že vdrli?.
4. Ustvarite varnostno kopijo. Prenesite aktualno varnostno kopijo datotek in zbirke podatkov ter jo hranite ločeno. Ponudnika prosite tudi, naj dnevnike dostopov vašega paketa hrani od 20. 10. 2026 naprej.
Po ponudnikovi potrditvi previdnostno zamenjajte gesla za meni za stranke, FTP/SFTP, zbirko podatkov in skrbnike CMS ter, kjer je mogoče, vključite dvostopenjsko prijavo.
Česa pri shared hostingu ne morete rešiti sami
Vmesni ukrepi, ki jih priporoča php.net, na primer session.upload_progress.enabled=0, delujejo samo, če so nastavljeni v konfiguraciji strežnika. Vnos v .user.ini ali prek ini_set() v kodi po navedbah php.net ne zadošča. Tudi omejitve pomnilnika na ravni cgroup in ponovni zagon procesov PHP so v domeni ponudnika.
Če vam ponudnik ne odgovori ali odgovarja izmikajoče, imate tri možnosti: ponovno povprašati in postaviti rok, spletno stran začasno preklopiti v vzdrževalni način ali preiti k ponudniku z jasno izjavo. BSI priporoča, da spletne strežnike začasno odklopite z omrežja, če posodobitev ni takoj mogoča.
Preverite tudi, ali je vaš paket še sodoben. Paketi, ki več let delujejo nespremenjeno, so včasih na starejših generacijah strežnikov s starejšimi različicami PHP, ki jih ponudnik vzdržuje le še omejeno. Prehod na aktualni paket istega ponudnika je pogosto povezan z majhnim naporom in prinese novejše različice PHP. Povprašajte po tem, če je odgovor o stanju popravka nezadovoljiv.
Če je spletna stran že sumljiva
Popravek pri ponudniku zapre ranljivost za prihodnost. Ne odstrani pa zadnjih vrat, ki so jih napadalci vgradili prej, in ne dokazuje, da se prej ni zgodilo nič. Če opazite nenavadnosti, ne brišite datotek na slepo. Najprej zavarujte stanje, da ostane vzrok pozneje sledljiv.
Kako PHP SOS konkretno pomaga?
- Z vami oblikujemo poizvedbo za ponudnika in njegov odgovor tehnično ovrednotimo.
- Vašo spletno stran preverimo glede spletnih lupin (webshell), tujih računov in manipuliranih datotek ter jo ob najdbi očistimo prek našega odstranjevanja škodljive programske opreme.
- Ob akutnem sumu prevzamemo nujno pomoč za vdrte spletne strani z zavarovanjem dokazov.
- Pomagamo pri izbiri ustrezne različice PHP in nato spletno stran preizkusimo.
Pogosta vprašanja
Ali moram kot stranka gostovanja PHP posodobiti sam?
Praviloma ne, saj PHP pri shared hostingu spada k platformi ponudnika. V meniju za stranke pa pogosto lahko izberete različico PHP. Če je tam navedena različica brez uradnih posodobitev, zamenjajte jo ali ponudnika vprašajte, kako jo ščiti.
Moja spletna stran ne deluje. Ali so me vdrli?
Ne nujno. Nekateri ponudniki so spletne strani previdnostno odklopili z omrežja, da bi zaprli ranljivost. Ponudnika vprašajte za razlog in si dajte potrditi, ali obstajajo znaki napada na vaš paket.
Ali lahko vmesne ukrepe sam nastavim v .user.ini?
Za session.upload_progress.enabled php.net izrecno navaja, da .user.ini in ini_set() ne zadoščata. To nastavitev mora ponudnik nastaviti v konfiguraciji strežnika.
Kaj naj imam od ponudnika v pisni obliki?
Potrditev, da so različice PHP v vašem paketu zaščitene pred CVE-2026-109618 in CVE-2026-109619, od kdaj to velja in da so bili procesi PHP znova zagnani. Ta odgovor shranite skupaj s svojo dokumentacijo.