Na kratko: Ali naj spletno stran zaradi vrzeli PHP umaknete z omrežja, je odvisno od enega vprašanja: ali PHP na tem strežniku dokazljivo teče na popravljenem stanju in so vsi procesi znova zagnani? Če da, izklop ni potreben. Če posodobitev ni takoj mogoča, BSI priporoča, da se spletni strežnik začasno odstrani z omrežja. Čakanje je upravičeno le, če sistem ne uporablja PHP, ni javno dosegljiv ali je ponudnik popravek pisno potrdil.
Razmere, v katerih morate odločiti
PHP2Shell obsega dve vrzeli v samem PHP, CVE-2026-109618 in CVE-2026-109619, obe ocenjeni s CVSS v4.0 9.2. Omogočata izvajanje škodljive kode na daljavo brez prijave. Popravljene različice so na voljo od 21. 10. 2026: 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Za PHP 8.1 in starejše uradnih posodobitev ni več.
BSI je izdal opozorilno stopnjo oranžno in svetuje takojšnjo posodobitev, nadomestno začasen izklop. Po poročanju medijev so mesto Mainz, službe hessenske deželne vlade in druge javne ustanove spletne strani preventivno umaknile z omrežja; hessenska deželna kancelarija ni javila napada. Kaj lahko podjetja iz tega izpeljejo, je na strani Organi umikajo spletne strani z omrežja.
Za odgovorne v podjetjih je vprašanje bolj praktično: Kaj naredimo z našo trgovino, našim portalom, našo spletno stranjo podjetja, danes?
Spletno stran umakniti, popraviti ali počakati: tri možnosti v primerjavi
Naslednja tabela postavlja možnosti ena ob drugo. Ne nadomešča ocene vašega posameznega primera, a naredi tehtanje vidno.
| Merilo | Takoj popraviti | Začasno izklopiti | Počakati |
|---|---|---|---|
| Zaščita pred PHP2Shell | Visoka, če sta popravek in ponovni zagon dokazana | Visoka za čas izklopa | Nobena, dokler ni popravljeno |
| Prekinitev delovanja | Kratka, za posodobitev in ponovni zagon | Ure do dnevi | Nobena |
| Predpogoj | Podprta različica PHP, dostop, vzdrževalno okno | Odločitev uprave, statična nadomestna stran | Dokazan razlog, zakaj tveganja ni |
| Napor | Majhen do srednji | Tehnično majhen, organizacijsko velik | Majhen, a napor za preverjanje dokaza |
| Značilen primer | Strežnik s PHP 8.2 do 8.5 | Stari sistem s PHP 8.1 ali starejšim, nejasno stanje | Sistem brez PHP ali samo notranje dosegljiv |
| Preostalo tveganje | Prejšnji vdor ostane mogoč | Prejšnji vdor ostane mogoč | V celoti prisotno |
Ena vrstica si zasluži pozornost: ne popravek ne izklop ne razjasnita, ali se je prej že kaj zgodilo. Po poročanju medijev je bil prvi opaženi poskus napada 17. 10. 2026, torej pred popravkom. Pogled na možne sledi zato sodi k vsaki možnosti.
V petih vprašanjih do odločitve
Vprašanja obdelajte po vrsti. Prvi jasen odgovor običajno vodi do odločitve.
- Ali na sistemu sploh teče PHP in je dosegljiv z interneta? Če ne, PHP2Shell sistema neposredno ne zadeva. Dokumentirajte, kako ste to ugotovili.
- Ali je stanje popravkov dokazano? Dokazano pomeni: popravljena različica ali prenos popravka (backport) s številkami CVE v dnevniku sprememb paketa in ponovni zagon vseh procesov PHP. Prikaz različice v plošči ne zadošča. Kako to preverite, je na strani Pravilno preverjanje različice PHP in stanja popravkov.
- Ali je posodobitev mogoče namestiti v naslednjih urah? Če da: popraviti, znova zagnati, preveriti. Do takrat lahko pomagajo prehodni ukrepi.
- Ali to ni mogoče, na primer zaradi PHP 8.1 ali manjkajočega dostopa? Tedaj je po BSI pot začasen izklop. Prehodni ukrepi po php.net tveganje zmanjšajo, a ne zaščitijo v celoti; podrobnosti so na strani Takojšnji ukrepi, če popravljanje še ni mogoče.
- Ali obstajajo znaki ogrozitve? Tedaj vprašanje ni več »popraviti ali izklopiti«, ampak »obravnavati incident«. Izklopiti, zavarovati dokaze, ne brisati prenagljeno.
Če izklopite: izklopite pravilno
Izklop naj odstrani napadalno površino, ne le skrije začetne strani. Vzdrževalna stran, ki jo še naprej ustvarja PHP, tega namena ne izpolni. Boljša je statična stran HTML, ki jo spletni strežnik streže brez PHP, ali preusmeritev na drug strežnik.
Pomislite na vse, kar visi na istem PHP: podstrani, vmesniki za aplikacije ali blagovno poslovanje, skrbniška področja, povratni klici plačil. Če je prizadeta trgovina, se vnaprej pogovorite z ponudnikom plačil in logistiko. In zaposlene ter stranke obvestite v jasnih besedah: stran je preventivno brez povezave, stik poteka po telefonu in e-pošti. To je bolje kot molk, ki hrani ugibanja.
Pomemben je tudi konec izklopa. Določite, pod katerim pogojem je stran spet na spletu, na primer »PHP na popravljenem stanju, ponovni zagon preverjen, prvi pregled sledi brez ugotovitev«. Tako iz zasilne zavore nastane urejen postopek.
Izklop ni poraz. Več javnih služb je po poročanju medijev storilo prav to, ne da bi obstajal napad. Preventivni izklop samodejno ne pomeni, da je bila spletna stran vdrta.
Kdaj ponudnika ne potrebujete
Vsaka odločitev ne zahteva zunanje pomoči. Če je vaša spletna stran pri ponudniku gostovanja, ki stanje popravkov in ponovni zagon pisno potrdi, in ni nenavadnosti, ste z kratko dokumentacijo dobro postavljeni. Enako velja, če lahko vaša lastna IT strežnik z podprto različico PHP popravi sama in obvlada kontrolo.
Pomoč se splača, če tečejo sistemi s staro različico PHP, je stanje nejasno, je prizadetih več strežnikov ali obstajajo znaki vdora.
Kako PHP SOS pomaga konkretno?
- V kratkem času z vami razjasnimo, kateri sistemi so prizadeti in katero stanje popravkov je dokazano.
- Vodstvu dostavimo podlago za odločitev na eni strani: možnosti, tveganja, priporočena pot.
- Izbrano pot izvedemo, torej popravek s ponovnim zagonom, prehodne ukrepe ali čist izklop s statično nadomestno stranjo, v okviru naše takojšnje pomoči pri PHP2Shell.
- Preverimo sledi od 17. 10. 2026 in rezultat dokumentiramo.
Sklep
Popravljanje je običajni primer, izklop prava zasilna zavora, čakanje je upravičeno samo z dokazilom. Kdor pošteno odgovori na pet vprašanj in odločitev pisno zabeleži, ravna v duhu priporočila BSI in lahko pozneje pokaže, zakaj.
Pogosta vprašanja
Ali moram svojo spletno stran zaradi PHP2Shell umakniti z omrežja?
Ne, če PHP že teče na popravljenem stanju in so vsi procesi znova zagnani. BSI priporoča začasni izklop za primer, da takojšnja posodobitev ni mogoča.
Kaj stane več, izklop: promet ali tveganje?
Na to je mogoče odgovoriti samo v posameznem primeru. Izpad nekaj ur je običajno bolje načrtljiv kot vdor, katerega posledic in trajanja nihče ne pozna. Tehtanje zabeležite pisno, ne glede na izid.
Ali sme vzdrževalna stran teči prek istega strežnika?
Da, če se streže kot statična datoteka brez PHP. Če vzdrževalno stran še naprej ustvarja PHP, napadalna površina ostane.
Ali je čakanje kdaj prava izbira?
Da, v jasno opredeljenih primerih: če na sistemu ne teče PHP, če ni dosegljiv z interneta ali če je ponudnik popravek in ponovni zagon pisno potrdil. Čakanje brez takih dokazil ni možnost, ampak tveganje.
Kdo naj sprejme odločitev?
Oseba, ki odgovarja za poslovno tveganje, praviloma uprava ali lastnik. IT dostavi dejstva. Kdo odloča, bi moralo biti vnaprej zapisano v načrtu za nujne primere.