Varnostna ekipa PHP je v torek, 20. oktobra, zvečer vnaprej napovedala, da bo naslednji dan izšla nujna varnostna izdaja za dve kritični napaki. Podrobnosti napak so pricurljale še pred uradno objavo, zato so izdajo prestavili dan naprej. 21. oktobra ob 16.00 po srednjeevropskem času je ekipa php.net sama izdala popravljene različice.

Zaradi uhajanja so se hitro odzvali tudi napadalci: več varnostnih podjetij (med njimi watchTowr, Hadrian in Patchstack) je zaznalo aktivno izkoriščanje, Cloudflare pa je prve napade sporočil že pred popravkom. Po poročilu Amazon Threat Intelligence so se prvi poskusi začeli že 17. oktobra.

Zakaj je kritična?

Obe napaki sta v upravljanju pomnilnika PHP:

• CVE-2026-109618: če med obdelavo zahteve zmanjka pomnilnika, PHP izvede čiščenje z napol pripravljenimi podatki, kar vodi do poškodbe pomnilnika.
• CVE-2026-109619: poznejša zahteva v istem procesu PHP lahko uporabi stanje iz prejšnje zahteve, ki kaže na že sproščen pomnilnik.

Obe imata oceno CVSS 9,2 (kritično). S posebej sestavljeno spletno zahtevo lahko napadalec na strežniku izvede kodo, s pravicami procesa PHP. Raziskovalci so pokazali tudi, da lahko pricurlja vsebina pomnilnika procesa PHP, ki lahko vsebuje gesla, žetone ali ključe API.

Ker PHP zahtevo obdela pred kodo aplikacije, ne pomaga niti zaščita prijave v CMS. Največje tveganje predstavlja Apache mod_php, vendar so pri določenih nastavitvah prizadeti tudi PHP-FPM, LiteSpeed in FrankenPHP.

Prizadete različice in popravki

Napake prizadenejo PHP 5.4 in novejše različice.

Pomembno: spodnja tabela kaže izključno, za katere veje je ekipa PHP.net (sam projekt PHP) izdala uradni popravek. To ne pomeni, da druge različice dejansko ostanejo nezaščitene: vzdrževalci operacijskih sistemov in proizvajalci programske opreme (na primer CloudLinux, cPanel, TuxCare, Debian, Ubuntu ali AlmaLinux) lahko popravek prenesejo nazaj (backport) tudi na druge, starejše različice PHP, in v praksi to pogosto tudi storijo. Kakšno je stanje na določenem strežniku, odloča stanje tam uporabljenega paketa, ne številka različice PHP.

Veja PHP	Popravljena različica od PHP.net	Opomba
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35	podpora PHP.net poteče 31. decembra 2026
8.1 in starejše	PHP.net ne izda uradne izdaje	ekipa PHP je objavila popravek na ravni izvorne kode za veje 7.4, 8.0 in 8.1; distribucije in proizvajalci lahko zanje (in za še starejše veje) izdajo lastne, nazaj prenesene popravke

Tabela torej kaže uradno podporo PHP.net, ne tega, katera različica je na določenem strežniku varna. Pri nas na primer paketi CloudLinux in cPanel (EasyApache) vsebujejo popravek tudi za starejše veje PHP, zato so na teh strežnikih zaščitene tudi starejše različice.

Zakaj ostane ista številka različice?

Nekateri proizvajalci (na primer CloudLinux) popravek prenesejo nazaj (backport) v svoje pakete s starejšo številko različice. V tem primeru se številka različice PHP ne spremeni (na primer ostane 8.5.11), spremeni se le številka gradnje paketa, ki pa v različici ni vidna. Da je popravek vključen, potrjuje dnevnik sprememb (changelog) paketa.

