PHP projekt objavio je verzije 8.5.12, 8.4.27, 8.3.36 i 8.2.35 koje zatvaraju dvije kritične ranjivosti za udaljeno izvršavanje koda bez autentifikacije. Propusti CVE-2026-109618 i CVE-2026-109619 ocijenjeni su s 9,2 prema ljestvici CVSS 4.0. Dok su zakrpe izlazile, sigurnosne tvrtke bilježile su pokušaje iskorištavanja, a državne i javne organizacije u Europi privremeno su gasile web-sustave kako bi smanjile izloženost.
Ranjivosti su godinama postojale u kodu, a pronađene su uz pomoć naprednih AI alata. Istraživači su koordinirali popravak s održavateljima PHP-a, pružateljima zaštite i velikim tehnološkim kompanijama. Problem je eskalirao kada su informacije o izmijenjenim binarnim paketima postale dostupne prije dogovorenog roka, čime je napadačima otvorena mogućnost da usporedbom verzija rekonstruiraju ranjivi dio.
Amazonov sigurnosni tim zabilježio je pokušaj iskorištavanja na mamcu nekoliko dana prije javne objave, a poslije su se pojavili dodatni pokušaji iz više izvora. Nije potvrđeno da je svaki pokušaj mogao uspjeti protiv stvarnog poslužitelja, no nakon objave zakrpe napadači mogu automatizirati usporedbu starog i novog koda. Vrijeme između dostupnosti ispravka i njegove instalacije zato postaje najopasniji dio incidenta.
PHP pokreće približno 75 posto web-stranica kojima je moguće prepoznati poslužiteljski programski jezik. Među njima su sustavi temeljeni na WordPressu, Drupalu i Joomli, prilagođene poslovne aplikacije te javni portali. Usluge hostinga mogu zakrpu primijeniti središnje, dok organizacije na vlastitim ili dijeljenim poslužiteljima ovise o administratoru i rasporedu pružatelja hostinga.
Nizozemske, finske, francuske i danske institucije gasile su pojedine javne servise kao mjeru opreza. Takva odluka stvara vidljiv prekid, ali može biti sigurnija od nastavka rada sustava kojem prijeti preuzimanje. Odgovorna procjena mora uzeti u obzir osjetljivost podataka, dostupnost zakrpe, mogućnost privremene izolacije i sposobnost tima da prepozna već provedeni napad.
Samo instaliranje paketa nije dovoljno. Administrator mora provjeriti koju verziju koristi web-poslužitelj, ponovno pokrenuti PHP-FPM ili Apache kako stari proces ne bi ostao u memoriji te potvrditi verziju na stvarnom produkcijskom zahtjevu. Nakon toga treba pregledati zapisnike, novostvorene datoteke, promjene računa i neuobičajene odlazne veze, jer zakrpa ne uklanja pristup koji je napadač već uspostavio.
PHP 8.2 doseže kraj podrške krajem godine, a još starije grane nemaju službene sigurnosne popravke. Organizacije koje na njima drže kritične aplikacije sada moraju birati između ubrzane migracije i privremene izolacije. Web-aplikacijski vatrozid može smanjiti dio rizika, ali ne zamjenjuje ispravljeni interpreter kada propust omogućuje izvršavanje koda na poslužitelju.
Zakrpe su dostupne, pokušaji iskorištavanja zabilježeni su, a pojedini javni sustavi već su preventivno isključeni. Prioritet je sada dokazati da su sve aktivne instance nadograđene i pregledane. Vlasnici web-sustava trebaju od pružatelja hostinga zatražiti pisanu potvrdu verzije i vremena nadogradnje. Vanjski dobavljač smanjuje operativni posao, ali ne prenosi odgovornost za osobne podatke i kontinuitet. Ako potvrda nije dostupna, organizacija mora tretirati servis kao potencijalno ranjiv i ograničiti mu pristup dok ne dobije dokaz.