Na kratko: Mnogi nasveti za PHP2Shell, ki trenutno krožijo po forumih in družbenih omrežjih, ne ščitijo ali celo škodijo: blokirati zahteve s sejnim piškotkom, skriti sporočila o napakah, nastavitve nastavljati prek .user.ini ali posodobiti samo CMS. php.net je nedvoumen: popolnih prehodnih ukrepov ni, posodobitev PHP s ponovnim zagonom vseh procesov je edina varna pot.
Zakaj so napačni nasveti v tem položaju nevarni
Ob kritični ranljivosti z veliko pozornostjo nastane trg hitrih rešitev. Nasveti se delijo, krajšajo in posredujejo naprej, pogosto brez omejitev izvirnega vira. Pri PHP2Shell se poleg tega po poročilih podrobnosti postale znane že pred uradnim terminom in je bilo stanje v prvih dneh nepregledno.
Napačen nasvet škoduje dvakrat. Pusti ranljivost odprto in ustvari občutek, da je bilo nekaj storjeno. Prav ta občutek povzroči, da prava posodobitev obleži. Nekateri nasveti poleg tega onesposobijo lastno spletno stran.
Devet nasvetov v preverjanju dejstev
Naslednja tabela povzema, kaj smo v zadnjih dneh pogosto brali, in jim nasproti postavlja izjave primarnih virov.
| Krožeči nasvet | Zakaj ne zdrži | Kaj velja namesto tega |
|---|---|---|
Blokirati vse zahteve s PHPSESSID |
Strokovni avtorji ga izrecno zavračajo; onesposobi prijave in košarice | Posodobiti PHP |
session.upload_progress.enabled=0 zadošča |
Po strokovnih poročilih ne zapre obeh ranljivosti | Smiseln prehodni ukrep, posodobitev ostane dolžnost |
Vrednosti nastavljati prek ini_set() ali .user.ini |
php.net to izrecno odsvetuje | Na strežniku v php.ini, poolu FPM ali konfiguraciji strežnika |
| Skriti sporočila o napakah | Po php.net error_reporting, display_errors ali @ ne pomagajo |
Posodobitev; izpisa napak kljub temu ne kazati javno |
Pomnilnik omejiti prek RLIMIT_AS ali RLIMIT_DATA |
php.net opozarja, da lahko prav to sproži ranljivo situacijo | Omejitev prek containerja ali cgroup |
| Posodobiti WordPress ali vtičnike | Ranljivost je v interpreterju PHP, ne v CMS | Posodobiti izvajalno okolje PHP |
| Cloudflare ali drug WAF zadošča | Zaščita samo za promet prek storitve; neposredno dosegljivi strežniki ostanejo odprti | WAF kot dodatna plast, ne kot nadomestilo |
| Storitev ponovno naložiti namesto znova zagnati | Po Red Hat reload ne zadošča, obstoječi workerji lahko obdržijo staro stanje | Vse workerje v celoti znova zagnati |
| Popravljeno pomeni čisto | Popravek ne odstrani predhodno vnesene škodljive programske opreme | Loge od 20. 10. varnostno shraniti in preveriti sledi |
Tri najpogostejše zmote podrobneje
Prepoved piškotkov
Nasvet, da se zavrnejo vse zahteve s sejnim piškotkom PHPSESSID, zveni tehnično in odločno. Strokovni avtorji ga izrecno zavračajo. V praksi pokvari vse, kar potrebuje sejo: račune strank, košarice, skrbniška območja, obrazce z zaščito pred ponarejanjem. Zaščita pred ranljivostjo ni.
Ena nastavitev, ki vse reši
session.upload_progress.enabled=0 je v priporočilih php.net in je proti CVE-2026-115560 navedena pomoč. V nekaterih prispevkih je iz tega nastalo „PHP2Shell izklopljen“. Po strokovnih poročilih sama ta nastavitev obeh ranljivosti ne zapre. Tudi memory_limit=-1 po php.net odpravi samo krmiljivi sprožilec; napaka pomnilnika na globlji ravni lahko ranljivo pot še vedno doseže. Na PHP 8.5 fatal_error_backtraces=0 po php.net blokira samo potrjeno pot prek backtraces.
Kako nastavitev vseeno pravilno in trajno nastavite, opisuje prispevek Izklop session.upload_progress. Celoten seznam prehodnih ukrepov je pod Takojšnji ukrepi brez popravka.
Ščit pred vrati
Cloudflare ima po lastnih navedbah od 21. oktobra aktivna zaščitna pravila, tudi za stranke v brezplačnem tarifu. Cloudflare sam pa opozarja na meje: zaščita deluje samo za promet, ki teče prek Cloudflare. Če je izvorni strežnik neposredno dosegljiv, se zaobide. Poleg tega Cloudflare dodatno preverja odgovor strežnika, ker sama zahteva ne zadošča vedno. Zakaj WAF posodobitve ne nadomesti, pojasnjuje prispevek WAF ali posodobitev.
Nasvet s tveganjem: filtriranje zahtev za nalaganje na robu
Vsak neprijeten nasvet ni napačen. Strokovni avtorji kot začasen, neuraden ukrep predlagajo, da se zahteve multipart/form-data zunaj pravih poti za nalaganje blokirajo na proxyju ali v WAF. To lahko zmanjša površino napada, a pokvari obrazce in nalaganja, če je seznam dovoljenih poti nepopoln.
Kdor ubere to pot, naj jo prej preizkusi v testnem okolju, uskladi s strokovnimi oddelki in dokumentira kot časovno omejen ukrep. Tudi ta ni nadomestilo za posodobitev.
Mnoge rešitve WAF za to ponujajo način opazovanja, v katerem pravila sprva samo beležijo namesto blokirajo. Novo pravilo pustite nekaj dni teči tako in ovrednotite, katere legitimne zahteve bi bile prizadete. Šele nato preklopite na blokiranje. Tako se izognete temu, da bi obrazci za prijave, portali za stranke ali nalaganje slik v trgovini neopazno odpovedali.
Tako preverite nasvet, preden ga uporabite
Štiri vprašanja ločijo uporabne nasvete od nevarnih:
- Vir: Ali priporočilo prihaja od php.net, vaše distribucije, BSI (nemški zvezni urad za informacijsko varnost) ali imensko navedenega strokovnega avtorja?
- Zahtevek: Ali je ukrep opisan kot prehod ali kot rešitev? Pri PHP2Shell je samo posodobitev rešitev.
- Stranski učinek: Kaj se pokvari, ko ukrep deluje? Nasvet brez opozorila na stranske učinke je nepopoln.
- Mesto izvedbe: Ali je nastavitev nastavljena na strežniku in ni prepisljiva, nato pa sledi ponovni zagon vseh workerjev?
Zabeležite, katere prehodne ukrepe ste kdaj uvedli. Tako jih lahko pozneje ciljno preverite in prepoznate, ali je domnevna zaščita zakasnila pravo posodobitev.
Kako konkretno pomaga PHP SOS?
- Preverimo ukrepe, ki so pri vas že izvedeni, in ločimo učinkovite od neučinkovitih.
- Namestimo posodobitev PHP, znova zaženemo vse procese in stanje dokažemo.
- Kjer posodobitev še ni mogoča, prehodne ukrepe po php.net uvedemo na strežniku in dokumentirano.
- Z WAF in virtualnim popravljanjem zaščito na robu dopolnimo, ne da bi nadomestili posodobitev.
Pogosta vprašanja
Ali ščiti, če blokiram zahteve s PHPSESSID?
Ne. Strokovni avtorji ta krožeči nasvet izrecno zavračajo. Onesposobi prijave, košarice in obrazce, ne da bi zaprl ranljivost v interpreterju.
Ali session.upload_progress.enabled=0 zadošča proti PHP2Shell?
Ne. Nastavitev je eden od več prehodnih ukrepov in po strokovnih poročilih ne zapre obeh ranljivosti. Je smiselna, a posodobitve PHP ne nadomesti.
Ali pomaga izklop display_errors?
Za PHP2Shell ne. php.net opozarja, da skrivanje diagnostike prek error_reporting, display_errors ali operatorja @ ne pomaga. V produkciji naj bo display_errors iz drugih razlogov vseeno izklopljen.
Po čem prepoznam resen nasvet?
Resen nasvet navede svoj vir, opiše meje in prehodne ukrepe označi kot take. Kdor obljublja, da posamezna nastavitev naredi posodobitev nepotrebno, se pri PHP2Shell moti.