Zato lahko preverjevalniki, ki gledajo le številko različice PHP, sporočijo napačno. Če vtičnik WordPress (na primer HelloPack) javi, da stran uporablja PHP 8.5.11 in jo je treba posodobiti, to ne pomeni samodejno, da popravek manjka. Če vidiš takšno opozorilo, nam piši in potrdili ti bomo stanje.

Pri tem pomaga tudi Build Date v izpisu phpinfo(): če je datum po 21. oktobru 2026, je bil paket verjetno znova preveden po popravku. Zanesljiva preverba je dnevnik sprememb paketa.

Kaj smo naredili mi?

• Že pred izidom popravka smo na naših strežnikih uvedli pravila ModSecurity, da bi do takrat zagotovili vsaj nekaj zaščite. To je dodatna zaščita, ki posodobitve PHP ne nadomešča.
• Na naših strežnikih: popravke smo ob izidu namestili v 5–15 minutah. Popravki za različne različice PHP so izhajali sproti, zaradi obremenjenosti repozitorijev pa je tudi njihov prenos trajal dlje kot običajno.
• Ponovni zagon: popravek začne veljati šele po ponovnem zagonu prizadetih storitev, zato smo Apache in PHP (ne celotnega strežnika) večkrat znova zagnali. To je skupaj povzročilo le nekaj minut prekinitve.
• Če tvoja stran deluje za Cloudflare, je tudi Cloudflare uvedel lastna zaščitna pravila: ta so 21. oktobra 2026 od 5.02 po srednjeevropskem času privzeto začela veljati prek pravil WAF. Tudi pri brezplačnih naročninah Cloudflare.

Kaj lahko narediš?

1. Za popravek PHP ti ni treba narediti ničesar. Popravek mora namestiti upravljavec oziroma vzdrževalec strežnika, iz same spletne aplikacije ga ni mogoče popraviti.
2. Preglej svojo stran. Sumljivi znaki so lahko neznane ali nedavno spremenjene datoteke .php, neznani uporabniki ali skrbniki v CMS, neznana načrtovana opravila (cron) v računu gostovanja ter nepričakovane preusmeritve, neželena ali tuja vsebina. Če kaj takega najdeš, nam to sporoči in ne briši ničesar, preden se dogovorimo.
3. Razmisli o menjavi gesel. Brez sumljivih znakov to ni obvezno, a iz previdnosti, zlasti če stran obravnava prijave ali plačila, je vredno zamenjati gesla za nadzorno ploščo, FTP, podatkovno bazo in skrbnika CMS. Napaka lahko razkrije tudi vsebino pomnilnika procesa PHP. Menjavo gesla za cPanel prikazujemo v ločenem članku.
4. CMS in vtičnike imej posodobljene. To ne nadomešča posodobitve PHP, vendar zmanjša napadalno površino.
5. Bodi previden z lažnimi sporočili. Zaradi novice se lahko namnožijo lažna sporočila, ki se sklicujejo na »nujno varnostno posodobitev«. Nikoli ne zahtevamo tvojega gesla po e-pošti.

Kdor bi rad preveril svojo stran, lahko uporabi na primer odprtokodno orodje php2shell-scanner podjetja Searchlight Cyber ali brezplačni preverjevalnik URL podjetja Aikido. Uporabljajte jih le za testiranje lastnega strežnika in lastne strani!

Časovnica

Časi so navedeni po srednjeevropskem poletnem času (CEST), v obliki LLLL-MM-DD UU:MM.

