Ukratko: Mnogi PHP2Shell savjeti koji trenutačno kruže na forumima i društvenim mrežama ne štite ili čak štete: blokirati zahtjeve sa session kolačićem, sakriti poruke o pogreškama, postavke zadavati putem .user.ini ili ažurirati samo CMS. php.net je jasan: nema potpunih prijelaznih mjera, PHP ažuriranje s ponovnim pokretanjem svih procesa jedini je siguran put.
Zašto su pogrešni savjeti u ovoj situaciji opasni
Kod kritične ranjivosti s velikom pozornošću nastaje tržište brzih rješenja. Savjeti se dijele, skraćuju i prosljeđuju, često bez ograničenja izvornog izvora. Kod PHP2Shella tome pridolazi to što su detalji prema izvješćima postali poznati već prije službenog termina i što je stanje u prvim danima bilo nepregledno.
Pogrešan savjet šteti dvostruko. Ostavlja ranjivost otvorenom i stvara osjećaj da je nešto učinjeno. Upravo taj osjećaj dovodi do toga da pravo ažuriranje ostaje ležati. Neki savjeti uz to onesposobljavaju i vlastitu web-stranicu.
Devet savjeta na provjeri činjenica
Sljedeća tablica sažima što smo posljednjih dana često čitali i suprotstavlja tome tvrdnje primarnih izvora.
| Savjet u opticaju | Zašto ne vrijedi | Što vrijedi umjesto toga |
|---|---|---|
Blokirati sve zahtjeve s PHPSESSID |
Stručni autori izričito odbacuju; onesposobljava prijave i košarice | Ažurirati PHP |
session.upload_progress.enabled=0 je dovoljno |
Prema stručnim izvješćima ne zatvara obje ranjivosti | Smislena prijelazna mjera, ažuriranje ostaje obveza |
Vrijednosti postavljati putem ini_set() ili .user.ini |
php.net izričito odvraća | Na strani poslužitelja u php.ini, FPM poolu ili konfiguraciji poslužitelja |
| Sakriti poruke o pogreškama | Prema php.net-u ne pomažu error_reporting, display_errors ni @ |
Ažuriranje; ispis pogrešaka ipak ne prikazivati javno |
Ograničiti memoriju putem RLIMIT_AS ili RLIMIT_DATA |
php.net upozorava da upravo to može izazvati ranjivu situaciju | Ograničenje putem containera ili cgroupa |
| Ažurirati WordPress ili dodatke | Ranjivost je u PHP interpreteru, a ne u CMS-u | Ažurirati PHP izvršno okruženje |
| Cloudflare ili neki drugi WAF je dovoljan | Zaštita samo za promet preko usluge; izravno dostupni poslužitelji ostaju otvoreni | WAF kao dodatni sloj, a ne zamjena |
| Uslugu ponovno učitati umjesto ponovno pokrenuti | Prema Red Hatu reload nije dovoljan, postojeći workeri mogu zadržati staro stanje | Potpuno ponovno pokrenuti sve workere |
| Zakrpano znači čisto | Zakrpa ne uklanja prethodno ubačeni zlonamjerni softver | Sigurnosno pohraniti logove od 20.10. i provjeriti tragove |
Tri najčešće zablude pobliže
Zabrana kolačića
Savjet da se odbace svi zahtjevi sa session kolačićem PHPSESSID zvuči tehnički i odlučno. Stručni autori izričito ga odbacuju. U praksi razbija sve što treba sesiju: korisničke račune, košarice, administratorska područja, obrasce sa zaštitom od krivotvorenja. Zaštita od ranjivosti on nije.
Jedna postavka koja sve rješava
session.upload_progress.enabled=0 nalazi se u preporukama php.net-a i protiv CVE-2026-115560 je navedeno rješenje. U nekim je člancima iz toga postalo „PHP2Shell isključen“. Prema stručnim izvješćima ta postavka sama ipak ne zatvara obje ranjivosti. Ni memory_limit=-1 prema php.net-u ne uklanja ništa osim upravljivog okidača; pogreška memorije na dubljoj razini i dalje može doseći ranjivi put. Na PHP-u 8.5 fatal_error_backtraces=0 prema php.net-u blokira samo potvrđeni put preko backtraceova.
Kako postavku ipak ispravno i trajno zadati, opisuje članak Isključivanje session.upload_progress. Potpuni popis prijelaznih mjera nalazi se na stranici Hitne mjere bez zakrpe.
Štit ispred
Cloudflare prema vlastitim navodima od 21. listopada ima aktivna zaštitna pravila, i za korisnike besplatnog paketa. Cloudflare sam međutim upozorava na granice: zaštita djeluje samo za promet koji prolazi kroz Cloudflare. Ako je izvorni poslužitelj izravno dostupan, zaobilazi se. Uz to Cloudflare dodatno provjerava odgovor poslužitelja jer sam zahtjev nije uvijek dovoljan. Zašto WAF ne zamjenjuje ažuriranje, objašnjava članak WAF ili ažuriranje.
Savjet s rizikom: filtrirati zahtjeve za upload na rubu
Nije svaki neugodan savjet pogrešan. Stručni autori predlažu kao privremenu, neslužbenu mjeru blokirati zahtjeve multipart/form-data izvan stvarnih putanja za upload na proxyju ili u WAF-u. To može smanjiti površinu napada, ali razbija obrasce i uploade ako je popis dopuštenih putanja nepotpun.
Tko ide tim putem, trebao bi ga prethodno provjeriti u testnom okruženju, uskladiti sa stručnim odjelima i dokumentirati kao vremenski ograničenu mjeru. Ni on nije zamjena za ažuriranje.
Mnoga WAF rješenja za to nude način promatranja u kojem pravila isprva samo bilježe umjesto da blokiraju. Pustite novo pravilo nekoliko dana da tako radi i analizirajte koji bi legitimni zahtjevi bili pogođeni. Tek potom prebacite na blokiranje. Tako izbjegavate da obrasci za prijavu kandidata, portali za kupce ili upload slika u shopu neopaženo ispadnu.
Kako provjeriti savjet prije nego što ga provedete
Četiri pitanja razdvajaju uporabljive od opasnih savjeta:
- Izvor: Potječe li preporuka od php.net-a, Vaše distribucije, BSI-ja ili imenom navedenog stručnog autora?
- Tvrdnja: Opisuje li se mjera kao prijelaz ili kao rješenje? Kod PHP2Shella samo je ažuriranje rješenje.
- Nuspojava: Što se razbija kad mjera djeluje? Savjet bez napomene o nuspojavama je nepotpun.
- Mjesto provedbe: Zadaje li se postavka na strani poslužitelja tako da se ne može nadjačati, uz ponovno pokretanje svih workera?
Zabilježite koje ste prijelazne mjere postavili i kada. Tako ih kasnije možete ciljano provjeriti i prepoznati je li prividna zaštita odgodila pravo ažuriranje.
Kako PHP SOS konkretno pomaže?
- Provjeravamo mjere koje su kod Vas već provedene i razdvajamo djelotvorne od nedjelotvornih.
- Instaliramo PHP ažuriranje, ponovno pokrećemo sve procese i dokazujemo stanje.
- Gdje ažuriranje još nije moguće, prijelazne mjere prema php.net-u postavljamo na strani poslužitelja i dokumentirano.
- Uz WAF i virtualno krpanje nadopunjujemo zaštitu na rubu, bez zamjene ažuriranja.
Česta pitanja
Štiti li blokiranje zahtjeva s PHPSESSID?
Ne. Stručni autori izričito odbacuju taj savjet u opticaju. On onesposobljava prijave, košarice i obrasce, a ne zatvara ranjivost u interpreteru.
Je li session.upload_progress.enabled=0 dovoljno protiv PHP2Shella?
Ne. Postavka je jedna od više prijelaznih mjera i prema stručnim izvješćima ne zatvara obje ranjivosti. Smislena je, ali ne zamjenjuje PHP ažuriranje.
Pomaže li isključivanje display_errors?
Za PHP2Shell ne. php.net upozorava da skrivanje dijagnostike putem error_reporting, display_errors ili operatora @ ne pomaže. U produkciji display_errors ipak treba biti isključen iz drugih razloga.
Po čemu prepoznajem ozbiljan savjet?
Ozbiljan savjet navodi svoj izvor, opisuje granice i prijelazne mjere naziva prijelaznima. Tko obećava da će jedna postavka učiniti ažuriranje nepotrebnim, kod PHP2Shella griješi.