Dvije kritične ranjivosti u PHP-u, jeziku na kojem rade brojni portali, trgovine, forumi i WordPress instalacije, pokrenule su hitnu utrku za zakrpama. Problem je dobio naziv PHP2Shell, a vodi se pod oznakama CVE-2026-109618 i CVE-2026-109619. PHP projekat navodi da obje greške mogu omogućiti udaljeno izvršavanje koda bez prethodne prijave korisnika. To je najteža klasa web-rizika jer napadaču, u određenim uslovima, može otvoriti put prema izvršavanju naredbi s ovlastima procesa koji pokreće web-aplikaciju.

Najvažnija vijest za vlasnike sajtova jeste da su zakrpe dostupne. PHP je objavio sigurnosne verzije 8.5.12, 8.4.27, 8.3.36 i 8.2.35 i naglasio da ne postoji potpuna zamjenska mjera koja bi nadogradnju učinila nepotrebnom. To znači da privremeno filtriranje saobraćaja može smanjiti rizik, ali nije razlog da se odgodi ažuriranje serverskog softvera.

Šta se zapravo dogodilo

Ranjivosti se nalaze u jezgru PHP-a, a ne u jednoj temi, dodatku ili pojedinačnoj aplikaciji. Prema tehničkom objašnjenju Google Clouda, prva greška povezana je s ponašanjem nakon nedostatka memorije tokom pripreme zahtjeva. Druga uključuje stanje koje može ostati vezano za memoriju nakon završetka zahtjeva. Obje mogu dovesti do oštećenja memorije, curenja podataka ili izvršavanja koda, zavisno od okruženja i načina obrade zahtjeva.

Za običnog vlasnika firme tehnički detalji nisu prvi zadatak. Važnije je razumjeti lanac odgovornosti. WordPress, Drupal, Joomla, Magento i brojne prilagođene aplikacije koriste PHP, ali verziju PHP-a najčešće održava hosting kompanija ili administrator servera. Ažuriranje WordPress jezgra nije isto što i ažuriranje PHP runtimea. Upravo zato prvo pitanje podršci treba biti precizno: koju PHP verziju koristi konkretni produkcijski sajt i kada je primijenjena sigurnosna zakrpa?

Zašto je reakcija hitna

Reuters je 22. oktobra izvijestio da su kompanije za internetsku infrastrukturu zabilježile rast pokušaja iskorištavanja sa hiljada na milione u kratkom periodu. Pokušaj nije dokaz uspješnog upada, ali pokazuje da automatizovani sistemi već pretražuju internet u potrazi za nezaštićenim serverima. Veliki broj pokušaja također znači da mali lokalni sajt nije nevidljiv napadačima. Automatizovani skener ne bira metu prema prometu ili poznatosti brenda.

Američka agencija CISA pozvala je organizacije na hitno zakrpavanje. PHP projekat je još jasniji: nadogradnja je jedini potpuno siguran izbor. Vlasnici starijih sajtova imaju dodatni problem jer ne mogu uvijek preći na novu verziju bez testiranja tema, dodataka i vlastitog koda. Ipak, nekompatibilnost nije razlog da produkcija ostane nezaštićena bez plana. Hosting može napraviti kopiju okruženja, testirati podržanu verziju i odvojiti rizičnu aplikaciju od drugih usluga.

Kontrolni spisak za vlasnika sajta

Prvo zapišite ko upravlja hostingom, domenom, DNS-om, rezervnim kopijama i aplikacijom. U mnogim malim firmama pristupi su rasuti između bivšeg developera, marketing agencije i vlasnika. Sigurnosna situacija je loš trenutak da se tek otkriva ko ima pristup serveru. Potvrdite kontakt odgovorne osobe i tražite pisanu potvrdu primijenjene PHP verzije.

Drugo, napravite provjerenu rezervnu kopiju datoteka i baze podataka prije nadogradnje. Backup koji postoji samo na istom serveru nije dovoljan za ozbiljan incident. Kopija treba biti odvojena, vremenski označena i testirana barem do nivoa da se arhiva može otvoriti i baza prepoznati. Nemojte vraćati staru kopiju samo zato što je nastao problem: i ona može sadržavati ranjivu verziju ili već kompromitovane datoteke.

Treće, primijenite zakrpljenu verziju PHP-a. Za aktivne grane to su 8.5.12, 8.4.27, 8.3.36 i 8.2.35 ili novija podržana izdanja. PHP upozorava da 8.2 krajem 2026. izlazi iz sigurnosne podrške, pa kratkoročna zakrpa ne treba zamijeniti plan prelaska na duže podržanu granu.

