Varnostna luknja v PHP z dne 21. oktobra: kaj se je zgodilo in kakšno je trenutno stanje

V sredo, 21. oktobra, sta postali znani dve resni varnostni luknji v programskem jeziku PHP, v katerem deluje velika večina vseh spletnih strani, med njimi tudi WordPress. Morda ste to opazili, saj so bile spletne strani pri nas del dneva nedostopne. V tem članku povzemamo, kaj se je zgodilo, kako smo ukrepali in kako je stanje trenutno.

Kaj se je zgodilo?

Luknji (CVE-2026-109618 in CVE-2026-109619) sta nepooblaščenim omogočali izvajanje kode na spletnem strežniku. To je približno najhujša vrsta ranljivosti, ki obstaja: napadalec za to ne potrebuje gesla, ranljivost pa zadeva praktično ves internet.

Kako smo ukrepali

1. Začasni ukrepsreda, 21. oktober, 10:00

   V tistem trenutku je bilo znano le, da sta v vseh različicah PHP prisotni dve resni ranljivosti z oceno CVE 9,2. Podrobnosti še niso bile znane in še ni bilo znanih uspešnih vdorov, čeprav je na primer Cloudflare opažal vedno več poskusov. Ker podrobnosti ranljivosti niso bile znane, nihče ni natančno vedel, za kaj gre in kaj je mogoče storiti za omejitev tveganja. Vendar pa je postajalo znanih vedno več blažilnih ukrepov in možnih dejanj za omejitev tveganja. Te smo vedno takoj izvedli, na primer onemogočanje določenih funkcij PHP in večkratno posodabljanje požarnega zidu.
   Od 10:00 smo tudi neprekinjeno izvajali zelo stroge preglede za zlonamerno programsko opremo, da bi takoj opazili, če bi bil kje na naših strežnikih ali v računih naših strank nameščen skript. Do tega ni prišlo.

2. Spletne strani nedostopnesreda, 21. oktober, 15:15

   Čeprav na naših strežnikih nismo opazili poskusov zlorabe, smo se odločili za najvarnejšo možnost: vse nedostopno. Glavni razlog za to je bil, da smo dvomili o učinkovitosti blažilnih ukrepov (začasnih rešitev), ki so krožili po internetu, saj nihče ni mogel potrditi, da ti zagotavljajo zadostno zaščito.
   V situaciji s toliko nejasnostmi in potencialno ogromnimi posledicami je nekaj ur izpada mogoče zagovarjati, tveganja pa ne.

3. Uradna rešitevsreda, 21. oktober, 16:00

   Razvijalci PHP so izdali uradno posodobitev z odpravo napake za različice 8.3, 8.4 in 8.5. Nato smo čakali na posodobljene pakete podjetja CloudLinux, ponudnika različic PHP na naših strežnikih.
   Ob objavi posodobitve so postale znane tudi podrobnosti ranljivosti, kar je potrdilo naš sum: znani blažilni ukrepi in dodatna pravila požarnega zidu so sicer zmanjšali tveganje za vdor, vendar to ni zadostovalo za zaščito strežnika.

4. Začasna rešitevsreda, 21. oktober, 19:00

   Žal je trajalo precej dlje, kot smo upali in pričakovali, da je CloudLinux pripravil posodobitve. Iz stika z drugimi ponudniki smo ugotovili, da nismo bili edini, ki smo bili presenečeni. Ker smo videli, da so že večkrat zamudili lastne roke, smo medtem pripravljali začasno rešitev.
   Sami smo na vseh naših strežnikih namestili različico PHP 8.3.36 in vse stranke začasno preklopili nanjo. 90 % spletnih strani je bilo med 19:00 in 20:30 spet dostopnih. Edine spletne strani, ki niso postale dostopne, so bile zastarele in niso mogle delovati s sodobno različico PHP.

5. Posodabljanječetrtek, 22. oktober, 00:30

   Posodobitve so postale na voljo in takoj smo začeli z nameščanjem in preverjanjem, strežnik za strežnikom.

6. Odpravljenočetrtek, 22. oktober, 02:30

   Vsi strežniki so bili posodobljeni in vse spletne strani so bile spet dostopne, na isti različici PHP, kot so jo uporabljale prej.

Dobro razumemo, da je neprijetno, če Vaša spletna stran popoldne in zvečer ni dosegljiva. Vendar to nevšečnost ne odtehta morebitnih posledic. Še nikoli prej nismo morali iz previdnosti vsega izklopiti, vendar če bi se enaka situacija ponovno pojavila, bi ravnali povsem enako.

Kako je stanje trenutno?

• Vse različice PHP, ki jih ponujamo, od 5.2 do 8.5, vsebujejo varnostne popravke za obe ranljivosti.
• Nekaj spletnih strani, ki je delovalo na še starejši različici PHP, za katero popravek ne obstaja, smo prestavili na popravljeno različico.
• Strežnike smo med luknjo in po njej preverili glede sledi zlorabe, kot so obtičali procesi PHP, sumljivi procesi, naloženi datoteke in zahteve, ki ustrezajo znanemu napadu. Nismo našli nobenih znakov, da bi bila ranljivost na naših strežnikih izkoriščena, prav tako pred izklopom nismo zaznali poskusov za to.

Je moja spletna stran ločena od spletnih strani drugih?

Da. Vsak gostovalni paket pri nas deluje v lastnem, zaščitenem okolju. PHP deluje pod uporabnikom Vašega paketa, brez skrbniških pravic na strežniku, in nima dostopa do datotek ali podatkovnih baz drugih strank. Tudi uporaba procesorja in pomnilnika je omejena po paketih. Več podrobnosti o naši varnosti namenoma ne razkrivamo javno: manj kot napadalec ve, bolje je.