Več kot 500 spletnih strani zaščitenih pred kritičnima ranljivostma PHP

Ko gre za varnost spletnih strani in je varnostna ranljivost javno razkrita, šteje vsaka ura. Ob kritičnih ranljivostih v programskem jeziku PHP, ki sta bili javno razkriti 20. in 21. oktobra, smo spletne strani naših strank zaščitili še pred objavo uradnih popravkov. V naslednjih dveh dneh smo posodobili več kot 500 spletnih strani, spletnih trgovin in spletnih aplikacij ter jih preselili na nove strežnike.

V članku opisujemo, kako je to potekalo, katere odločitve smo sprejeli in zakaj.

Kaj se je zgodilo?

V torek, 20. oktobra 2026, je skupnost, ki razvija PHP, napovedala objavo nujnih popravkov za kritični ranljivosti z oznakama CVE-2026-109618 in CVE-2026-109619. Napadalcu omogočata, da brez gesla izvaja svoje ukaze na ranljivem strežniku. Napaka je v samem jedru jezika PHP, zato zadeva skoraj vse spletne strani, ki tečejo na njem: WordPress, Drupal, Joomla in tudi našo Kabi platformo.

Urad Vlade Republike Slovenije za informacijsko varnost z je 21. oktobra dvignil raven ogroženosti na visoko, zavezancem pa odredil, da sisteme, dostopne z interneta, posodobijo najkasneje v 48 urah. Kasneje se je izkazalo, da so napadalci ranljivost poskušali izkoristiti že 17. oktobra, torej štiri dni, preden so bili varnostni popravki sploh na voljo.

Prvi dan: zaščita še pred uradnimi popravki

Ko smo 21. oktobra prejeli napoved, tehnične podrobnosti še niso bile javno znane. Vedeli smo le, da gre za kritično napako in kdaj bodo popravki izšli. Tisti dan smo naredili tri stvari.

1. Najprej smo pripravili popis vseh strežnikov in projektov: kje teče katera različica PHP, kateri projekti so že na novi infrastrukturi in kateri še na starejši. Ker gostimo in vzdržujemo samo rešitve, ki smo jih razvili sami, smo imeli ta pregled hitro narejen oz. že pripravljen. Kdor gosti stotine različnih sistemov, ki jih ni razvil sam, bi za enak pregled potreboval bistveno več časa.
2. Nato smo omejili delovanje spletnih strani, spletnih trgovin in aplikacij. Najpomembnejši ukrep je bil, da smo onemogočili nalaganje datotek, tako na spletnih straneh kot v zalednem delu aplikacij. Varnostna podjetja so pozneje potrdila, da napadi potekajo prav prek zahtevkov za nalaganje datotek. S tem smo glavno pot napada zaprli, še preden smo poznali vse podrobnosti. Za stranke je to pomenilo nekaj omejitev v delovanju, saj smo tudi v CMS administraciji, CRM-ju, PIM sistemu in ostalih zalednih aplikacijah onemogočili nalaganje slik in dokumentov. Odločili smo se, da je to bistveno manjše tveganje kot odprt strežnik.
3. Ko je bila omejitev že pripravljena smo stranke obvestili, kaj se dogaja, kaj smo že storili in kaj še pripravljamo. Želeli smo, da o težavi najprej izvejo od nas, ne iz novic.

Za novejše projekte smo naredili nadgradnjo že nekaj ur po objavi

Popravki so izšli v sredo, 21. oktobra, ob 16. uri po našem času. Približno 100 projektov, ki smo jih izdelali v zadnjem letu, je že teklo na naši novi infrastrukturi. Pri njih je bila namestitev hitra, zato so bili zaščiteni v eni uri po uradni objavi popravkov.

Drugi in tretji dan: popravki za novejše projekte

Naslednja dva dneva: nova infrastruktura in selitev več kot 500 strani

Pri ostalih projektih je bilo dela bistveno več. Selitev starejših projektov na novo infrastrukturo smo načrtovali že prej, ranljivost pa nas je postavila pred odločitev: stara okolja zakrpati in jih čez nekaj mesecev vseeno seliti ali selitev izvesti takoj. Izbrali smo drugo. Najprej smo pripravili novo strežniško okolje in infrastrukturo, nato pa pričeli s selitvijo.

