Trenutno stanje: PHP2Shell. Dvije kritične PHP ranjivosti (CVSS 9.2) omogućuju zlonamjerni kod bez prijave. Zakrpe od 21. 10. 2026.Što sada učiniti →

PHP2Shell: 15 pitanja korisnika hostinga

Vaša web-stranica je kod pružatelja hostinga, a želite znati što kod PHP2Shella morate učiniti sami? Evo 15 najčešćih pitanja s kratkim odgovorima.

Stanje 5 min čitanjaStanje i procjena

Ukratko: Što učiniti kao korisnik hostinga kod PHP ranjivosti PHP2Shell? PHP ažuriranje najčešće ne morate sami instalirati, to kod zajedničkog hostinga preuzima pružatelj hostinga. Vaši su zadaci drugi: pribaviti pisanu potvrdu razine zakrpe, u izborniku za korisnike odabrati podržanu PHP verziju i provjeriti ima li na web-stranici neobičnosti. Na 15 najčešćih pitanja o tome ovaj članak odgovara kratko i redom.

PHP ranjivost kao korisnik hostinga: jesam li pogođen, što učiniti?

Od 21. listopada 2026. stižu nam mnoga pitanja tvrtki čija je web-stranica kod pružatelja hostinga. Većina se vrti oko istih točaka. Tko želi opširnije pročitati o odgovornostima, nalazi ih na stranici Zajednički hosting: što radi pružatelj, a što morate Vi.

1. Je li moja web-stranica uopće pogođena?

Ako Vaša web-stranica radi s WordPressom, Shopwareom, TYPO3-om, Joomlom, Contaom ili nekim drugim PHP sustavom, poslužitelj ispod nje možda je pogođen. Čiste HTML stranice bez PHP-a nisu. U sumnji pomaže pogled u izbornik za korisnike: ako tamo postoji postavka za PHP verziju, koristite PHP.

2. Koja je razlika između zajedničkog hostinga i vlastitog poslužitelja?

Kod zajedničkog hostinga dijelite poslužitelj koji vodi pružatelj hostinga s drugim korisnicima; pružatelj održava PHP. Kod vlastitog root poslužitelja ili vServera odgovorni ste sami. Kod upravljanog poslužitelja ugovor uređuje tko instalira ažuriranja.

3. Moj pružatelj hostinga poslao je obavijest svima. Moram li još nešto učiniti?

Pažljivo pročitajte što u njoj piše. Zajednička obavijest često samo potvrđuje da pružatelj hostinga „radi na toj temi“. Trebate izjavu o Vašem paketu: PHP grana, razina zakrpe, vrijeme i ponovno pokretanje.

Odgovornost i ažuriranje

4. Instalira li pružatelj hostinga ažuriranje automatski?

U pravilu da, za PHP verzije koje nudi na svojim poslužiteljima. Je li to već učinjeno i pokrivaju li se i starije verzije, razlikuje se od pružatelja do pružatelja. Pitajte.

5. Moj izbornik za korisnike prikazuje staru oznaku verzije. Jesam li nezaštićen?

Ne nužno. Mnogi pružatelji hostinga ugrađuju ispravke kao backport, pa broj ostaje isti. Plesk, primjerice, može i dalje prikazivati 8.2.34 iako je pogreška otklonjena. Mjerodavna je potvrda pružatelja hostinga.

6. Još koristim PHP 7.4 ili 8.1. Što sada?

Te grane od PHP projekta više ne dobivaju službena ažuriranja. Neki pružatelji hostinga isporučuju vlastite ispravke, drugi ne. Razjasnite to pisanim putem i planirajte prelazak na podržanu granu. Prethodno u zahtjevima sustava svog CMS-a provjerite koje PHP verzije podržava.

7. Mogu li PHP verziju prebaciti sam?

Kod većine pružatelja hostinga da, u izborniku za korisnike. Kako to ide i na što prije obratiti pažnju, opisuje članak Promjena PHP verzije u korisničkom području hostinga. Prije toga napravite sigurnosnu kopiju.

8. Pomaže li ažuriranje WordPressa ili dodataka?

Protiv PHP2Shella ne, jer je ranjivost u PHP-u. Ažuriranja CMS-a ipak imaju smisla jer zatvaraju druge ranjivosti.

Provjeriti i dokazati

9. Kako od pružatelja hostinga dobiti dokaz?

Pisanim upitom koji traži konkretne podatke: stanje paketa po PHP grani, datum instalacije, ponovno pokretanje svih PHP procesa. Predložak za kopiranje nudi vodič Zatražiti potvrdu PHP ažuriranja od pružatelja hostinga.

10. Mogu li prijelazne mjere postaviti putem .user.ini?

Ne. php.net izričito odvraća od toga da se prijelazne postavke zadaju putem ini_set() ili .user.ini. Njihovo je mjesto u konfiguraciji poslužitelja, a nju kod zajedničkog hostinga vodi pružatelj hostinga.

