Kritične ranljivosti PHP (CVE-2026-109618 in CVE-2026-109619): kaj se je zgodilo in kaj storiti

Dne 21. oktobra 2026 je projekt PHP objavil popravke za dve kritični ranljivosti, CERT-EU pa je istega dne izdal varnostno opozorilo 2026-018. Obe sta ocenjeni z 9,2 in obe sta opisani kot oddaljeno izvajanje kode brez prijave. Če upravljate spletišče WordPress, spletno trgovino ali drugo aplikacijo v PHP, to zadeva vas, rešitev pa je posodobitev, ne nastavitev. Ta članek pojasnjuje, kaj je znano, kako napad pride noter in kaj naj storite. Stanje na dan 22. oktobra 2026, po različici 1.1 opozorila CERT-EU.

Kaj se je zgodilo

Projekt PHP je 20. oktobra napovedal varnostno izdajo in popravke objavil 21. oktobra ob 13:30 UTC. CERT-EU je svoje opozorilo naslovil „Critical Vulnerabilities in PHP“ in navaja dva CVE: CVE-2026-109618 in CVE-2026-109619, vsakega z oceno 9,2. CERT-EU poleg tega piše, da se tehnične podrobnosti že javno obravnavajo in da so začeli krožiti prvi vzorčni programi, ki dokazujejo izkoristljivost. Opozorilo ne potrjuje napadov v praksi, pravi pa, da je zaradi tega verjetneje, da napadalci napaki že izkoriščajo. Obravnavajte to kot nujno.

Koga to zadeva

Prizadeta je vsaka različica PHP, starejša od popravljene v podprti veji, in vsaka veja, ki ji je podpora potekla.

CERT-EU navaja PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP in LiteSpeed. Po oceni skupine PHP je tveganje največje pri mod_php. Prizadeti so lahko tudi izdelki, ki vgrajujejo PHP; CERT-EU za to napoti na seznam nizozemskega NCSC na koncu tega članka. Šteje vsaka namestitev, ki streže spletne zahteve, ne glede na to, ali ima obrazec za nalaganje datotek ali ne.

Kako napadalec doseže prvo napako

Nihče se ne mora prijaviti. Po navedbah CERT-EU predstavljen napad kaže, da za sprožitev zadošča ena sama zahteva brez prijave, in to preden se zažene kakršna koli koda aplikacije. To večina spregleda: nepomembno je, ali je vaš WordPress posodobljen, ali so vaši vtičniki popravljeni ali je vaš kontaktni obrazec zaščiten. Zahteva najprej doseže jedro PHP.

Prva napaka, CVE-2026-109618, deluje takole:

1. Zahteva prispe na naslov, ki ga streže PHP. Brez prijave, brez računa.
2. PHP začne brati telo zahteve. CERT-EU kot primer navaja obdelavo nalaganja datotek prek obrazcev.
3. PHP uveljavlja svoj memory_limit z longjmp(). Ko je meja presežena, skoči iz tistega, kar je pravkar počel, in zahtevo konča.
4. Če se to zgodi sredi sestavljanja notranjih podatkov zahteve, so ti podatki sestavljeni le napol.
5. Poznejše čiščenje neveljavne podatke obravnava kot veljavne in sprosti pomnilnik, ki ni bil nikoli inicializiran. Ta pomnilnik lahko še vedno vsebuje podatke iz prejšnjih dodelitev, ki jih je nadzoroval napadalec.
6. Od tam opozorilo opisuje izvajanje kode na strežniku.

Kako napadalec usmerja zadnji korak, namenoma ne opisujemo. Dovolj je vedeti, da vstopna točka ni vaša aplikacija in da ga zato nič znotraj vaše aplikacije ne more ustaviti.

Druga napaka: stanje, ki preživi svoj pomnilnik

CVE-2026-109619 je drug mehanizem z enakim izidom. PHP za vsako zahtevo hrani notranje stanje. Po nekaterih napakah, na primer po usodni napaki, lahko to stanje ostane, čeprav je bil pomnilnik pod njim sproščen. Naslednja zahteva, ki jo obdela isti delovni proces, lahko to zastarelo stanje uporabi, preden se na običajen način ponastavi. Napadalec potrebuje dve zahtevi, ki pristaneta pri istem delovnem procesu; CERT-EU izid ocenjuje enako kot pri prvi napaki: oddaljeno izvajanje kode.

