Ukratko: Ako sumnjate da je Vaš poslužitelj hakiran putem PHP2Shella, javite se odmah. Jeste li pogođeni? Nazovite. Pomažemo. Od prve poruke preuzimamo obuzdavanje, osiguravamo tragove, zatvaramo ranjivost, uklanjamo zlonamjerni kod i dokumentiramo incident dok nije zaključen.
Sada ništa ne brisati i ništa ne postavljati iznova. Obrisane datoteke i prepisani zapisnici upravo su tragovi iz kojih se vidi je li netko upao i kako. Poslužitelj prema potrebi odspojite s mreže, ali ga ostavite nepromijenjenim. Prijavite hitni slučaj, reći ćemo Vam sljedeći korak.
Jeste li pogođeni? Znakovi da je PHP2Shell već iskorišten
PHP2Shell je naziv za dvije kritične ranjivosti u samom PHP-u kojima napadači mogu bez prijave izvršavati zlonamjerni kod na daljinu. Jednoznačnog otiska za sada nema. Zato je važno što poslužitelj radi, a ne što skener pronađe. Naznake provale su:
- Procesi web-poslužitelja ili PHP-FPM-a koji pokreću ljusku poput
shilibash. To je snažan znak upozorenja. - Nove ili izmijenjene PHP datoteke u mapama za prijenos, predmemoriju ili privremene datoteke koje nitko nije izradio.
- Cron poslovi, usluge ili SSH ključevi koje ne poznajete.
- Odlazne veze prema nepoznatim odredištima, iznenada veliko opterećenje ili neobičan promet podataka.
- Zahtjevi u zapisnicima od 17. 10. 2026., osobito upadljivi prijenosi datoteka i zahtjevi za sesije prije instalacije zakrpe.
- Poruke pružatelja hostinga, preglednika ili tražilice o spamu, zlonamjernom softveru ili preusmjeravanjima.
Više o tome pronaći ćete na stranici Jesam li već kompromitiran?. Ako nijedan znak ne postoji, to nije dokaz da je poslužitelj čist. Znači samo da za sada ništa nije uočeno.
Što učiniti odmah
- Ništa ne mijenjati. Ne brisati datoteke, ne vraćati sigurnosnu kopiju, ne instalirati iznova prije nego što se stanje osigura.
- Osigurati zapisnike. Zamolite pružatelja hostinga ili svoj IT da ne prepisuju zapisnike pristupa, pogrešaka i sustava. Stručni tisak savjetuje čuvanje zapisnika od 20. 10. 2026.
- Odlučiti o dostupnosti. Ako podaci mogu curiti ili bi posjetitelji mogli biti ugroženi, web-stranicu odspojite s mreže ili je stavite u način održavanja.
- Prikupiti pristupe. Zabilježite tko ima pristup poslužitelju, panelu, CMS-u i bazi podataka. Lozinke mijenjajte tek nakon dogovora i s čistog uređaja.
- Obavijestiti odgovorne. Upravu, službenika za zaštitu podataka, a ako postoji polica, i osiguratelja.
- Nazvati nas ili nam pisati. Što prije upoznamo situaciju, to će se više moći dokazati.
Kako PHP SOS konkretno pomaže?
Radimo na daljinu, bez dolaska, u cijeloj Njemačkoj i Europi.
- Procijeniti situaciju: Razjašnjavamo koji sustavi rade, koji se PHP način rada koristi, što je uočeno i koji bi podaci mogli biti pogođeni.
- Osigurati i zatvoriti: Osiguravamo datoteke, bazu podataka i zapisnike te utvrđujemo stanje prije svake izmjene. Zatim zatvaramo ranjivost zakrpom ili, ako ona još nije moguća, privremenim mjerama, te ponovno pokrećemo sve PHP procese.
- Provjeriti i očistiti: Tražimo web shellove, stražnja vrata, cron poslove i tuđe pristupe te ih uklanjamo ili stanje iznova gradimo iz pouzdanih izvora. Postupak opisuje stranica Uklanjanje malwarea i web shellova.
- Ojačati i izvijestiti: Mijenjamo pogođene tajne podatke, nadograđujemo zaštitne mjere i isporučujemo izvješće koje razdvaja dokazano, vjerojatno i nepoznato.
Ako incident nadiđe jedan poslužitelj, prelazimo na strukturirani odgovor na incident. Ako su potrebni dokazi koji drže pred sudom, uključujemo IT forenziku.
Zašto sama zakrpa nakon napada nije dovoljna
Ranjivosti su u PHP interpreteru, a ne u CMS-u. PHP projekt objavio je 21. 10. 2026. verzije 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Tko je nakon toga ažurirao i ponovno pokrenuo sve workere, zaštićen je od novih napada tim putem. No ono što je napadač prethodno ostavio ostaje: web shell, dodatni račun, zakazani zadatak. Upravo su zato dani između 17. i 21. 10. osobito važni.
Tome se pridodaje drugi razlog: web shell je često tek prvi korak. Tko je mogao izvršavati kod na web-poslužitelju, mogao je čitati i konfiguracijske datoteke te iz njih preuzeti pristupe bazi podataka, e-pošti i API-ju. Te tajne podatke treba zamijeniti, inače vrata ostaju otvorena iako je PHP zakrpan. Kako smisleno provjeriti datoteke i vremena, opisuje savjetnik o prepoznavanju web shellova.
Obveza prijave i dokumentacija
Ako su mogli biti pogođeni osobni podaci, prijava nadzornom tijelu u roku od 72 sata može postati potrebna. Rok teče od saznanja, a ne od završetka istrage. Je li Vaš slučaj obvezan na prijavu, odlučuju službenik za zaštitu podataka ili odvjetnik; pravni savjet ne pružamo. Naša dokumentacija za to daje osnovu. Više o roku pišemo na stranici Obveza prijave prema GDPR-u u 72 sata, a korake nakon toga u Kontrolnom popisu nakon hakiranja.
Što nam trebate poslati
- Opis što se i od kada primjećuje te tko je to uočio
- Vrsta poslužitelja: vlastiti poslužitelj, upravljani poslužitelj ili hosting paket, uz pružatelja hostinga
- Rezultat naredbe
php -vi, ako je poznat, način rada (PHP-FPM, mod_php, LiteSpeed) - Vrijeme PHP ažuriranja, ako je već instalirano
- Pristup poslužitelju ili dopuštenje da razgovaramo s Vašim pružateljem hostinga
- Kontakt osoba s ovlastima za isključivanje i ponovna pokretanja
Zašto PHP SOS
Radimo Made in Germany i više od 25 godina s našom mrežom partnera stručnjaka za kibernetičku sigurnost specijalizirani smo za IT sigurnost. Imate jednu kontakt osobu koja Vas prati od prve poruke do zaključenja. Sve što radimo dokumentira se kako biste to mogli dokazati upravi, osiguratelju i tijelima. Ne obećavamo ništa što nitko ne može ispuniti: ako zapisnici nedostaju, to otvoreno kažemo, a navodimo i što je dokazano, a što ostaje pretpostavka.
Jeste li pogođeni? Nazovite. Pomažemo.
Ne čekajte da sumnja postane sigurnost. Nazovite ili pišite putem WhatsAppa. Preuzimamo od prve poruke i ostajemo uz Vas dok incident nije zaključen i dokumentiran. Prijavite hitni slučaj odmah.
Česta pitanja
Je li dovoljno ažurirati PHP ako je moj poslužitelj možda već hakiran?
Ne. Ažuriranje zatvara ranjivost, ali ne uklanja zlonamjerni softver koji je već ubačen i ne dokazuje da se prije nije ništa dogodilo. Nakon zakrpe poslužitelj se mora provjeriti na tragove provale.
Po čemu prepoznajem uspješan PHP2Shell napad?
Ne postoje objavljeni, potvrđeni indikatori kompromitacije (Indicators of Compromise). Otkrivanje se temelji na ponašanju: procesi web-poslužitelja koji pokreću ljusku, nove PHP datoteke u mapama za prijenos ili predmemoriju, nepoznati cron poslovi ili SSH ključevi i upadljive odlazne veze.
Trebam li poslužitelj odspojiti s mreže ako sumnjam na provalu?
To je često ispravno, jer BSI (njemački Savezni ured za informacijsku sigurnost) savjetuje privremeno odspojiti web-poslužitelj s mreže čak i kada ažuriranje nije odmah moguće. Važno je pritom ništa ne brisati te sačuvati zapisnike i datoteke kako bi se incident mogao razjasniti.
Moram li nakon PHP2Shell napada obavijestiti tijelo za zaštitu podataka?
Ako bi mogli biti pogođeni osobni podaci, prijava u roku od 72 sata može biti potrebna. Odluku donosite sa svojim službenikom za zaštitu podataka ili odvjetnikom; mi za to isporučujemo tehničke činjenice.
Jesu li poslužitelji doista već hakirani putem PHP2Shella?
Prema medijskim izvješćima prvi pokušaji napada opaženi su od 17. 10. 2026., a Cloudflare je izvijestio o opaženim pokušajima napada. BSI u početku nije prijavio potvrđene uspješne napade u širem opsegu. U pojedinačnom slučaju to se može razjasniti samo na samom poslužitelju.