Na kratko: Kdor želi nameščeno posodobitev PHP, potrebuje več kot nove pakete: odločilni so pravo stanje paketa, ponovni zagon vseh procesov PHP in dokaz o tem. Prav to zagotavlja naša storitev popravljanja PHP. Za vsak strežnik prejmete pisno dokazilo, ki ga lahko predložite interno ali tretjim.
Zakaj posodobitev PHP sama pogosto ne zadošča
Od 21. 10. 2026 obstajajo popravki za ranljivosti PHP2Shell CVE-2026-109618 in CVE-2026-109619. BSI priporoča takojšnjo posodobitev. V praksi opažamo tri tipične ovire.
Prvič, številka različice ne kaže vedno pravega stanja. Distribucije in ponudniki gostovanja deloma nameščajo backporte; takrat Plesk na primer še naprej prikazuje 8.2.34, čeprav je stanje paketa popravljeno. Drugič, po namestitvi pogosto še naprej tečejo stari procesi PHP. Nove datoteke na disku ne ščitijo, dokler stari workerji delujejo v pomnilniku. Tretjič, na strežniku pogosto vzporedno tečeta dve ali več različic PHP in ena se pozabi.
Namestitev posodobitve PHP: odpravljene različice
| Veja | Odpravljeno od | Predhodno stanje | Opomba |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | dodatno preverite fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | podpora se konča 31. 12. 2026 |
| PHP 8.1 in starejši | ni uradnih posodobitev | – | samo minimalni backporti izvorne kode za 7.4, 8.0, 8.1 |
Pri paketih iz distribucij ali od ponudnikov gostovanja ne šteje številka za „PHP“, ampak stanje paketa, ki ga ponudnik potrdi kot popravljeno. Kako to preverite sami, piše na strani Pravilno preverjanje različice PHP in stanja popravkov.
Kako konkretno pomaga PHP SOS?
- Popis: zabeležimo vse namestitve PHP na strežniku, način delovanja (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) in katera spletna stran uporablja katero različico.
- Namestitev posodobitve: odpravljene različice namestimo iz paketnega vira vaše distribucije, vašega panela ali uradnega projekta. Za containerje z vami zgradimo nove slike.
- Ponovni zagon vseh procesov: PHP-FPM, Apache, LiteSpeed ali ustrezne workerje popolnoma znova zaženemo in preverimo, da noben proces ni starejši od posodobitve. Ozadje je na strani Ponovni zagon PHP-FPM in vseh workerjev.
- Preizkus delovanja: odpremo najpomembnejše strani in funkcije, na primer začetno stran, prijavo, obrazce in blagajno, ter preverimo dnevnike napak.
- Dokazilo: za vsak strežnik prejmete zapisnik z različico, stanjem paketa, časom ponovnega zagona in odprtimi točkami.
Tipičen korak preverjanja po ponovnem zagonu izgleda takole:
# Različica PHP CLI in binarne datoteke FPM (pot je odvisna od sistema)
php -v
php-fpm8.3 -v
# Čas zagona procesov FPM: mora biti po posodobitvi
ps -o pid,lstart,cmd -C php-fpm8.3
Posebni primeri: paneli, containerji in več različic PHP
Na strežnikih s Pleskom ali cPanelom različice PHP pogosto izvirajo iz paketnih virov panela in ne iz distribucije. Tam preverimo vsako nameščeno različico posebej, tudi tiste, ki trenutno niso dodeljene nobeni spletni strani. Neuporabljene, zastarele različice po dogovoru odstranimo, da se ne bi po pomoti znova aktivirale.
V okoljih Docker in Kubernetes posodobitev na gostitelju ne zadošča. PHP je v sliki in šele na novo zgrajena slika s popravljeno osnovo, razporejena na vse tekoče containerje, ranljivost zapre. Pri tem preverimo tudi, ali se starejše slike v registrih ali deploymentih še uporabljajo. Podrobnosti so na strani Popravljanje PHP v containerjih Docker.
Pri mod_php PHP teče neposredno v procesu Apache. Ekipa PHP tam tveganje ocenjuje kot najvišje. Po posodobitvi je zato treba znova zagnati sam Apache; zgolj ponovno nalaganje konfiguracije ni v vsakem primeru dovolj.
Kaj dobite od nas
- zapisnik popravljanja za vsak strežnik: nameščeni paketi, različice, vir, čas
- dokaz, da so bili vsi procesi PHP znova zagnani
- seznam preverjenih spletnih strani in funkcij
- opozorila o sistemih, ki jih ni bilo mogoče popraviti, z obrazložitvijo
- priporočilo za nadaljnjo pot, na primer pri PHP 8.2 zaradi bližnjega konca podpore
Kaj potrebujemo od vas
- Dostop: SSH s skrbniškimi pravicami ali dostop do panela (Plesk, cPanel ipd.)
- Okno vzdrževanja: kdaj je dovoljen kratek ponovni zagon
- Kontaktna oseba: za vprašanja in za potrditev po preizkusu delovanja
- Varnostne kopije: potrditev, da obstaja aktualna kopija, ali naročilo, da se pred tem ustvari
- Opozorila o lastnih razvojih: posebne razširitve PHP ali konfiguracije, ki jih je treba upoštevati
Pri shared hostingu brez lastnega dostopa do strežnika sami ne moremo popravljati. Takrat vam pomagamo, da pri ponudniku gostovanja zastavite prava vprašanja in ocenite odgovor.
Česa ne obljubljamo
Storitev popravljanja zapre znano ranljivost. Ne odgovori na vprašanje, ali je bil strežnik pred posodobitvijo že ogrožen, in ne odstrani vnesene škodljive programske opreme. Če to želite vedeti, je primerno naročilo takojšnja pomoč pri PHP2Shell z iskanjem sledi.
Za PHP 8.1 in starejše uradnih posodobitev ni več. Tam uvedemo vmesne ukrepe in priporočamo selitev na podprto različico. Zagotovila o združljivosti z vašim CMS-jem ne dajemo po spominu, ampak jo preverimo na podlagi sistemskih zahtev proizvajalca.
Pogosta vprašanja
Zakaj moj strežnik po posodobitvi še prikazuje staro različico PHP?
Razlogov je lahko dvoje. Ali je distribucija namestila backport, zato številka različice ostane enaka, čeprav je stanje paketa popravljeno. Ali pa stari procesi PHP še tečejo v pomnilniku in jih je treba znova zagnati.
Katere različice PHP zapirajo PHP2Shell?
Ranljivost je odpravljena v PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35, objavljenih 21. 10. 2026. Pri paketih distribucij šteje stanje paketa, ki ga ponudnik potrdi kot popravljeno.
Ali lahko posodobitev ohromi mojo spletno stran?
Posodobitev znotraj iste glavne različice, na primer z 8.3.35 na 8.3.36, je praviloma nekritična. Kratek ponovni zagon procesov PHP pa je potreben. Časovno okno uskladimo z vami in nato preverimo spletne strani.
Ali je s popravkom vse opravljeno?
Za samo ranljivost da, takoj ko so vsi procesi znova zagnani. Ali je kdo vdrl že pred popravkom, popravek ne pokaže. Za to je potreben samostojen pregled.