Kritične ranljivosti v PHP – posodobite zdaj (CVE-2026-109618 in CVE-2026-109619)

1. oktobra je projekt PHP napovedal varnostno izdajo zaradi dveh kritičnih ranljivosti. 21. oktobra ob 13.30 UTC so bili popravki objavljeni. Obe ranljivosti omogočata neavtentificirano oddaljeno izvajanje kode s CVSS 9,2, javna koda proof-of-concept pa že kroži.

To ni ranljivost, ki bi jo načrtovali v naslednje vzdrževalno okno. To je ranljivost, ki jo odpravite danes.

Na kratko

• Posodobite na PHP 8.5.12, 8.4.27, 8.3.36 ali 8.2.35.
• Prizadet je ves PHP, ki obdeluje spletne zahteve – PHP-FPM, mod_php, php-cgi, FrankenPHP in LiteSpeed.
• Zadostuje ena neavtentificirana zahteva, ki lahko deluje še preden se izvede koda vaše aplikacije.
• Koda PoC je javna. Računajte s širokim skeniranjem v urah, ne tednih.
• Če ne morete popraviti takoj: izolirajte storitve, izpostavljene internetu, dokler popravek ni nameščen in preverjen.

Kaj se je zgodilo

1. oktobra je projekt PHP sporočil, da pripravlja varnostno izdajo. Naslednji dan, 21. oktobra ob 13.30 UTC, so bili popravki objavljeni hkrati v štirih različicah: 8.5.12, 8.4.27, 8.3.36 in 8.2.35. CERT-EU je isti dan izdal varnostno opozorilo in organizacije pozval k takojšnji posodobitvi.

Hitri popravek je dobra stvar. To, da je tehnični opis hkrati postal javen, pomeni, da se čas od »popravek obstaja« do »napadalci poskušajo« meri v urah.

Kaj ranljivosti dejansko počneta

CVE-2026-109618 – poškodba pomnilnika na meji pomnilnika

PHP ustavi zahtevo, ki preseže memory_limit, tako da jo prekine s klicem longjmp(). Prekinitev se torej lahko zgodi sredi notranje operacije, ko so podatki zahteve le delno inicializirani – na primer med razčlenjevanjem nalaganja datoteke v obrazcu.

Čiščenje zahteve lahko nato obravnava neveljavne podatke kot veljavne in sprosti pomnilnik, ki ni bil nikoli inicializiran. V tem pomnilniku so lahko še vedno podatki iz prejšnjih dodelitev, ki jih nadzoruje napadalec. Rezultat je poškodba pomnilnika, ki lahko vodi v izvajanje kode.

CVE-2026-109619 – preostalo globalno stanje

Notranje stanje, ki pripada eni zahtevi, lahko preživi, potem ko je njen pomnilnik sproščen – na primer po kritični napaki. Kasnejša zahteva, ki jo obdela isti delovni proces, lahko uporabi preostalo stanje, preden ga običajna inicializacija uspe ponastaviti.

Nobena ranljivost torej ne zahteva napake v vaši aplikaciji. Nahajata se v samem PHP-jevem obdelovanju zahtev.

Predstavljeni exploit kaže, da lahko ena neavtentificirana zahteva sproži napad, preden se izvede kakršna koli aplikacijska koda.

Kdo je prizadet

Vse namestitve PHP, ki strežejo spletnemu prometu. Ekipa PHP meni, da je mod_php najbolj izpostavljena konfiguracija.

• PHP 8.5 pred 8.5.12
• PHP 8.4 pred 8.4.27
• PHP 8.3 pred 8.3.36
• PHP 8.2 pred 8.2.35
• Opuščene veje (PHP 8.1 in starejše), ki ne prejemajo več rednih posodobitev

Poleg tega: številni komercialni izdelki in izdelki odprte kode uporabljajo PHP v ozadju. Ti so lahko prizadeti, tudi če sami ne upravljate namestitve PHP. NCSC-NL je objavil seznam tretjih programov, v katere je vgrajen PHP.

Najpogostejša napaka, ki jo vidimo: štejejo se samo strežniki, ki ste jih postavili sami. Ne pozabite na vsebnike, slike CI, naprave, notranja orodja in storitve, ki jih upravljajo dobavitelji.

Preverite stanje – pet minut na okolje

1. Zaženite php -v na vsakem gostitelju in v vsakem vsebniku. Ne le na enem.
2. Popišite izvajalna okolja: bazeni PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP, LiteSpeed.
3. Znova zgradite slike vsebnikov – odločilna je osnovna slika, ne delujoča instanca.
4. Vprašajte dobavitelje, ki za vas upravljajo izdelke, odvisne od PHP: katero različico poganjate in kdaj boste posodobljeni?
5. Poiščite opuščene veje. PHP 8.1 in starejše ne dobivajo rednih popravkov.

Odpravite

