Dvije kritične ranjivosti u PHP-u, CVE-2026-109618 i CVE-2026-109619, natjerale su vlasnike web-sustava na hitne nadogradnje jer napadaču bez korisničkog računa mogu omogućiti izvršavanje vlastitog koda na poslužitelju. PHP projekt objavio je ispravke u verzijama 8.5.12, 8.4.27, 8.3.36 i 8.2.35, a sustavi koji ih ne mogu uvesti trebali bi se privremeno ukloniti s interneta.
Ranjivosti su dobile zajednički naziv PHP2Shell i ocjenu 9,2 od deset. Prva se oslanja na oštećenje memorije pri obradi pogreške zbog nedostatka memorije, a druga na stanje koje ostaje povezano s već oslobođenom memorijom. U oba slučaja posebno oblikovan web-zahtjev može pokrenuti napad prije nego što aplikacijska logika stigne provjeriti korisnika.
Najveći rizik PHP projekt vidi kod Apacheova mod_php načina rada, ali ugroženi su i PHP-FPM, php-cgi, FrankenPHP i LiteSpeed. To proširuje problem izvan pojedinačne aplikacije ili dodatka. Zakrpa WordPressa, Drupala ili Joomle nije dovoljna ako temeljni PHP-ovo izvršno okruženje ostane ranjiv.
Dodatni problem predstavljaju verzije 8.1 i starije koje više nemaju redovnu podršku. Dio Linux distribucija i komercijalnih dobavljača objavljuje vlastite povratne zakrpe, no administrator mora provjeriti datum i izvor paketa, a ne samo broj verzije. Sustav može izgledati zastarjelo, a biti zakrpan, ili obrnuto.
CISA je organizacijama preporučila da najprije popišu sve PHP instance, daju prednost javno dostupnim sustavima i prate PHP procese koji pokreću ljuske ili preuzimaju alate. Popis je važan jer se PHP često nalazi unutar gotovih uređaja, kontejnera i administracijskih sučelja koja nisu vidljiva u standardnom registru aplikacija.
Tržišna posljedica nije samo trošak hitnog rada. Organizacije moraju provjeriti jesu li napadači ušli prije zakrpe, jer nadogradnja ne uklanja već postavljenu zlonamjernu web-ljusku ili novi korisnički račun. Pregled zapisnika, neočekivanih procesa, novih datoteka i izlaznih veza zato mora pratiti tehničko krpanje.
Incident je ponovno otvorio pitanje financiranja otvorenog koda. Kritične komponente koriste milijuni komercijalnih sustava, dok ih često održava mali broj ljudi i ograničen proračun. Dobavljači hostinga, CMS platforme i veliki korisnici mogu smanjiti rizik izravnim financiranjem, testiranjem i ranom distribucijom zakrpa.
Novi sigurnosni detalji objavljeni nakon prvih zakrpa uključuju CVE-2026-115560, ranjivost koja traži neuobičajenu kombinaciju postavki i aplikacijskog ponašanja. Za nju u trenutku provjere nije bilo pune zakrpe, a preporučena privremena mjera bila je isključivanje funkcije praćenja napretka prijenosa datoteka u sesiji.
Za uprave je pouka operativna: inventar osnovnih komponenti i rok za uvođenje kritične zakrpe moraju biti mjerljivi. Dobavljač aplikacije treba dokazati koju PHP verziju koristi, tko prati objave i koliko brzo isporučuje popravak. Sljedeći provjerljivi korak bit će nova PHP zakrpa za treću ranjivost i objava opsega potvrđenih kompromitacija.
Dobavljači hostinga mogu ubrzati sanaciju automatskim popisom verzija i kontroliranim ponovnim pokretanjem servisa. Ipak, automatizacija ne smije zatvoriti incident prije pregleda kompromitacije. Klijent treba dobiti dokaz o instaliranoj zakrpi, vremenu promjene i nalazima iz zapisnika, a ne samo poruku da je održavanje završeno.
Osiguravatelji i revizori vjerojatno će tražiti dokaz o inventaru, vremenu zakrpe i pregledu prethodnih aktivnosti. Tvrtka koja ne zna gdje se PHP nalazi teško može dokazati da je reagirala u razumnom roku. Nabava zato treba ugovoriti obvezu dobavljača da prijavi ugrađene komponente i kritične ranjivosti bez čekanja na upit kupca.
Web-aplikacijski vatrozid može privremeno blokirati dio obrazaca napada, ali nije potpuna zamjena za zakrpu. Ranjivost se nalazi ispod poslovne aplikacije, a novi način iskorištavanja može zaobići početno pravilo. Organizacija koja se oslanja na WAF mora ograničiti trajanje iznimke i unaprijed odrediti datum nadogradnje.
