Na kratko: Po PHP2Shell sama prikazana različica PHP malo dokazuje, ker ponudniki gostovanja popravke pogosto vgradijo kot backport. Zato pisno zahtevajte potrditev posodobitve PHP: stanje paketa za vsako vejo PHP, čas namestitve in ponovni zagon vseh procesov PHP. Predlogo za kopiranje najdete spodaj.
Zakaj ravno zdaj šteje pisna potrditev
Projekt PHP je 21. 10. 2026 objavil popravke za dve kritični ranljivosti, znani pod imenom PHP2Shell. Obe omogočata izvajanje škodljive kode na daljavo brez prijave. BSI (nemški zvezni urad za informacijsko varnost) je razglasil opozorilno stopnjo 3 / oranžna in priporoča takojšnjo posodobitev.
Kdor svojo spletno stran upravlja pri ponudniku gostovanja, posodobitve pogosto ne more namestiti sam. Hkrati kot upravljavec nosite odgovornost za podatke svojih strank. Pisna, konkretna potrditev ponudnika gostovanja zato ni zgolj formalnost. Je del vaše dokumentacije, na primer nasproti pooblaščencem za varstvo podatkov, zavarovalnicam ali vodstvu.
Poleg tega: popravek ne odstrani škodljive programske opreme, ki je bila vnesena prej. Po poročilih medijev je bil prvi opaženi poskus napada že 17. 10. Natančen trenutek, ko je bil vaš strežnik zaščiten, je zato pomemben za vprašanje, ali morate preverjanje nadaljevati.
Zakaj prikazana različica PHP ne zadošča
Odpravljene so različice PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35. Številne distribucije in ponudniki gostovanja popravek v svoj paket prevzamejo kot backport. Tedaj vmesnik, kot je Plesk, še naprej prikazuje 8.2.34, čeprav je strežnik popravljen.
Obratno lahko zavede tudi pravilna številka različice. Nove datoteke same ne ščitijo, dokler v pomnilniku še tečejo stari procesi PHP. Šele po ponovnem zagonu vseh workerjev je novo stanje aktivno. Več o tem v prispevku Pravilno preverjanje različice PHP in stanja popravkov.
| Izjava ponudnika gostovanja | Kaj dokazuje | Kaj še manjka |
|---|---|---|
| „Vsi sistemi so posodobljeni.“ | malo | Različica ali stanje paketa, datum, ponovni zagon |
| „PHP 8.3.36 je nameščen.“ | Različica | Datum, ponovni zagon, prizadeti strežniki |
| „Backport v paketu xy, ponovni zagon dne …“ | Popravek in aktivacija | po potrebi podatki o PHP 8.1 in starejših |
Katere podatke potrebujete od ponudnika gostovanja
Prosite za odgovore na te točke, po možnosti za vsako spletno stran ali pogodbo:
- Katere veje in različice PHP so aktivne za vaše spletne strani, tudi starejše, ki tečejo samo za posamezne mape?
- So popravki za CVE-2026-109618 in CVE-2026-109619 vključeni, kot uradna različica ali kot backport?
- Kdaj je bila posodobitev nameščena in kdaj so bili vsi procesi PHP (pooli FPM, Apache, LiteSpeed) znova zagnani?
- Ali je
session.upload_progress.enabledzaradi CVE-2026-115560 izklopljen? - Kateri način delovanja uporablja vaš paket, na primer PHP-FPM ali Apache z mod_php? Pri mod_php ekipa PHP vidi najvišje tveganje.
- Kateri dnevniki dostopov in napak od 20. 10. 2026 se hranijo in kako jih lahko dobite?
Če spletna stran še teče na PHP 8.1 ali starejšem, povprašajte posebej. Za te veje uradnih posodobitev ni več, obstajajo samo minimalni backporti izvorne kode za 7.4, 8.0 in 8.1.
Predloga: zahteva za potrditev posodobitve PHP pri ponudniku gostovanja
Besedilo kopirajte v prijavo na podporo ali e-pošto svojemu ponudniku gostovanja. Podatke v oglatih oklepajih dopolnite.
Zadeva: Prošnja za potrditev stanja popravkov PHP (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Dober dan,
pri vas upravljamo naslednja spletna mesta / pogodbe:
[številka stranke, pogodba, domene]
V zvezi z varnostnimi ranljivostmi PHP CVE-2026-109618 in
CVE-2026-109619 (PHP2Shell, popravki z dne 21. 10. 2026) ter opozorilom
h CVE-2026-115560 z dne 23. 10. 2026 vas prosimo za pisno
potrditev naslednjih točk:
1. Katere različice PHP oziroma stanja paketov so aktivne za naša spletna mesta?
2. Ali vsebujejo popravke (uradna različica ali backport)?
3. Datum in ura namestitve.
4. Datum in ura ponovnega zagona vseh procesov PHP (FPM, Apache,
LiteSpeed ipd.).
5. Ali je session.upload_progress.enabled na strežniku izklopljen?
6. Kateri način delovanja PHP se uporablja (npr. PHP-FPM, mod_php)?
7. Ali se dostopovni dnevniki in dnevniki napak hranijo od 20. 10. 2026
in kako jih lahko dobimo?
8. Če spletno mesto še uporablja PHP 8.1 ali starejši: Kakšna zaščita
je tam in kateri prehod priporočate?
Te podatke potrebujemo za našo interno dokumentacijo.
Hvala in lep pozdrav
[ime, podjetje, funkcija]
Pravilna ocena odgovora in lastno preverjanje
Dober odgovor navaja konkretna stanja, datume in ure. Splošne izjave, kot je „odzvali smo se“, za vašo dokumentacijo ne zadoščajo. V tem primeru prijazno povprašajte po manjkajočih točkah.
Če vaš paket to dopušča, preverite tudi sami. Z dostopom SSH običajno zadostujejo ti ukazi:
# Različica ukazne vrstice (lahko se razlikuje od spletne različice)
php -v
# Stanje paketov v Debianu/Ubuntuju
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Stanje paketov v RHEL, Alma, Rocky
rpm -qa | grep -i php
# Od kdaj tečejo procesi PHP-FPM?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Če je čas zagona procesov PHP pred potrjenim datumom namestitve, ponovni zagon ni bil popoln.
Če ponudnik gostovanja ne odgovori ali odgovarja izmikajoče
Če odgovora ni ali manjkajo odločilni podatki, stanja ne smete šteti za razjasnjeno. BSI priporoča, da se spletni strežniki začasno odklopijo z omrežja, če posodobitev ni takoj mogoča. Ali je to za vašo spletno stran sorazmerno, presodi vodstvo, v idealnem primeru pisno in z datumom.
Vzporedno se splača pogledati morebitne sledi napada, saj čas popravka ostaja odprt. Izhodišča ponuja prispevek Ali sem že kompromitiran?. Brez dostopa SSH ostaja pisna potrditev vaš najpomembnejši dokaz. Katere dolžnosti ima ponudnik gostovanja in katere vi, pojasnjuje stran Shared hosting: kaj naredi ponudnik gostovanja; za upravljane strežnike pomaga stran Managed server: razjasnitev odgovornosti.
Povpraševanje, odgovor in lastne rezultate preverjanja z datumom shranite v eno mapo. Ta dokumentacija pozneje pomaga pri vprašanjih zavarovalnic ali pooblaščencev za varstvo podatkov.
Kako PHP SOS pomaga konkretno?
- Z vami oblikujemo poizvedbo za ponudnika gostovanja in strokovno ocenimo odgovor.
- Kjer je dostop mogoč, stanje paketov, aktivni način delovanja in ponovni zagon procesov PHP preverimo sami.
- Če ostanejo vrzeli, uvedemo vmesne ukrepe ali načrtujemo prehod na podprto različico.
- Rezultat in časovne točke zapišemo v dokazilo, ki ga lahko posredujete znotraj podjetja.
Kako poteka posodobitev s ponovnim zagonom in dokazilom, opisuje naš Servis za popravke PHP.
Pogosta vprašanja
Ali zadošča, če ponudnik gostovanja napiše, da je vse posodobljeno?
Za vašo dokumentacijo to praviloma ne zadošča. Prosite za konkretne podatke: stanje paketa ali različico za vsako vejo PHP, datum namestitve in datum ponovnega zagona vseh procesov PHP. Šele s tem lahko omejite časovno okno ranljivosti.
Zakaj moj vmesnik za gostovanje še vedno prikazuje PHP 8.2.34?
Distribucije in ponudniki gostovanja varnostne popravke včasih vgradijo kot backport, ne da bi spremenili številko različice. Plesk lahko tedaj še naprej prikazuje 8.2.34, čeprav je strežnik popravljen. Jasnost prinese samo potrditev ponudnika glede stanja paketa.
Kaj naj storim, če ponudnik gostovanja ne odgovori?
Svojo poizvedbo dokumentirajte z datumom in čez primeren čas ponovno povprašajte. Vzporedno preverite, ali lahko vmesne ukrepe nastavite sami, in z vodstvom uskladite, ali bo spletna stran do razjasnitve odklopljena z omrežja, kot BSI priporoča za nepopravljene strežnike.
Ali tudi posodobitev WordPressa ali spletne trgovine zapre ranljivost?
Ne. PHP2Shell je v samem PHP. Posodobitev CMS-ja ali programske opreme trgovine ne spremeni ničesar na interpreterju PHP, ki teče na strežniku.