11. Moja web-stranica bila je nakratko izvan mreže. Jesam li hakiran?

Ne nužno. Neki su pružatelji hostinga preventivno isključili web-stranice ili ponovno pokrenuli poslužitelje. Pitajte za razlog prije nego što izvučete zaključke.

12. Po čemu prepoznajem da je moja web-stranica napadnuta?

Mogući znakovi su nepoznati administratorski računi, nove PHP datoteke u mapi za upload, preusmjeravanja na tuđe stranice, tuđe stranice u Googleovu indeksu ili upozorenja u Search Consoleu. Zamolite pružatelja hostinga da čuva logove pristupa od 20. listopada.

Kad nešto ne štima

13. Pružatelj hostinga ne odgovara ili izbjegava odgovor. Što učiniti?

Pitajte pisanim putem i postavite razuman rok. Ako odgovor izostane, poslužitelj biste trebali tretirati kao neprovjeren i razmisliti o tome da web-stranicu privremeno prebacite na statičnu stranicu za hitne slučajeve.

14. Trebam li promijeniti pružatelja hostinga?

Promjena usred situacije stvara vlastite rizike. Smislena je ako pružatelj hostinga trajno ne daje informacije ili dalje vodi stare PHP verzije bez ispravka. Na što pritom paziti, opisuje članak Promjena pružatelja hostinga nakon incidenta.

15. Moram li nešto prijaviti?

Ako postoje naznake napada i ako bi mogli biti pogođeni osobni podaci, može postojati obveza prijave prema GDPR-u, u pravilu u roku od 72 sata. Razjasnite to sa svojim službenikom za zaštitu podataka ili odvjetnikom. Ovo nije pravni savjet.

Vaš kratki popis za provjeru

  1. Pisanim putem pitati pružatelja hostinga za razinu zakrpe i ponovno pokretanje.
  2. Provjeriti PHP verziju u izborniku za korisnike, zastarjele grane zamijeniti.
  3. Pregledati administratorske račune i mapu za upload.
  4. Provjeriti ima li upozorenja u Search Consoleu.
  5. Kod neobičnosti potražiti pomoć prije nego što obrišete datoteke.

Kako PHP SOS konkretno pomaže?

  • Razjašnjenje s pružateljem hostinga: Formuliramo upit ili vodimo razgovor te ocjenjujemo odgovor.
  • Provjera web-stranice: Tražimo tragove u datotekama, bazi podataka i računima, koliko to paket hostinga dopušta.
  • Čišćenje: Ako nađemo zlonamjerni kod, uklanjamo ga i mijenjamo sve pristupe.
  • Dokumentacija: Stanje dobivate pisanim putem.

Kod konkretne sumnje pomaže hitna pomoć za hakirane web-stranice.

Zaključak

Kao korisnik hostinga kod PHP2Shella ne nosite teret ažuriranja, ali nosite odgovornost za svoju web-stranicu. Većina pitanja može se riješiti jasnim pisanim odgovorom Vašeg pružatelja hostinga. Ono što nakon toga ostaje jest pogled na vlastitu web-stranicu: račune, datoteke, Googleove napomene. Tko je napravio oboje, obavio je svoj dio i u sumnji može dokazati da je postupao pažljivo.

Česta pitanja

Tko je kod web-hostinga odgovoran za PHP ažuriranje?

Kod zajedničkog hostinga u pravilu pružatelj hostinga, jer on vodi poslužitelj i PHP instalaciju. Vi ste odgovorni za svoju web-stranicu, svoje pristupe i odabir PHP verzije u izborniku za korisnike. Kod upravljanih poslužitelja podjelu uređuje ugovor.

Zašto moj pružatelj hostinga prikazuje staru PHP verziju?

Mnogi pružatelji hostinga i distribucije ugrađuju ispravak kao backport u postojeću verziju. Broj tada ostaje isti iako je ranjivost zatvorena. Zato se oslonite na pisanu potvrdu pružatelja hostinga, a ne na prikaz.

Što kao korisnik hostinga mogu sam provjeriti?

Možete provjeriti postavljenu PHP verziju u izborniku za korisnike, pregledati administratorske račune Vašeg CMS-a, potražiti nepoznate datoteke u mapi za upload i provjeriti ima li upozorenja u Search Consoleu. Razinu zakrpe samog poslužitelja može dokazati samo pružatelj hostinga.

Pomaže li postavka vatrozida u paketu hostinga?

Pravila vatrozida pružatelja hostinga ili usluge ispred mogu smanjiti rizik. Ona međutim ne zamjenjuju PHP ažuriranje na poslužitelju. Zato uvijek najprije pitajte za ažuriranje.

Izvori

Hitni kontakt

Svaki sat se računa. Pišite nam odmah.

Ukratko opišite sustav, verziju PHP-a i opažanje. Javit ćemo Vam se, razjasniti situaciju i raditi na daljinu dok incident nije zaključen i dokumentiran.

Hitna pomoć