Na kratko: Če sumite, da je bil vaš strežnik vdrt prek PHP2Shell, se javite zdaj. Ste prizadeti? Pokličite nas. Pomagamo. Od prvega sporočila prevzamemo zajezitev, zavarujemo sledi, zapremo ranljivost, odstranimo škodljivo kodo in incident dokumentiramo do zaključka.
Zdaj ničesar ne brišite in ničesar ne postavljajte znova. Izbrisane datoteke in prepisani dnevniki so sledi, iz katerih se vidi, ali in kako je kdo vdrl. Strežnik po potrebi odklopite z omrežja, vendar ga pustite nespremenjenega. Prijavite nujni primer, povedali vam bomo naslednji korak.
Ste prizadeti? Znaki, da je bil PHP2Shell že izkoriščen
PHP2Shell je ime za dve kritični ranljivosti v samem PHP-ju, s katerima lahko napadalci brez prijave od daleč izvedejo škodljivo kodo. Nedvoumnega prstnega odtisa doslej ni. Zato šteje, kaj strežnik počne, ne kaj najde skener. Znaki vdora so:
- Procesi spletnega strežnika ali PHP-FPM, ki zaženejo lupino, na primer
shalibash. To je močan opozorilni znak. - Nove ali spremenjene datoteke PHP v mapah za nalaganje, predpomnilnik ali začasne datoteke, ki jih ni ustvaril nihče od vas.
- Opravila cron, storitve ali ključi SSH, ki jih ne poznate.
- Odhodne povezave na neznane cilje, nenadna visoka obremenitev ali nenavaden promet.
- Zahteve v dnevnikih od 17. 10. 2026 naprej, zlasti nenavadna nalaganja in zahteve za seje pred namestitvijo popravka.
- Sporočila ponudnika gostovanja, brskalnika ali iskalnika o spamu, zlonamerni programski opremi ali preusmeritvah.
Več o tem najdete v prispevku Ali sem že ogrožen?. Če ni nobenega znaka, to ni dokaz, da je strežnik čist. Pomeni le, da doslej ni bilo nič opaženo.
Kaj storite takoj
- Ničesar ne spreminjajte. Ne brišite datotek, ne obnavljajte varnostne kopije, ne namestite znova, preden je vse zavarovano.
- Zavarujte dnevnike. Prosite ponudnika gostovanja ali svojo IT-službo, naj ne prepišeta dnevnikov dostopa, napak in sistemskih dnevnikov. Strokovni tisk svetuje hrambo dnevnikov od 20. 10. 2026 naprej.
- Odločite o dosegljivosti. Če bi lahko podatki uhajali ali bi bili obiskovalci ogroženi, spletno stran odklopite ali preklopite v vzdrževalni način.
- Zberite dostope. Zapišite, kdo ima dostop do strežnika, upravljalne plošče, CMS-ja in zbirke podatkov. Gesla zamenjajte šele po dogovoru in z čiste naprave.
- Obvestite ljudi. Vodstvo, pooblaščenca za varstvo podatkov, ob obstoječi polici tudi zavarovalnico.
- Pokličite nas ali nam pišite. Čim prej poznamo stanje, tem več ostane dokazljivega.
Kako konkretno pomaga PHP SOS?
Delamo na daljavo, brez prihoda na kraj, po vsej Nemčiji in Evropi.
- Ocena stanja: Razjasnimo, kateri sistemi tečejo, kateri način delovanja PHP se uporablja, kaj je bilo opaženo in kateri podatki bi lahko bili prizadeti.
- Zavarovanje in zapiranje: Zavarujemo datoteke, zbirko podatkov in dnevnike ter pred vsako spremembo ugotovimo stanje. Nato ranljivost zapremo s popravkom ali, če ta še ni mogoč, s prehodnimi ukrepi, in znova zaženemo vse procese PHP.
- Preverjanje in čiščenje: Iščemo webshelle, stranska vrata, opravila cron in tuje dostope ter jih odstranimo ali pa stanje znova zgradimo iz zaupanja vrednih virov. Postopek opisuje stran Odstranjevanje zlonamerne kode in webshellov.
- Utrjevanje in poročilo: Zamenjamo prizadete skrivnosti, dopolnimo zaščitne ukrepe in dostavimo poročilo, ki ločuje dokazano, verjetno in neznano.
Če incident preraste en strežnik, preidemo v strukturirano odzivanje na incidente. Če so potrebni dokazi, ki obstanejo pred sodiščem, pritegnemo IT-forenziko.
Zakaj popravek po napadu sam ne zadostuje
Ranljivosti ležita v interpreterju PHP, ne v CMS-ju. Projekt PHP je 21. 10. 2026 izdal različice 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Kdor je nato posodobil in znova zagnal vse delavce (worker), je pred novimi napadi po tej poti zaščiten. Kar je napadalec odložil prej, pa ostane: webshell, dodaten račun, načrtovano opravilo. Prav zato so dnevi med 17. in 21. 10. posebej pomembni.
Dodaten vidik: webshell je pogosto šele prvi korak. Kdor je lahko na spletnem strežniku izvajal kodo, je lahko prebral tudi konfiguracijske datoteke in iz njih prevzel dostope do zbirke podatkov, e-pošte in API-jev. Te skrivnosti je treba zamenjati, sicer ostanejo vrata odprta, čeprav je PHP popravljen. Kako smiselno preverite datoteke in časovne točke, opisuje vodnik za prepoznavanje webshellov.
Obveznost prijave in dokumentacija
Če bi bili lahko prizadeti osebni podatki, je lahko potrebna prijava nadzornemu organu v 72 urah. Ura teče od seznanitve, ne od zaključka preiskave. Ali je vaš primer prijavljiv, odločita pooblaščenec za varstvo podatkov ali odvetnik; pravnega svetovanja ne nudimo. Naša dokumentacija za to zagotovi podlago. Več o roku najdete v prispevku Obveznost prijave GDPR v 72 urah, korake po njem pa v kontrolnem seznamu po vdoru.
Kaj nam pošljite
- Opis, kaj je opaženo od kdaj in kdo je to opazil
- Vrsta strežnika: lasten strežnik, upravljani strežnik ali paket gostovanja, skupaj s ponudnikom
- Rezultat ukaza
php -vin, če je znan, način delovanja (PHP-FPM, mod_php, LiteSpeed) - Čas posodobitve PHP, če je že bila izvedena
- Dostop do strežnika ali dovoljenje, da govorimo z vašim ponudnikom gostovanja
- Kontaktna oseba s pooblastilom za odklop in ponovne zagone
Zakaj PHP SOS
Delamo »Made in Germany« in smo s partnerskim omrežjem kibernetskih strokovnjakov že več kot 25 let specializirani za IT-varnost. Imate enega sogovornika, ki vas spremlja od prvega sporočila do zaključka. Vse, kar storimo, je dokumentirano, da lahko to izkažete pred vodstvom, zavarovalnico in organi. Ne obljubljamo ničesar, česar nihče ne more izpolniti: če dnevnikov ni, to odkrito povemo in navedemo, kaj je dokazano in kaj ostaja domneva.
Ste prizadeti? Pokličite nas. Pomagamo.
Ne čakajte, da sum postane gotovost. Pokličite ali pišite po WhatsAppu. Prevzamemo že od prvega sporočila in ostanemo, dokler incident ni zaključen in dokumentiran. Prijavite nujni primer zdaj.
Pogosta vprašanja
Ali zadostuje posodobitev PHP, če je bil moj strežnik morda že vdrt?
Ne. Posodobitev ranljivost zapre, ne odstrani pa že vnesene škodljive programske opreme in ne dokazuje, da prej ni bilo nič narobe. Po popravku je treba strežnik preveriti za sledmi vdora.
Po čem prepoznam uspešen napad PHP2Shell?
Objavljenih, potrjenih indikatorjev ogroženosti (Indicators of Compromise) ni. Prepoznavanje temelji na vedenju: procesi spletnega strežnika, ki zaženejo lupino (shell), nove datoteke PHP v mapah za nalaganje ali predpomnilnik, neznana opravila cron ali ključi SSH ter nenavadne odhodne povezave.
Ali naj strežnik odklopim z omrežja, če sumim vdor?
Pogosto je to prav, saj BSI tudi ob posodobitvi, ki ni takoj mogoča, svetuje začasen odklop spletnega strežnika z omrežja. Pomembno je, da pri tem ničesar ne izbrišete ter ohranite dnevnike in datoteke, da je mogoče incident pojasniti.
Ali moram po napadu PHP2Shell obvestiti organ za varstvo podatkov?
Če bi bili lahko prizadeti osebni podatki, je lahko potrebna prijava v 72 urah. O tem odločite skupaj s pooblaščencem za varstvo podatkov ali odvetnikom; tehnična dejstva za to zagotovimo mi.
Ali so bili strežniki prek PHP2Shell res že vdrti?
Po poročilih medijev so bili prvi poskusi napadov opaženi od 17. 10. 2026, o opaženih poskusih je poročal tudi Cloudflare. BSI sprva ni poročal o potrjenih uspešnih napadih v širšem obsegu. V posameznem primeru je to mogoče razjasniti samo na strežniku.