PHP2Shell: kritične vrzeli v PHP – tako jih zdaj odpravite

21. oktober 2026 | PHP | IT-varnost

21. oktobra 2026 je varnostna ekipa PHP objavila posodobitve za vse še podprte različice PHP. Odpravljata dve kritični ranljivosti, znani kot PHP2Shell. BSI je izdal opozorilo in zahteva, da se prizadeti sistemi nemudoma posodobijo. Kdor upravlja spletni strežnik s PHP, naj ukrepa še danes. To velja tudi za vse, ki upravljajo „le“ WordPress, Nextcloud ali Joomla, saj te aplikacije tečejo na PHP.

Ta prispevek povzema, kaj se je zgodilo, katere različice PHP so prizadete, katero različico zdaj potrebujete in kako v nekaj minutah preverite, ali je vaš strežnik zaščiten.

Kaj se je zgodilo? Časovni potek

Varnostna ekipa PHP je objavo popravkov napovedala vnaprej, da so imeli ponudniki gostovanja in skrbniki čas za pripravo. Sama objava je bila 21. oktobra 2026. BSI je še isti dan izdal svoje opozorilo (različica 1.1).

• 20. oktober 2026: Predopozorilo varnostne ekipe PHP, da bodo naslednji dan izšle varnostne posodobitve.
• 21. oktober 2026, 14:00 UTC (16:00 CEST): Objavljeni so popravki za PHP 8.5, 8.4, 8.3 in 8.2.
• 21. oktober 2026: BSI opozarja pred „kritičnimi ranljivostmi, ki ogrožajo spletne aplikacije po vsem svetu“, in priporoča, da se nemudoma posodobi. Po navedbah BSI so veliki ponudniki gostovanja strežnike deloma preventivno izklopili.

Obe ranljivosti PHP na kratko

Gre za dve ločeni napaki v jedru PHP: CVE-2026-109618 in CVE-2026-109619. Obe po navedbah varnostne ekipe PHP lahko privedeta do tega, da lahko napadalec izvaja programsko kodo na strežniku, ne da bi se prijavil (unauthenticated Remote Code Execution). Ranljivosti so ocenjene s CVSS v4.0: 9,2 (kritično).

Po oceni BSI ob objavi ni bilo potrjenih napadov, vendar so obstajali nepotrjeni znaki poskusov izkoriščanja. Pri kritičnih vrzelih v tako razširjeni programski opremi je po izkušnjah treba računati s tem, da napadalci popravke analizirajo in pripravljajo avtomatizirane napade. Časovno okno za posodobitev je zato kratko.

Koga zadeva?

Prizadet je načeloma vsak strežnik, na katerem teče PHP, ne glede na to, kako je PHP povezan: PHP-FPM, mod_php v Apachu, php-cgi, FrankenPHP ali LiteSpeed. Po navedbah varnostne ekipe PHP je tveganje največje pri Apachu z mod_php.

BSI izrecno navaja aplikacije, ki temeljijo na PHP in so zato lahko soprizadete:

• Sistemi za upravljanje vsebin: WordPress, Drupal, TYPO3, Joomla
• Spletne trgovine: Magento
• Oblak in shranjevanje datotek: Nextcloud
• Vmesniki požarnih zidov: pfSense, OPNsense

Aplikacija sama pri tem ne sme biti okvarjena. Vrzel je v PHP, zato samo posodobitev WordPressa, Nextclouda & drugih ne pomaga. Posodobiti je treba različico PHP na strežniku. Pri požarnih zidovih, kot sta pfSense in OPNsense, popravljena različica PHP pride prek posodobitve vdelane programske opreme (firmware) proizvajalca.

Te različice PHP so varne

Ranljivosti so odpravljene v naslednjih različicah. Vse pod tem velja za ranljivo.

Tako preverite in posodobite svoj strežnik

1. Ugotovite nameščeno različico PHP

V ukazni vrstici strežnika php -v prikaže različico ukazno-vrstičnega PHP. Spletni strežnik lahko uporablja drugo različico PHP. Zato preverite tudi različico PHP-FPM oziroma modula Apache, na primer z php-fpm8.3 -v ali prek strani, ki izpiše phpinfo() (to nato takoj spet odstranite).

2. Posodobitev namestite prek upravljanja paketov

Pri Debianu, Ubuntuju, RHEL in sorodnih popravljena različica pride prek običajnega upravljanja paketov, na primer apt update && apt upgrade ali dnf upgrade. Pri zunanjih virih, kot sta Sury PPA ali repozitorij Remi, se novi paketi običajno pojavijo kmalu.

3. Znova zaženite storitev PHP

