PHP2Shell, šesti dan: strežnik je posodobljen. Kaj pa vse drugo?

Sreda. Zjutraj SI-CERT opozori na dve kritični ranljivosti, URSIV zviša oceno kibernetske ogroženosti na visoko, ob štirih popoldne izidejo popravki. Sledi noč, v kateri posodabljate strežnike, ugašate storitve in vmes vodstvu razlagate, zakaj spletna stran ne deluje. V četrtek zjutraj pride vprašanje, na katero nihče ne odgovarja rad: »Ali smo ranljivi?«

Danes, v ponedeljek, je ekipa PHP uro pred tem zapisom objavila nove pakete za Windows. Spet posodobitev, tokrat zaradi ranljivosti v knjižnici, ki je priložena paketu. Če ste imeli ta teden občutek, da ves čas le tečete za dogodki, to ni bila vaša napaka. Štirje dnevi od napovedi do prvih uspešnih napadov niso udoben urnik za nikogar.

• Torek, 20. oktobra. Varnostna ekipa PHP napove izdajo popravkov za dve kritični ranljivosti, obe z oceno CVSS 4.0 9,2. Podrobnosti obljubi šele ob izdaji.
• Sreda, 21. oktobra. SI-CERT priporoči takojšnjo namestitev popravkov na vseh prizadetih sistemih. URSIV zviša oceno ogroženosti na visoko, za zavezance po zakonu o informacijski varnosti in za vse druge, ki uporabljajo PHP, ter napove pisno odredbo z nujnimi ukrepi. Ob 16. uri izidejo PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Razvijalci so jasni: popolnega začasnega ukrepa ni, edina varna izbira je posodobitev. V Nemčiji BSI razglasi oranžno stopnjo opozorila, mesto Mainz pa preventivno ugasne svoj spletni portal.
• Petek, 23. oktobra. PHP dodatno svetuje nastavitev session.upload_progress.enabled=0 do naslednje redne izdaje. Censys v Nemčiji, kjer ima marsikateri slovenski dobavitelj svoje naročnike, našteje okoli 4,2 milijona storitev, ki sporočajo ranljivo različico PHP.
• Konec tedna. Na vabah, torej strežnikih, ki so namenoma postavljeni kot ranljivi (t. i. honeypotih), so zabeleženi prvi uspešni napadi, in sicer na PHP 8.4.26.
• Ponedeljek, 26. oktobra. Novi paketi za Windows z oznako -1, na primer 8.5.12-1. Odpravljajo ranljivost v dekodirniku Brotli (CVE-2026-111497). Ta je dosegljiva prek razširitve cURL, če aplikacija vklopi samodejno razširjanje stisnjenih odgovorov. Različica PHP ostane ista.

Namestiti posodobitev je bil lažji del. Težje je biti prepričan, da je prišla povsod. Pet mest, kjer se v takem tednu lahko zatakne:

Številka različice še ne pove, ali je popravek nameščen. Debian, Ubuntu in Red Hat popravke vgradijo v svoje pakete. Različica PHP pri tem pogosto ostane enaka, spremeni se le revizija paketa. V Windows ima ista različica PHP od danes pripono -1. Skener, ki bere številke različic, zato kot ranljive javi tudi posodobljene strežnike. In obratno: prava številka v glavi odgovora še ne pomeni, da paket vsebuje zadnji popravek. Merodajen je dnevnik sprememb paketa.

Posodobitev začne delovati šele v novem procesu. Skupine procesov PHP-FPM, delovni procesi FastCGI, vsebniki: kar je bilo zagnano pred posodobitvijo, teče s staro kodo, dokler se ne zažene znova. To velja tudi za procese, na katere nihče več ne pomisli, na primer za preizkusni strežnik, ki že tedne teče na razvijalčevem računalniku.

PHP teče tudi tam, kjer nihče ne reče »PHP«. V spletnem vmesniku požarnega zidu, na omrežnem disku, v Nextcloudu, v intranetnem wikiju, v vsebniški sliki (angl. container image) z lastnim PHP-jem. Pri napravah boste morali počakati na popravek proizvajalca, do takrat pa vmesnik umaknite z interneta. Pri vsebnikih ni dovolj posodobiti gostitelja: sliko je treba zgraditi znova.

Strežnik upravlja ponudnik, tveganje nosite vi. Če vaša spletna stran gostuje pri ponudniku, popravka ne namestite sami. Pisno vprašajte, na kateri različici teče vaše okolje in od kdaj. Odgovor z datumom je vreden več kot »delamo na tem« na strani s stanjem storitev.

