Časovnica PHP2Shell: kronologija od 17. do 25. oktobra 2026

Na kratko: Časovnica PHP2Shell zaenkrat obsega štiri dokumentirane datume: prvi opaženi poskus napada 17. 10., vnaprejšnja napoved na php.net 20. 10., popravki 21. 10. ob 16.00 po nemškem času in dodatno opozorilo o CVE-2026-115560 23. 10. 2026. Za upravljavce iz tega sledi: namestite popravke, znova zaženite vse procese PHP in dnevnike zavarujte najpozneje od 20. 10.

Zakaj je časovnica PHP2Shell pomembna za upravljavce

Pri ranljivosti te resnosti ni pomembno samo, ali je vaš strežnik danes popravljen. Odločilno je tudi, kako dolgo je bil prej ranljiv. To časovno okno določa, katere dnevnike zavarujete, katere datoteke preverite in ali lahko kompromitacijo z dobrim razlogom izključite.

PHP2Shell zadeva PHP sam, ne posameznega CMS-ja. Dve kritični ranljivosti, CVE-2026-109618 in CVE-2026-109619, omogočata izvajanje škodljive kode na daljavo brez prijave. Obe imata po CVSS v4.0 oceno 9,2. Razumljiv uvod najdete na strani Kaj je PHP2Shell?.

Spodnja kronologija vsebuje samo podatke, ki so na dan 25. 10. 2026 dokumentirani. Kjer navedba temelji na poročilih medijev, je to označeno.

17. oktober: prvi opaženi poskus napada

Po poročilih medijev je bil 17. 10. 2026 opažen prvi poskus napada, o katerem je poročal Amazon. To je bilo štiri dni pred popravki. Obstajalo je torej obdobje, ko so se napadi že poskušali, posodobitve pa še ni bilo.

Ali in koliko napadov je bilo v tej fazi uspešnih, ni dokumentirano. Pomembna je posledica za vaše lastno preverjanje: strežnik, ki je danes popravljen, je bil lahko prej kompromitiran. Popravek ne odstrani vnesene škodljive programske opreme in ne dokazuje, da prej ni bilo nič narobe.

20. in 21. oktober: napoved in popravki

Projekt PHP je 20. 10. 2026 na php.net napovedal varnostne posodobitve. Odpravljene različice so sledile 21. 10. 2026 ob 14.00 UTC, torej ob 16.00 po nemškem času.

Za PHP 8.1 in starejše uradnih posodobitev ni več, obstajajo samo minimalni backporti izvorne kode za 7.4, 8.0 in 8.1. Po navedbah strokovnega tiska so prizadete skoraj vse različice vse do PHP 5.4. Prizadeti načini delovanja so PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP in LiteSpeed. Najvišje tveganje ekipa PHP vidi pri mod_php, kjer je bil exploit prikazan, še preden se sploh izvede koda aplikacije.

Distribucije in ponudniki gostovanja včasih vgradijo backporte. Tedaj Plesk na primer še naprej prikazuje 8.2.34, čeprav je strežnik popravljen. Merodajna sta stanje paketa in potrditev ponudnika, ne prikazana številka različice. Kako to pravilno preverite, piše na strani Pravilno preverjanje različice PHP in stanja popravkov.

23. oktober: opozorilo o CVE-2026-115560

Projekt PHP je 23. 10. 2026 objavil dodatno opozorilo, tokrat o CVE-2026-115560. Po njem je izkoriščanje mogoče samo pri nenavadni konfiguraciji: v konfiguraciji je serialize_handler php_binary ali php_serialize, aplikacija ga pred session_start() z ini_set() preklopi na php, session upload progress pa je aktiven.

Rešitev je preprosta in jo nastavite ne glede na to, ali takšno konstelacijo pri sebi poznate:

; v php.ini, v poolu FPM ali v konfiguraciji strežnika
; ne prek ini_set() ali .user.ini
session.upload_progress.enabled = 0

Nato znova zaženite vse workerje PHP. Popolno opozorilo naj bi sledilo z naslednjo redno izdajo s popravki napak. Do takrat ostaja ta nastavitev priporočena vmesna rešitev.

Stanje 25. oktobra: razmere in odprta vprašanja

BSI (nemški zvezni urad za informacijsko varnost) je razglasil opozorilno stopnjo 3 / oranžna. Priporoča takojšnjo posodobitev in, če to ni mogoče takoj, začasen odklop spletnih strežnikov z omrežja. BSI je pričakoval hitro obsežno izkoriščanje; potrjeni uspešni napadi v širšem obsegu po navedbah BSI sprva niso bili znani. Presojo BSI povzema stran Kaj BSI priporoča glede PHP2Shell.

Cloudflare je poročal o opaženih poskusih napadov in uvedel zaščitna pravila, vendar opozarja, da pravila samo na podlagi podatkov zahteve ne zadoščajo. Palo Alto Networks (Unit 42) je naštel več kot 22,6 milijona izpostavljenih, potencialno ranljivih instanc. Potrjeni Indicators of Compromise niso objavljeni; odkrivanje temelji na analizi vedenja.

Nekateri ponudniki so spletne strani previdnostno umaknili iz spleta. To samodejno ne pomeni, da so bile te strani vdrte. Ob stanju tega pregleda je odprto predvsem, koliko strežnikov je bilo v času pred popravkom dejansko kompromitiranih.

Kaj časovnica pomeni za vaše dnevnike in preverjanja

Iz datumov izhajajo tri obdobja: pred 17. 10., med 17. 10. in vašim lastnim trenutkom popravka in ponovnega zagona ter po njem. Srednje obdobje je kritično. Dlje ko je pri vas trajalo, temeljiteje naj bo preverjanje.

Preprost način, da dnevnike zavarujete nespremenjene in zabeležite stanje:

# Dnevnike zavarujte skupaj (poti prilagodite svojemu sistemu)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Kontrolna vsota za poznejši dokaz
sha256sum /root/logs-sicherung-*.tar.gz
# Kako dolgo sistem hrani dnevnike?
grep -R "rotate" /etc/logrotate.d/

Poleg tega zapišite, kdaj točno je bila posodobitev nameščena in kdaj so bili procesi PHP znova zagnani. Nove datoteke same ne ščitijo, dokler v pomnilniku še tečejo stari procesi. Kako ovrednotite zavarovane dnevnike, opisuje vodnik Analiza dnevnikov spletnega strežnika po napadu.

Kako PHP SOS pomaga konkretno?

• Z vami ugotovimo dejansko okno ranljivosti vašega strežnika: stanje paketov, čas popravka, ponovni zagon vseh workerjev.
• Dnevnike in stanje sistema zavarujemo sledljivo, še preden se karkoli spremeni.
• Preverimo, ali so prisotne vedenjske nepravilnosti, na primer nove datoteke PHP, tuji procesi in nenavadne odhodne povezave.
• Rezultat dokumentiramo tako, da lahko z njim delajo vodstvo, pooblaščenci za varstvo podatkov in zavarovalnice.

Postopek podrobno opisuje naša nujna pomoč PHP2Shell.

Pogosta vprašanja

Viri

• php.net: varnostna obvestila
• PHP 8 ChangeLog
• BSI: nemški zvezni urad za informacijsko varnost
• TechTarget: PHP2Shell, 22M exposed servers at risk