Sama posodobitev paketa ne zadošča: tekoči procesi PHP obdržijo staro kodo v pomnilniku. Znova zaženite PHP-FPM (systemctl restart php8.3-fpm) oziroma Apache (systemctl restart apache2) in nato preverite, ali so bili procesi zagnani po posodobitvi.

4. Gostovane spletne strani

Pri skupnem gostovanju običajno posodablja ponudnik. V meniju za stranke je običajno mogoče nastaviti različico PHP za vsako spletno stran. Tam izberite eno od zgoraj navedenih varnih različic ali pri ponudniku vprašajte po stanju popravkov. Po navedbah BSI so posamezni ponudniki strežnike preventivno odklopili z omrežja. Če vaša stran za kratek čas ni dosegljiva, je to lahko vzrok.

PHP 8.1 in starejše: brez uradne posodobitve

Za PHP 8.1 in starejše uradnih varnostnih posodobitev ni več. Upravljavci takih sistemov imajo dve možnosti:

• Preklop na podprto različico (priporočeno). Starejša ko je različica, večji je napor za prilagoditev aplikacije in razširitev, zato je treba preklop prej preizkusiti.
• Popravke prenesti nazaj (backport). Varnostna ekipa PHP je popravke objavila v razvojnih vejah na GitHubu. Kdor PHP prevaja sam, lahko te spremembe prevzame v starejše različice. To je prehodna rešitev in zahteva strokovno znanje.

Tudi PHP 8.2 je podprt le še do 31. decembra 2026. Zato prehod na PHP 8.4 ali 8.5 načrtujte zdaj in ga ne odlašajte na prelom leta.

Prehodni ukrepi in vprašanje „Izklopiti strežnik?“

Varnostna ekipa PHP je ob napovedi opisala tudi začasne zaščitne ukrepe. Ti zmanjšujejo tveganje, vendar vrzeli ne zaprejo popolnoma. Ne nadomeščajo posodobitve in so namenjeni le premostitvi časa do posodobitve.

Ali naj se strežnik do posodobitve odklopi z omrežja, je odvisno od njegovega pomena in dosegljivosti. BSI navaja, da so veliki ponudniki ta korak naredili. Kot pravilo palca velja:

• Javno dosegljiv strežnik, posodobitev zdaj mogoča: takoj posodobite, izklop ni potreben.
• Javno dosegljiv strežnik, posodobitev kratkoročno ni mogoča: omejite dostop (na primer prek požarnega zidu samo za znane naslove) ali storitev začasno izklopite, zlasti pri mod_php.
• Samo interno dosegljiv strežnik: posodobite v doglednem času, nujnost je manjša.

Pogosta vprašanja

Ali moram posodobiti WordPress, Joomla ali Nextcloud?

Ne zaradi te ranljivosti. Ta je v PHP, ne v aplikaciji. Posodobite različico PHP na strežniku. Posodobitev aplikacije je kljub temu smiselna, neodvisno od tega.

Kako ugotovim, ali je kdo ranljivost že izkoristil?

Zanesljiva ugotovitev je težka. Opozorilni znaki so neznane datoteke PHP v spletnem imeniku, nenavadni procesi pod uporabnikom spletnega strežnika, novi uporabniški računi ali opravila cron ter nenavaden odhodni podatkovni promet. Pri konkretnem sumu je treba sistem forenzično pregledati in ga v dvomu postaviti znova.

Ali zadostuje požarni zid za spletne aplikacije (Web Application Firewall)?

Požarni zid lahko prestreže znane vzorce napadov, vendar ni nadomestilo za posodobitev. Več o sodelovanju več zaščitnih plasti preberite v našem prispevku Zaščita Odoo 19: požarni zid, 2FA & Web RBL. Načela veljajo za vsako spletno aplikacijo.

Ali je Odoo prizadet?

Ne. Odoo je napisan v Pythonu in ne teče na PHP. Prizadete bi bile le aplikacije PHP, ki tečejo na istem strežniku.

Kje najdem uradne informacije?

Objavo varnostne skupine PHP najdete v arhivih novic na php.net (vnos z dne 20. oktobra 2026), različice pa na php.net/downloads. Opozorilo urada BSI nosi številko 2026-297981-1032 in je na bsi.bund.de objavljeno.

Podpora podjetja Biricon IT Services

Če niste prepričani, katera različica PHP teče na vašem strežniku, ali potrebujete pomoč pri popravljanju, vam z veseljem pomagamo: pri popisu vseh sistemov PHP, pri nameščanju posodobitev, pri prehodu na podprto različico PHP in pri preverjanju morebitne kompromitacije. Kot ponudnik IT storitev oskrbujemo strežnike, požarne zidove in spletne aplikacije za mala in srednja podjetja.

Kontaktirajte nas zdaj

Stanje: 21. oktober 2026. Razmere se lahko hitro spremenijo; merodajne so objave varnostne skupine PHP in urada BSI.