Kaj storiti še danes

1. Ugotovite, katera različica PHP dejansko streže vaše spletišče. php -v v ukazni vrstici pokaže različico ukazne vrstice, ki se lahko razlikuje od različice vašega spletnega strežnika. Preverite php-fpm -v, upravljalno ploščo gostovanja ali stran, ki kliče phpinfo(). Pri souporabi gostovanja vprašajte ponudnika.
2. Posodobite na popravljeno različico: 8.5.12, 8.4.27, 8.3.36 ali 8.2.35. Distribucije popravke pogosto prenesejo nazaj, ne da bi spremenile številko različice; zato poiščite številke CVE v varnostnem obvestilu svojega dobavitelja. V vsebnikih znova zgradite iz posodobljene osnovne slike. Skupina PHP opozarja, da rpms.remirepo.net na dan izdaje še ni imel posodobitev, in priporoča pakete distribucije ali gradnjo iz izvorne kode.
3. Znova zaženite vsak delovni proces PHP. Posodobitev na disku ne spremeni procesov, ki že tečejo. Znova zaženite PHP-FPM ali spletni strežnik in nato še enkrat preverite zagnano različico.
4. Če danes ne morete posodobiti, strežnik ločite od javnih omrežij, dokler popravek ni nameščen in preverjen. CERT-EU jasno pravi, da ti napaki v celoti odpravi le posodobitev.
5. Če uporabljate PHP 8.1 ali starejši, pri dobavitelju zahtevajte povratno preneseni popravek ali preidite na podprto vejo. Te različice ne dobivajo rednih posodobitev.

Ukrepi, ki tveganje zmanjšajo, a napake ne odpravijo

CERT-EU navaja ukrepe, ki napad otežijo. Izrecno pravi, da namestitve ne naredijo varne. Uporabite jih med pripravo posodobitve, ne namesto nje.

• Proti CVE-2026-109618: Nastavite memory_limit=-1 tako, da ga aplikacije ne morejo prepisati, na primer s php_admin_value v bazenu FPM, in preverite, da noben vnos bazena, imenika ali aplikacije spet ne nastavi končne meje. Nastavite nizek post_max_size (8M brez nalaganja datotek, 32M z njim) in upload_max_filesize obdržite pod njim. Omejite velikost zahteve, število polj, dele multipart, število glav in globino gnezdenja na spletnem strežniku ali posredniškem strežniku. Uporabite mejo pomnilnika vsebnika ali cgroup kot mejo razpoložljivosti, ne pa RLIMIT_AS ali RLIMIT_DATA, ki lahko sprožita ranljivo napako pri dodeljevanju pomnilnika.
• Proti CVE-2026-109619: Nastavite session.upload_progress.enabled=0 v php.ini, v bazenu FPM ali v nastavitvi strežnika, ki velja pred obdelavo zahteve (ne z ini_set() ali .user.ini), in znova zaženite vse delovne procese. Pri PHP 8.5 dodatno nastavite fatal_error_backtraces=0. Odstranite neveljavne ali zastarele nastavitve za posamezne zahteve, ki pred inicializacijo izpisujejo diagnostična sporočila, in odpravite usodne napake ter prekoračitve časovne omejitve izvajanja, ki jih lahko napadalec doseže.

Kaj SilentShield tu zmore in česa ne

To ni težava z boti in raje to povemo odkrito, kot da bi izdelčna stran namigovala drugače. Napad zadene jedro PHP, preden zahtevo vidi karkoli od nas ali kateri koli CAPTCHA, vtičnik ali pravilo požarnega zidu znotraj vaše aplikacije. Zaščita pred boti pri obrazcu ga ne ustavi in nihče vam ne bi smel trditi, da ga. Edina popolna rešitev je posodobitev PHP.

API in nadzorna plošča SilentShield nista napisana v PHP. Vtičnik za WordPress in PHP SDK tečeta v vašem lastnem PHP, zato morata biti pri njiju posodobitev opravljena na vašem strežniku. Po posodobitvi je običajna zaščita pred boti in neželenimi sporočili iz obrazcev enako koristna kot prej; le odgovor na to težavo ni bila nikoli.

Viri

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Napoved projekta PHP z dne 20. oktobra 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: izdelki, ki vgrajujejo PHP