V dveh dneh smo:

• zaščitili in posodobili na zadnjo različico, ki je uradno podprta, več kot 500 strani, trgovin in aplikacij in jih preselili na nove strežnike,
• selitve izvajali ponoči v četrtek ter v petek pozno popoldne in zvečer, da so stranke čim manj občutile prekinitve.

Veliko dela, ki ga uporabniki ne vidijo

Za takim odzivom na žalost ni enega samega gumba za posodobitev. Vsaka spletna stran ima svoje posebnosti, različne zahteve, povezave iz različnih ERP sistemov in lahko teče na drugi različici PHP. Pri delu starejših strani je bilo treba kodo dodatno prilagoditi, da je delovala na novi različici. Gladka selitev spletnega mesta zahteva natančen načrt, izvedbo in preverjanje, da po posegu vse deluje tako kot prej. Za več kot 500 projektov je to prav poseben izziv.

Pri tem je sodelovala celotna ekipa, od sistemskih administratorjev, razvijalcev in vodij projektov. Ko je treba ukrepati hitro, se pokaže, kako dobro poznaš lastno infrastrukturo. Mi jo poznamo, ker smo jo skozi vsa leta gradili sami.

Kaj smo se naučili?

• Hitrost je odvisna od predpriprave, ne od dneva napada. Popis strežnikov in spletnih strani smo naredili v nekaj urah, ker smo vedeli, kaj teče kje. Brez tega bi prve dragocene ure porabili za iskanje.
• Zaščititi se da tudi pred uradnimi popravki. Začasna omejitev funkcij, kot je nalaganje datotek, ni prijetna, a je zaprla pot napadalcem v času, ko dejanskih popravkov sploh še ni bilo. Prav tako je pomembno imeti dober sistem arhiviranja podatkov v ločenem okolju.
• Zastarelost spletnih strani je dolg, ki ga plačaš v najslabšem trenutku. Projekti na novi infrastrukturi so bili zaščiteni v eni uri, starejši pa so zahtevali dva dni intenzivnega dela. Zato ima smisel spletne strani posodabljati sproti, ne šele takrat, ko je nujno. Naročniki in partnerji se morajo zavedati, da vlaganje v redno posodabljanje spletnih strani preprečuje nepričakovane stroške v prihodnosti.
• Obveščanje je del zaščite. Stranka, ki ve, kaj se dogaja, lažje sprejme začasne omejitve in ne izgublja časa z ugibanjem.
• Vlaganje v razvoj infrastrukture se vedno izplača. V razvoj nove infrastrukture smo v preteklih letih vložili ogromno število ur, ki bi jih lahko namenili razvoju projektov, ki so financirani. Vendar se tudi zaradi takšnih situacij izkaže, da je bila naša odločitev več kot pravilna.

Poleg tega obstajajo ukrepi, s katerimi zaščitite svojo spletno stran ne glede na to, kdo jo gosti in veljajo za vsako podjetje.

Varnost ni enkratno opravilo!

Taki dogodki pokažejo, kako pomembni so redno vzdrževanje infrastrukture, redno posodabljanje spletnih strani, trgovin, aplikacij, spremljanje varnostnih obvestil in sposobnost hitrega odziva. Prav zato je spletna varnost danes vprašanje osnovnega poslovanja podjetja.

V Kabiju bomo še naprej skrbeli, da so spletne strani naših strank varne, posodobljene in pripravljene na nove izzive. To je namen rednega vzdrževanja spletnih strani, ki je pri nas del celotne skrbi za projekt, od izdelave spletne strani do gostovanja.

Če vaše spletne strani ne vzdržujemo mi in niste prepričani, ali je zaščitena, nam pošljite njen naslov. Preverili bomo, na kateri različici PHP teče, in vam povedali, ali je treba kaj storiti. Pri tem vam lahko pomaga tudi nekaj vprašanj, ki si jih zastavite ob izbiri ponudnika spletnega gostovanja. Če želite ostati na tekočem z varnostjo in razvojem spletnih strani, spremljajte naše novice.

Za naše stranke je spletna stran predvsem pomemben prodajni kanal. Naša naloga je, da jim za njeno varnost in delovanje ni treba skrbeti.