Na kratko: Za varnostno ranljivost PHP 8.1, PHP2Shell, uradne posodobitve ni. Projekt PHP za 7.4, 8.0 in 8.1 dobavlja samo minimalne backporte izvorne kode, ne gotovih izdaj. Kdor upravlja te različice, potrebuje potrjen backport svojega ponudnika ali vmesne ukrepe in naj prehod na podprto različico načrtuje zdaj.
Ali obstaja posodobitev proti ranljivosti PHP 8.1?
Ne od projekta PHP. 21. oktobra 2026 so izšli uradni popravki samo za podprte veje: 8.5.12, 8.4.27, 8.3.36 in 8.2.35. PHP 8.1 in starejše različice uradnih posodobitev ne prejemajo več.
Kljub temu so prizadete. Po poročilih strokovnega tiska ranljive različice segajo skoraj nepretrgoma nazaj do PHP 5.4. Kdor javno dostopno upravlja eno od teh različic, ima torej kritično ranljivost z oceno CVSS v4.0 9,2 brez gotovega popravka.
Za številna podjetja je to presenečenje, saj takšni sistemi pogosto leta stabilno in neopazno tečejo. Da različica ne prejema več posodobitev, v vsakdanu ni opaziti, dokler se ne pojavi ranljivost, kot je PHP2Shell. Backporti izvorne kode za 7.4, 8.0 in 8.1 so izjema in ne ponovna vzpostavitev rednega vzdrževanja.
Kaj pomenijo backporti izvorne kode
Za 7.4, 8.0 in 8.1 obstajajo minimalni backporti izvorne kode. To so popravki v izvorni kodi, preneseni na te starejše veje. Niso uradna izdaja s številko različice, preizkušenim paketom in dnevnikom sprememb.
V praksi to pomeni: nekdo mora backport prevzeti, iz njega PHP znova zgraditi, preizkusiti in namestiti. To se lahko zgodi na tri načine:
- Vaša distribucija popravek prevzame v svoje pakete, na primer v okviru dolgoročnega vzdrževanja.
- Vaš ponudnik gostovanja gradi lastne pakete PHP in backport namesti.
- Vi sami ali izvajalec gradite PHP iz izvorne kode. To je zahtevno in se mora ponoviti ob vsaki nadaljnji ranljivosti.
Ali je vaš sistem backport prejel, preverite v dnevniku sprememb paketa:
apt changelog php8.1-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # Debian/Ubuntu
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # družina RHEL
Imena paketov se po distribuciji in paketnem viru razlikujejo. Če vnosa ni, vprašajte ponudnika. Kako pregled poteka podrobno, piše na strani Pravilno preverjanje različice PHP in stanja popravkov.
Stari strežnik zavarovati do selitve
Dokler ne teče potrjen backport, veljajo vmesni ukrepi php.net: neprepisljiv memory_limit=-1 z omejitvijo pomnilnika prek cgroup, post_max_size 8M ali 32M z upload_max_filesize pod tem in session.upload_progress.enabled=0 v konfiguraciji strežnika, nato ponovni zagon vseh workerjev. Niso popolna zaščita. Podrobnosti na strani Takojšnji ukrepi, če še ne morete popraviti.
Zraven sodijo ukrepi, ki zmanjšajo dosegljivost: skrbniška območja samo prek VPN ali odobrenih naslovov IP, nepotrebne spletne strani izklopiti, dostope do strežnika tesno omejiti. BSI priporoča, da se strežniki brez posodobitve začasno odklopijo z omrežja. Za staro, težko selivo aplikacijo je lahko izolirana rešitev bolj poštena kot obratovanje v odprtem internetu.
Če je strežnik s PHP 8.1 ali starejšim od 17. oktobra dalje nezaščiten tekel na omrežju, to vzemite resno: BSI je računal na hitro obsežno izkoriščanje. Zavarujte dnevnike od 20. oktobra dalje in strežnik dajte pregledati glede sledi, preden selite.
Načrtovanje selitve: na katero različico?
Cilj je različica, ki jo projekt PHP podpira in jo vaša aplikacija prenese. PHP 8.2 ranljivost zapre od 8.2.35, doseže pa konec podpore 31. 12. 2026. Kdor zdaj seli, naj zato po možnosti izbere 8.3 ali novejši, če aplikacija to dopušča. Aktualno stanje navaja php.net na strani podprtih različic.
Katero različico PHP podpira vaš CMS ali trgovina, preverite po sistemskih zahtevah proizvajalca, na primer na wordpress.org, shopware.com ali typo3.org. Pogosto je treba najprej posodobiti sam aplikacijo, preden lahko PHP zamenjate. Tipičen primer so starejše trgovine, ki jih opisujemo na strani Shopware 5. Ozadje o posledicah zastarelih različic najdete na strani PHP End of Life: tveganja zastarelih različic.
| Korak | Vsebina |
|---|---|
| Stanje | različica PHP, aplikacija, razširitve, lastne prilagoditve |
| Zahteve | podprte različice PHP po proizvajalcu |
| Testno okolje | kopija z novo različico PHP, analiza dnevnika napak |
| Preklop | načrtovano okno vzdrževanja, pripravljena pot nazaj |
| Dodelava | preveriti vmesne vrednosti, vzpostaviti nadzor |
Kako konkretno pomaga PHP SOS?
S selitvijo s PHP 8.1 in starejšega vas vodimo od stare različice do podprte:
- Takoj zavarovati: preveriti stanje backportov, uvesti vmesne ukrepe, zmanjšati dosegljivost.
- Preveriti sledi: zavarovati dnevnike od 20. oktobra dalje in jih analizirati glede nepravilnosti.
- Pripraviti selitev: razjasniti združljivost po proizvajalcu, postaviti testno okolje, odpraviti napake.
- Preklopiti in dokazati: namestiti novo različico PHP, znova zagnati vse procese, dokumentirati stanje.
Pogosta vprašanja
Ali je PHP 8.1 prizadet zaradi PHP2Shell?
Po poročilih strokovnega tiska so prizadete skoraj vse različice nazaj do PHP 5.4, vključno s PHP 8.1. Projekt PHP za 8.1 ne objavlja več uradnih posodobitev, samo minimalne backporte izvorne kode.
Kaj je backport izvorne kode?
Popravek v izvorni kodi, prenesen na starejšo vejo različic. Ni gotova izdaja: nekdo ga mora prevzeti, PHP znova zgraditi, preizkusiti in namestiti. To lahko prevzame ponudnik vaše distribucije, ponudnik gostovanja ali izvajalec.
Ali zadošča prehod na PHP 8.2?
Kratkoročno PHP 8.2.35 ranljivost zapre. PHP 8.2 pa 31. 12. 2026 doseže konec podpore. Kdor tako ali tako seli, naj zato preveri, ali aplikacija po navedbah proizvajalca podpira tudi 8.3 ali novejši.
Moja trgovina teče samo s PHP 7.4. Kaj zdaj?
Potrebni sta dve stvari vzporedno: strežnik zavarovati z vmesnimi ukrepi in izolacijo ter aplikacijo pripeljati na različico, ki prenese podprto različico PHP. Katera je to, piše v sistemskih zahtevah proizvajalca.