Paketi distribucije. Linuxove distribucije in ponudniki LTS so imeli popravke že prej. Posodobite prek upravitelja paketov in znova zaženite delovne procese.

Vsebniki. Posodobite osnovno sliko in znova zgradite. Ponovni zagon stare slike ne reši ničesar.

Lastna kompilacija. Posodobite na 8.5.12, 8.4.27, 8.3.36 ali 8.2.35.

Opuščene različice. Ekipa PHP je objavila minimalne backporte za 7.4, 8.0 in 8.1 za tiste, ki gradijo iz izvorne kode ali nimajo ponudnika LTS. Če imate ponudnika LTS: najprej stopite v stik z njim.

rpms.remirepo.net: to prostovoljno vzdrževano skladišče na dan izdaje ne prejme posodobitev. Ekipa PHP uporabnike spodbuja, naj preidejo na pakete distribucije ali gradijo iz izvorne kode.

Po posodobitvi znova zaženite PHP-FPM in druge delovne procese. Nova binarna datoteka brez ponovnega zagona je še vedno stari proces.

Če danes ne morete popraviti

Spodnji ukrepi zmanjšujejo izpostavljenost določenim napadalnim potem. Namestitve ne naredijo varne. Samo posodobitev zapre ranljivost.

Proti CVE-2026-109618:

• Nastavite memory_limit=-1 tako, da aplikacija tega ne more prepisati, na primer php_admin_value v bazenu FPM ali v konfiguraciji Apache. Preverite, da noben bazen, imenik ali nastavitev aplikacije ne vrne omejitve.
• Nastavite nizek post_max_size: 8M za aplikacije brez nalaganja datotek, 32M tam, kjer je nalaganje potrebno. Naj bo upload_max_filesize manjši od post_max_size.
• V spletnem strežniku ali posredniku nastavite omejitve za dekodirano velikost zahteve, število polj, število delov multipart, število glav in globino gnezdenja. Omejitve morajo zajeti tudi zahteve brez uporabnega Content-Length.
• Uporabite pomnilniško omejitev vsebnika ali cgroupa kot omejitev razpoložljivosti, po možnosti s politiko, ki ubije le prizadeti delovni proces. Ne uporabljajte RLIMIT_AS ali RLIMIT_DATA – lahko sprožita ranljivo pot dodeljevanja.

Proti CVE-2026-109619:

• Nastavite session.upload_progress.enabled=0 in znova zaženite vsak delovni proces. Nastavite v php.ini, v bazenu FPM ali v konfiguraciji strežnika, da velja pred razčlenjevanjem zahteve. Ne zanašajte se na ini_set() ali FPM-jev .user.ini.
• V PHP 8.5: nastavite fatal_error_backtraces=0 in znova zaženite vsak delovni proces.
• Odstranite neveljavne ali zastarele nastavitve na ravni zahteve, ki pred inicializacijo oddajajo diagnostiko. Skrivanje diagnostike z error_reporting, display_errors ali @ ne pomaga.
• Popravite kritične napake in časovne omejitve, do katerih lahko doseže napadalec – v povratnih klicih, nalaganju, uvozu in čiščenju.

Zakaj ne kaže čakati

Tri stvari ločijo ta dogodek od običajnega popravka:

1. Avtentikacija ni potrebna. Ni prijave, za katero bi se skrili.
2. Napad se zgodi pred vašo kodo. Logika aplikacije, pravila WAF in model pravic tu niso zaščitna pregrada.
3. PoC je že zunaj. Kar običajno traja tedne, je že naredil nekdo drug.

Cena popravka in ponovnega zagona danes je v primerjavi s ceno vdora zanemarljiva. To še posebej velja, če vas zajema NIS2, kjer je treba o pomembnem incidentu obvestiti v 24 urah.

Po popravku – tri stvari

1. Preverite na vsakem vozlišču. Različico – ne le, da je upravitelj paketov rekel OK.
2. Berite dnevnike vzvratno. Zahteve multipart POST, nepričakovani odgovori 500, sesuti delovni procesi in promet iz neznanih virov v zadnjih dneh.
3. Ob najmanjšem sumu: zaženite incidentni postopek. Izolirajte, zavarujte dnevnike, ocenite obveznost prijave.

Viri

• CERT-EU, Security Advisory 2026-018: https://cert.europa.eu/publications/security-advisories/2026-018/
• PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35: https://www.php.net/
• GHSA-w8hw-w9fx-j79w: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GHSA-6wmf-4rv5-p3rp: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• NCSC-NL, seznam izdelkov z vgrajenim PHP: https://github.com/NCSC-NL/php2shell

---

Takšne ranljivosti so same po sebi argument za neprekinjeno varnost: posodobitve, preverjanje in nadzor, ki potekajo ves čas – ne letni pregled. Preberite več o tem, kaj neprekinjena varnost pomeni v praksi.