Datum	Dogodek
2026-10-17	Po poročilu Amazon Threat Intelligence so se takrat začeli prvi poskusi izkoriščanja, pred javno objavo.
2026-10-20 21:33	Varnostna ekipa PHP vnaprej napove nujno izdajo za dve kritični napaki. Podrobnosti pricurljajo še pred uradno objavo, tudi CERT-EU izda opozorilo.
2026-10-21 05:02	Cloudflare na paketih z WAF privzeto vklopi svoja zaščitna pravila.
2026-10-21 09:43	Cloudflare sporoči prve napade.
2026-10-21 11:08	Prvi nabor pravil Imunify360 WAF blokira javno krožeči vzorec napada.
2026-10-21 13:35	Hadrian poroča o obsežnem izkoriščanju, predvsem prek postopka nalaganja seje (session upload progress).
2026-10-21 16:00	Ekipa php.net izda popravljene različice: 8.5.12, 8.4.27, 8.3.36 in 8.2.35.
2026-10-21 16:19	watchTowr potrdi, da zaznava aktivne poskuse izkoriščanja obeh napak. Opozorilo izdata tudi CISA in britanski NCSC.
2026-10-21 sproti	Tudi cPanel izda obvestilo o popravljenih paketih cPanel in EasyApache 4.
2026-10-21 19:50	AlmaLinux izda popravljene pakete PHP za testiranje (v produkcijske repozitorije pridejo od 2026-10-21 23:15).
2026-10-21 22:55	CloudLinux izda popravljene pakete ea-php (ea-php52–ea-php85).
2026-10-21	Ubuntu izda obvestilo USN-8948-1: popravljeni paketi PHP za izdaje Ubuntu 22.04 LTS (php8.1, 8.1.2-1ubuntu2.28), 24.04 LTS (php8.3, 8.3.6-0ubuntu0.24.04.13), 26.04 LTS (php8.5, 8.5.4-0ubuntu1.5) in 26.10 (php8.5, 8.5.9-0ubuntu2.1).
2026-10-21	Ubuntu izda obvestilo USN-8948-2 za starejše izdaje: 20.04 LTS (php7.4, 7.4.3-4ubuntu2.29+esm5) in 18.04 LTS (php7.2, 7.2.24-0ubuntu0.18.04.17+esm14) prek ESM; popravek za 16.04 in 14.04 zahteva naročnino Ubuntu Pro Legacy Support.
2026-10-21	Tudi Debian izda popravljene pakete: trixie (Debian 13) php8.4 8.4.27-1~deb13u1 (DSA-6574-1) in bookworm (Debian 12) php8.2 8.2.35-1~deb12u1 (DLA-4848-1). V nestabilni veji (sid) popravka v sledilniku Debiana še ni bilo.
2026-10-22 02:07	Popravljeni paketi alt-php CloudLinuxa se pojavijo v stabilnih repozitorijih (CloudLinux 7, 8, 9: PHP 5.2–8.5).
2026-10-22 03:19	TuxCare je izdal vse popravljene pakete (alt-php, lastne pakete PHP distribucij, PHP for Windows).
2026-10-22 14:05	Izide odprtokodno orodje za preverjanje (Searchlight Cyber php2shell-scanner).

Pogosta vprašanja

Ali to zadeva mojo stran WordPress ali spletno trgovino? Da, lahko zadeva vsako stran na osnovi PHP, ker je napaka v PHP. Popravek se izvede na strežniku.

Ali zadošča posodobitev WordPressa ali vtičnikov? Ne. Napako odpravi popravek PHP, posodobitev CMS sama po sebi ne.

Ali je moja stran izpadla? Za kratek čas da: ponovni zagoni Apacha in PHP so skupaj povzročili le nekaj minut prekinitve.

Lahko še naprej uporabljam PHP 8.1 ali starejšega? PHP.net za te veje ni izdal uradne izdaje, vendar lahko operacijski sistemi in proizvajalci (na primer CloudLinux, cPanel in TuxCare) zanje izdajo nazaj prenesen popravek, zato so na teh strežnikih lahko zaščitene tudi starejše različice. Dolgoročno priporočamo prehod na podprto različico (8.3 ali 8.4), če je tvoja stran združljiva z njo. Pred prehodom naredi varnostno kopijo, po njem pa preizkusi stran. Menjavo različice PHP v cPanelu prikazujemo v ločenem članku.

• kibernetska varnost
• php
• cloudlinux
• cpanel
• novice