Stare veje nove izdaje ne dobijo. Za PHP 8.1 in starejše uradne različice ni. Ekipa PHP je za 7.4, 8.0 in 8.1 objavila minimalne popravke izvorne kode, kar pomaga tistim, ki PHP prevajajo sami. Vsi drugi so odvisni od distributerja, ponudnika dolgoročne podpore ali od nadgradnje, ki je verjetno že dolgo na seznamu. Naslednji rok je že znan: PHP 8.2 po 31. decembru 2026 ne bo več dobival varnostnih popravkov.

Kdor lahko izvaja kodo s pravicami spletnega strežnika, prebere tudi vse, kar sme brati strežnik: dostopne podatke za bazo v konfiguracijski datoteki, ključe API, gesla za SMTP. Zato preverite, preden zaprete poglavje. Sesuti delovni procesi v dnevniku dogodkov, datoteke PHP tam, kjer jih ne bi smelo biti, sejne datoteke s tujo vsebino: če najdete kaj od tega, te dostope zamenjajte.

Zapišite si tudi, kdaj ste posodobili kateri sistem. Zavezanci po zakonu o informacijski varnosti bodo dokazila potrebovali zaradi napovedane odredbe URSIV, nemški naročniki pa lahko isto vprašajo že v naslednjem varnostnem vprašalniku. Sproti voden seznam s časovnimi žigi pošljete takoj. Za nazaj ga je treba sestaviti iz dnevnikov, zahtevkov in spomina.

Tistim, ki so v četrtek želeli kaj urediti prek spleta, se je zdelo tako. In res: ugasnjena storitev je izpad, ki ga morate razložiti strankam. Ugasnjena spletna trgovina izgublja promet, zahvale pa ni, če se na koncu ne zgodi nič.

Račun je kljub temu jasen. Nekaj ur mirovanja stane manj kot strežnik, ki ga je prevzel nekdo drug. Na forumu Slo-Tech je nekdo to povedal krajše: »Jasno da boš najprej dal kritične zadeve offline, da si kupiš čas.«

Kdor je ugasnil, si je res kupil čas. Drago postane tam, kjer ta čas ne zadošča, ker nihče ne ve, kje vse teče PHP.

Posodobitev je hitra, ko je jasno, kje. Čas vzame iskanje. Pet vprašanj, na katera lahko odgovorite zdaj, ko je teden še svež:

• Kje pri nas teče PHP: na strežnikih, v napravah, v vsebnikih, pri ponudniku gostovanja?
• Kdo je odgovoren za vsako od teh mest, z imenom in namestnikom?
• Kako ugotovimo, ali je popravek res nameščen: različica paketa, oznaka gradnje, ponovni zagon?
• Kako hitro popravek dostavita proizvajalec in ponudnik gostovanja, in ali imamo to pisno?
• Katera veja bo naslednja ostala brez podpore in kdaj načrtujemo prehod?

Če znate odgovoriti na ta vprašanja, bo naslednja zvišana ocena ogroženosti za vas dolg delovni dan, ne pa noč brez konca.

Najtrdovratnejše so aplikacije, ki so obtičale na stari veji, ker bi jih nadgradnja pokvarila. To ni težava PHP-ja, ampak težava podedovanih sistemov, in enako zadeva Access, Delphi ali .NET. Kako velika je pri vas, na prvi pogled pokaže pregled podedovanih sistemov: deset vprašanj, tri minute, vaši odgovori se ne shranjujejo. Kako poslovno kritične aplikacije razvijamo naprej, namesto da bi jih pisali na novo, preberite na strani o posodobitvi podedovanih aplikacij.

Če dobavljate nemškim naročnikom, se vprašanje o PHP2Shell lahko pojavi že v naslednjem vprašalniku. Kako se nanj pripraviti, smo opisali v članku Nemški varnostni vprašalnik: trenutek, ko marketing sreča realnost.

Dogovorite se za pogovor, če katera od vaših aplikacij ne drži več koraka s časom in bi radi vedeli, katere poti so na voljo.

Viri (stanje 26. 10. 2026, ob 15. uri): varnostna ekipa PHP, napoved z 20. 10., varnostno obvestilo in izdaje z 21. 10., obvestilo o napredku nalaganja v seji s 23. 10., posodobljeni paketi za Windows s 26. 10. (php.net); SI-CERT, obvestilo SI-CERT 2026-07, 21. 10. 2026; URSIV, ocena kibernetske ogroženosti z 21. 10. 2026, po poročanju Portala24; BSI, opozorilo »PHP – Kritische Schwachstellen bedrohen Webanwendungen weltweit«, različica 1.1; ZDFheute, 21. 10. 2026; Censys, php2shell.censys.com, stanje 23. 10. 2026. Navedek je iz komentarjev pod novico »Huda ranljivost v PHP-ju terja takojšnjo posodobitev, nekaj strani preventivno ugasnili«, Slo-Tech, 21. 10. 2026.