Četvrto, ažurirajte aplikaciju, dodatke i teme te uklonite ono što se ne koristi. To ne zatvara samu PHP2Shell grešku, ali smanjuje druge puteve napada. Napušten dodatak, stara administratorska sesija i javno dostupan razvojni panel mogu pretvoriti jedan problem u cijeli lanac kompromitovanja.

Peto, pregledajte web i sistemske logove za period prije i poslije objave ranjivosti. Tražite neuobičajene zahtjeve, nove administratorske naloge, neočekivane zakazane zadatke, promjene datoteka, izvršne datoteke u direktorijima za upload i izlazni saobraćaj prema nepoznatim adresama. Ako nemate stručnu osobu, tražite incidentni pregled od hostinga ili sigurnosnog administratora. Nemojte javno objavljivati logove jer mogu sadržavati IP adrese, tokene i lične podatke.

Šta korisnici mogu, a šta ne mogu uraditi

Posjetilac ne može zakrpiti tuđi server. Za većinu građana najrazumnije je izbjegavati unos osjetljivih podataka na stranici koja se ponaša neobično, koristiti jedinstvene lozinke i uključiti višefaktorsku zaštitu gdje postoji. Ako servis objavi incident, promijenite lozinku na tom servisu i svugdje gdje ste je ponovili. Međutim, nasumična promjena svih lozinki bez informacije o incidentu nije zamjena za rad administratora servera.

Vlasnik sajta također ne treba automatski tvrditi da je bio hakovan. Ispravan redoslijed je: utvrditi izloženost, primijeniti zakrpu, pregledati dokaze i tek zatim saopćiti šta se zna. Ako postoje znakovi neovlaštenog pristupa ličnim podacima, potrebno je uključiti pravnu i sigurnosnu procjenu obaveza prijavljivanja incidenta.

Kako provjeriti hosting bez tehničkog nagađanja

U kontrolnom panelu često postoji prikaz aktivne PHP verzije, ali taj broj može biti drugačiji za pojedine domene ili komandnu liniju. Zato snimak ekrana iz panela nije konačan dokaz. Tražite od hostinga potvrdu verzije za konkretni virtualni host, vrijeme instalacije zakrpe i informaciju jesu li pregledani sigurnosni događaji. Ako koriste upravljanu platformu, pitajte je li nadogradnja automatska ili zahtijeva izbor korisnika.

Korisno je tražiti i odgovor na tri dodatna pitanja: postoje li izolovane kopije backupa, koliko dugo se čuvaju logovi i postoji li plan vraćanja usluge ako se otkrije kompromitovanje. To su pitanja koja vrijede i nakon što PHP2Shell nestane iz naslovnica.

Šira pouka za firme u BiH

Mali poslovni sajt često se tretira kao gotov proizvod koji se plati jednom i zaboravi. U stvarnosti je to stalno aktivan sistem izložen internetu. Održavanje nije samo objava novih fotografija nego upravljanje serverskim verzijama, pristupima, kopijama i nadzorom. Najskuplji trenutak za otkrivanje da nema odgovorne osobe jeste poslije napada.

PHP2Shell zato nije samo priča za developere. To je test osnovne digitalne higijene svake firme koja prima upite, narudžbe, prijave ili dokumente preko weba. Zakrpa je prvi korak. Jasan vlasnik sistema, provjeren backup i redovno održavanje ono su što smanjuje posljedice sljedeće ranjivosti.

Minimalni plan za naredna 24 sata

Ako nemate vlastiti IT tim, otvorite jedan incidentni tiket kod hostinga i u njemu zadržite svu komunikaciju. Tražite četiri odgovora: aktivnu PHP verziju, vrijeme instalacije zakrpe, potvrdu pregleda logova i lokaciju posljednje odvojene rezervne kopije. Odgovor „server je siguran“ bez verzije i vremena nije dovoljan za poslovnu evidenciju.

Nakon nadogradnje testirajte prijavu, kontakt-forme, kupovinu, plaćanje, slanje e-maila i zakazane zadatke. Sigurnosna zakrpa ima prioritet, ali kvar kritičnog procesa treba odmah otkriti. Sačuvajte listu testova i rezultat. Ako se pronađe sumnjiva promjena, nemojte brisati tragove prije kopiranja logova i datoteka za analizu. Izolujte sistem, ograničite pristup i uključite stručnu osobu koja može razlikovati pokušaj napada od uspješnog izvršavanja koda.

Kada se stanje stabilizuje, zapišite rok za sljedeću provjeru i vlasnika zadatka. Jednokratna hitna intervencija bez redovnog procesa ostavlja firmu u istoj poziciji pri narednom kritičnom ažuriranju.