Imunify360 31. oktobra 2026 odstranil legitimno PHP-kodo? Preverjamo možne lažno pozitivne zaznave
Ali ste 31. oktobra 2026 tudi na svojem strežniku opazili, da je Imunify360 označil ali samodejno očistil PHP-datoteke, čeprav so bile del običajnega delovanja spletnih strani ali internih integracij? Na podlagi konkretnega dogodka odpiramo vprašanje morebitnih lažno pozitivnih zaznav (false positive) in vabimo druge skrbnike strežnikov, da delijo svoje ugotovitve.
Kaj se je zgodilo?
Na enem od produkcijskih strežnikov smo 31. oktobra 2026 med približno 03:27 in 03:50 po slovenskem času zaznali samodejno čiščenje 18 PHP-datotek. Prizadete so bile predvsem prilagojene datoteke WordPressove teme, komunikacija z WHMCS ter avtomatizacija izdajanja e-računov. Ena od spletnih strani je zaradi manjkajoče kode začela vračati napako HTTP 500. Del avtomatizacije je po čiščenju izgubil pomembne programske funkcije.
Zgodovina pregleda Imunify360 je prikazovala status Cleaned in podpise iz družine SMW-INJ-CLOUDAV-php.tool.remote, med drugim NPU2001, NPU2003, NPU2005 in NPU2009.
Zanimiva časovna povezava s posodobitvijo
V strežniškem dnevniku sta bila tik pred dogodkom zabeležena dogodka FilesUpdated({FilesType:wp-rules}) ob 03:26:03 in FilesUpdated({FilesType:php-immunity-v2}) ob 03:26:06. Približno minuto zatem se je začelo samodejno čiščenje. Gre za časovno povezavo, ne za dokončno dokazano vzročno povezavo. Za potrditev napake v zaznavah bi potrebovali pojasnilo razvijalca Imunify360.
Kaj je pokazal pregled datotek?
Pregled obnovljene kode ni razkril očitnih znakov klasične PHP-spletne lupine. Večina označene kode je izvajala znane naloge, kot so povezovanje z API-ji, obdelava PDF-računov in preverjanje razpoložljivosti domen. Pojavljale so se funkcije curl_exec(), base64_decode() in WordPressove HTTP-funkcije, ki so lahko legitimne, hkrati pa jih uporabljajo tudi škodljive skripte. Zato zgolj prisotnost teh funkcij ne dokazuje ne okužbe ne lažno pozitivne zaznave.
Po ciljni obnovi iz varnostne kopije je varnostni sistem nekatere datoteke ponovno samodejno očistil. Šele po uvedbi izjem za točno določene datoteke je obnova obstala. Izključevanje preverjanja mora biti začasno, omejeno in utemeljeno, saj lahko izjema skrije tudi pravo okužbo.
Ali so podobne napake že javno prijavljene?
Na forumu WordPress.org je bil javno opisan primer vtičnika WP Umbrella, pri katerem je Imunify360 po obnovitvi znova odstranil legitimno datoteko. V razpravi je omenjena tudi eskalacija primera specialistom Imunify360. To je ločen primer in ni potrditev, da gre za isto podpisno pravilo ali isti incident.
Vir: WP Umbrella 2.27.0 – Imunify360, WordPress.org.
Kaj priporočamo skrbnikom strežnikov?
Če ste opazili podobno vedenje, najprej preverite zgodovino Imunify360, natančne poti datotek, čas zaznave in podpis pravila. Pred obnovo ohranite kopijo očiščene datoteke in dnevnike, nato primerjajte original z zaupanja vredno varnostno kopijo. Izjem ne dodajajte za celotne spletne mape in ne izklapljajte globalnega pregleda samo zato, da bi ustavili opozorila. Če sumite na napačno zaznavo, jo prijavite podpori CloudLinux oziroma Imunify360, pri tem pa iz dokaznega gradiva odstranite gesla, API-ključe in osebne podatke.
Anketa za skrbnike strežnikov
Ste od 31. oktobra 2026 na strežniku z Imunify360 opazili samodejno čiščenje datotek, za katere sumite, da so bile legitimne?
Oddajte glas v spodnji anketi. Izberete lahko en odgovor.
Možni odgovori v anketi:
- Da, prišlo je do prekinitve delovanja spletne strani ali storitve.
- Da, zaznave so se pojavile, vendar brez opaznega izpada.
- Ne, podobnih težav nisem opazil.
- Imunify360 uporabljam, vendar še nisem preveril dnevnikov.
- Imunify360 ne uporabljam.
Če ste imeli podobno izkušnjo, lahko v komentarjih navedete približen čas, oznako zaznave in vrsto prizadete aplikacije, brez deljenja dostopnih podatkov. Zbrane odzive bomo uporabili za boljšo oceno, ali gre za osamljen primer ali širši pojav.
Posodobljeno: 31. oktober 2026. Vzrok zaznav ob objavi še ni uradno potrjen.
