Imaš dvanaest klijentskih sajtova. Svi su na jednom hosting nalogu, jer je tako bilo najjeftinije i najlakše kad si kretao. Jedan od tih sajtova koristi dodatak koji klijent nije ažurirao devet meseci, jer si mu ti davno dao pristup i on se tamo povremeno igra. U utorak ujutru ti stigne mejl od Google-a da je jedan sajt označen kao opasan.
Pitanje nije da li ćeš to očistiti. Pitanje je koliko sajtova čistiš.
Odgovor zavisi od jedne odluke koju si doneo pre godinu dana, verovatno bez razmišljanja: da li svaki klijent ima svoj nalog, ili svi dele jedan.
Šta tačno znači da je sve na jednom nalogu
Kad na cPanel nalogu dodaš addon domen, ne dobijaš nov nalog. Dobijaš još jedan folder unutar istog naloga. Svi fajlovi imaju istog vlasnika, PHP se izvršava pod istim korisnikom, i baze su u istom MySQL korisničkom prostoru.
To u praksi znači da skripta koja se izvršava na sajtu A ima pravo da čita i piše po fajlovima sajta B. Nije u pitanju loše podešavanje. Operativni sistem gleda vlasnika fajla, a vlasnik je isti.
Sucuri ovo zove cross-site contamination i opisuje ga baš tako: sajtovi u istom okruženju obično imaju pravo pisanja jedan po drugom, naročito u cPanelu sa addon domenima. Dovoljna je jedna kompromitovana admin lozinka da zaraza pređe na sve.
Ako držiš svoje sajtove, to je tvoj problem i tvoja odluka. Ako držiš tuđe, to je dvanaest firmi koje ne znaju da dele sudbinu.
Kako se zaraza kreće bočno
Napadač retko ulazi kroz glavna vrata. Obično uđe kroz najslabiji sajt u grupi, onaj sa napuštenim dodatkom ili starom temom, i tu ostavi uploader skriptu. Ta skripta ne radi ništa spektakularno. Ona samo omogućava da se kasnije ubaci nešto drugo.
Sledeći korak je obilazak susedstva. Skripta pročita strukturu foldera iznad sebe, nađe ostale sajtove, i u svaki ubaci isti kod. Najčešće u fajl koji nikad ne otvaraš, tipa wp-includes nečega ili u temu koja se retko ažurira.
Ti očistiš sajt koji je Google prijavio. Za dve nedelje isti problem izađe na drugom sajtu, pa na trećem. Svaki put ti izgleda kao nova provala, a zapravo je ista, samo se seli.
Ovo je najskuplji deo priče. Čišćenje jednog sajta je posao od sat vremena. Tri meseca gašenja požara, uz klijenta kome svaki put objašnjavaš da je sad stvarno rešeno, to je nešto drugo.
Brojke iz 2026 koje su promenile računicu
Patchstack je u martu objavio godišnji izveštaj o bezbednosti WordPressa. Nekoliko podataka odatle menja način na koji treba da razmišljaš o ovome.
U 2025. je u WordPress ekosistemu otkriveno 11.334 novih ranjivosti, što je 42 odsto više nego 2024, kad ih je bilo 7.966. Od toga je 91 odsto bilo u dodacima, a u samom jezgru WordPressa svega šest.
Visoko ozbiljnih, onih koje se koriste u masovnim automatizovanim napadima, bilo je 1.966, odnosno 17 odsto. To je više nego u prethodne dve godine zajedno.
Najgori podatak je vreme. Ponderisani medijan od objave ranjivosti do prve eksploatacije u 2025. bio je pet sati. Dvadeset odsto je iskorišćeno u prvih šest sati, 45 odsto u prva 24 sata, 70 odsto u prvih sedam dana.
Uz to, 46 odsto ranjivosti je objavljeno dok zakrpa još nije postojala. Skoro polovina.
Ovo ruši pretpostavku na kojoj mnogi grade održavanje: da je dovoljno redovno ažuriranje. Ako se ranjivost koristi pet sati posle objave, a zakrpe često nema ni tada, tvoje ažuriranje u petak ujutru je druga linija odbrane, ne prva.
Kad ne možeš da sprečiš ulazak sa sigurnošću, jedino što ti ostaje je da ograničiš štetu. A štetu ograničavaš izolacijom.
Hosting te neće spasiti koliko misliš
Isti izveštaj sadrži deo koji hosteri ne vole da citiraju. Patchstack je u 2025. uradio dva pentest istraživanja i testirao uobičajenu zaštitu kod raznih hostera: interne WAF-ove, Cloudflare, Imunify360 i ModSecurity, protiv stvarnih WordPress eksploata.
Tradicionalna zaštita je blokirala 12 odsto napada kad se merilo na poznatim iskorišćenim ranjivostima. Šire postavljen test je podigao taj broj na 26 odsto.
Najbolji host van Patchstack-ovog kruga blokirao je 60,7 odsto. Više njih je bilo ispod 17 odsto. Jedan nije blokirao ništa.
Razlog je u prirodi napada. Najveći deo otpada na Broken Access Control, napad koji u saobraćaju izgleda kao potpuno normalan zahtev prijavljenog korisnika. Nema injekcije, nema čudnog stringa, nema ničega što generičko pravilo može da prepozna.
Zaštita nije beskorisna, ali je loša jedina brana. Ono što hosting može da uradi sa sigurnošću je da drži sajtove razdvojene. Za to ne mora ništa da prepozna, dovoljno je da tako bude postavljeno.
Šta sam izmerio na sopstvenom nalogu
Da ne ostane na teoriji, seo sam na jedan naš nalog i proverio šta se odatle uopšte vidi. Rezultati su od 23. septembra 2026.
Prvo, spisak korisnika. Komanda ls /home vraća tačno jedan folder, moj. Fajl /etc/passwd ima 25 redova, iako na serveru živi znatno više naloga. Ono što nalog ne vidi, ne može ni da napadne.
Drugo, procesi. ps aux iz naloga prikazuje samo procese tog istog korisnika. Nijedan tuđi.
Treće, PHP. Lista disable_functions na nalogu blokira exec, system, passthru, shell_exec, proc_open i popen. To je šest funkcija koje svaka iole ozbiljnija web shell skripta pokuša prvo.
Četvrto, resursi. Nalog ima svoje granice: 100 ulaznih procesa, 115 ukupnih procesa, 2 GB radne memorije i ceo jedan CPU. Kad sajt na susednom nalogu bude pogođen napadom koji troši procesor, on udari u svoj zid, a ne u tvoj.
Peto, dozvole. Folder public_html stoji kao drwxr-x--- sa vlasnikom naloga. Niko sa strane nema pravo čitanja.
Ovo je ono što izolacija stvarno znači na nivou servera, i to je merljivo za par minuta. Nije obećanje iz marketinškog teksta.
Malware koji se vraća posle čišćenja
Još jedan razlog zašto izolacija vredi više nego ranije. Napadači sve ređe ostavljaju zaseban zlonameran fajl koji možeš da obrišeš. Umesto toga ubacuju kod u postojeće fajlove teme, dodataka ili jezgra. Obrišeš fajl i slomiš sajt.
Porodica malvera Lock360, čije su dve glavne varijante činile 38 i 32 odsto svih detekcija ubrizganog koda u 2025, ide korak dalje. Ona drži kod u memoriji servera i prepisuje očišćene fajlove čim ih vratiš. Izveštaj to opisuje kao krug u kom timovi podrške očiste zarazu pa ona odmah ponovo napiše sebe.
Parrot TDS je bio najčešći ubrizgani kod, sa 64 odsto svih ubrizganih sekvenci. On radi kao skretničar: Google-ovom botu servira spam sa ključnim rečima, čoveku redirekciju na prevaru, a bezbednosnom skeneru ništa. Novije varijante prepoznaju i AI botove tipa ChatGPT i Gemini, pa i njima serviraju čist sadržaj.
Ako ti se takvo nešto desi na jednom nalogu sa dvanaest sajtova, čišćenje nije jedan posao nego dvanaest, i svaki mora da se završi u istom prozoru. Inače ti se zaraza vrati sa sajta koji si ostavio za kraj.
Koliko te odvojeni nalozi stvarno koštaju
Na ovom mestu razgovor uvek skrene na cenu, pa evo brojeva.
Agency Starter paket je 3.333 dinara mesečno uz godišnje plaćanje, sa 50 GB prostora i do 20 odvojenih cPanel naloga. Ako popuniš svih 20, to je 167 dinara po klijentu mesečno. Agency Pro je 5.833 dinara sa 100 GB i do 50 naloga, što je 117 dinara po nalogu.
Svaki podnalog dobija svoje: 2 GB RAM-a, 4 CPU jezgra, 100 ulaznih i 200 aktivnih procesa, 20 MB/s propusnosti diska uz 2048 IOPS-a i 500.000 inodova. Dnevni bekap ide po nalogu, ne po grupi, što znači da vraćanje jednog klijenta ne dira ostale.
Uporedi to sa jednim popodnevom koje potrošiš na čišćenje zaraze koja se seli. Ako ti je sat vremena 2.000 dinara, izgubio si mesečni trošak izolacije za celu agenciju, i to samo na prvom požaru.
Isti račun važi i ako radiš sam. Hosting za frilensere postoji baš zato što frilenser drži tuđe sajtove, a ne svoje, pa mu granica između klijenata vredi isto koliko i agenciji.
Kad je jedan nalog sasvim u redu
Ne treba preterati. Ima situacija u kojima odvajanje nema smisla.
Ako držiš svoje sajtove, sve pod istim brendom, i ti si jedini koji ima pristup, jedan nalog je u redu. Rizik je tvoj i ti ga kontrolišeš.
Ako imaš dva klijenta i oba plaćaju po 3.000 dinara mesečno za održavanje, matematika odvajanja ti verovatno još ne radi. Napravi bekap koji stvarno testiraš i sačekaj peti sajt.
Ako su svi sajtovi koje držiš čiste vizitke bez korisničkih naloga, prodavnice i formi, površina napada ti je mala. Rizik postoji, ali je manji nego kod prodavnice sa deset dodataka.
Granica se prepozna po jednom pitanju: može li propust jednog klijenta da ti obori drugog klijenta. Kad odgovor postane da, odvajanje više nije tehnička tema nego poslovna.
Šta da uradiš ove nedelje
Ako ti je sve na jednom nalogu, ne moraš da seliš odmah. Ima nekoliko stvari koje vrede pre selidbe.
Otvori File Manager i pogledaj gde tačno žive addon domeni. Ako su unutar public_html glavnog sajta, tvoji sajtovi mogu da pišu jedan po drugom i to je stanje koje sad znaš.
Napravi spisak po riziku. Koji sajt ima najviše dodataka, koji ima korisničke naloge, kome je klijent tražio admin pristup. Taj sajt seli prvi, jer on najverovatnije unosi zarazu ostalima.
Proveri da li tvoj bekap radi po sajtu ili po celom nalogu. Ako radi po nalogu, vraćanje jednog klijenta znači vraćanje svih na isti datum, a to obično ne možeš da izvedeš usred radnog dana. Ako ti ta tema nije razrađena, imamo poseban tekst o tome kako se pravi bekap strategija po sajtu.
Kad budeš selio, seli u talasima i po jedan klijent, ne sve odjednom. I iskoristi priliku da središ i ono što klijent vidi, jer white label podešavanje se najlakše radi u trenutku kad ionako praviš nov nalog.
Odvojeni nalozi ti neće sprečiti provalu. Ali kad ti u utorak ujutru stigne onaj mejl od Google-a, razlika je u tome da li zoveš jednog klijenta ili dvanaest.
Ako među klijentima imaš i advokatske kancelarije, kod kojih hakovan sajt znači i problem sa poverljivošću, pogledaj WordPress hosting za advokate, gde je svaki sajt odvojen od ostalih.
