Na kratko: Obhodna rešitev za varnostno ranljivost PHP2Shell lahko tveganje zmanjša, a posodobitve ne nadomešča. php.net zanjo navaja trdne omejitve pomnilnika in nalaganja, izklop session upload progress in pri PHP 8.5 fatal_error_backtraces=0. Če tudi to ni mogoče kratkoročno, BSI priporoča, da se spletni strežnik začasno odklopi z omrežja.
Kaj obhodna rešitev lahko stori in česa ne
Vmesni ukrepi php.net naj bi otežili pogoje, pod katerimi sta ranljivosti CVE-2026-109618 in CVE-2026-109619 izkoristljivi. Izrecno niso popolna zaščita. Ranljivosti sta odpravljeni samo v PHP 8.5.12, 8.4.27, 8.3.36 in 8.2.35 ali v potrjenem backportu vašega ponudnika.
Ukrepi so smiselni, kadar posodobitev iz konkretnega razloga še ni mogoča: okno vzdrževanja še čaka, aplikacijo je treba najprej preizkusiti ali pa upravljate PHP 8.1 ali starejši, za kar ni več uradne posodobitve. Takrat so most, ne cilj.
Zato skupaj z obhodno rešitvijo načrtujte tudi posodobitev: kdo jo izvede, v katerem oknu vzdrževanja in kdo potem preveri, da so vsi workerji znova zagnani? Prehod brez končnega datuma grozi, da postane trajno stanje.
Možnost 1: strežnik začasno odklopiti z omrežja
BSI je razglasil opozorilno stopnjo 3 (oranžna) in priporoča, da se prizadeti spletni strežniki začasno odklopijo z omrežja, če posodobitev ni takoj mogoča. Nekateri ponudniki so to storili previdnostno; to ne pomeni, da so bile te strani vdrte.
Za številna podjetja je izpad trgovine ali portala drag. Smiselna je lahko presoja: dostop samo še prek VPN ali odobrenih naslovov IP, statična vzdrževalna stran namesto aplikacije PHP ali izklop posameznih, nepotrebnih spletnih strani na strežniku. Čim manj PHP je dosegljivega od zunaj, tem manjša je napadalna površina.
Pomembno je, da se odločitev sprejme zavestno in zapiše: kdo je kdaj odločil, da strežnik ostane na spletu, in s kakšnimi zaščitnimi ukrepi? To pozneje pomaga nasproti zavarovalnici, varstvu podatkov in vodstvu.
Vmesni ukrepi php.net
| Ukrep | Vrednost | Opomba |
|---|---|---|
memory_limit |
-1, ni mogoče prepisati |
omejitev pomnilnika nato nastaviti prek containerja ali cgroup |
post_max_size |
8M brez nalaganj, 32M z nalaganji |
upload_max_filesize pod tem |
| Omejitev pomnilnika | prek containerja/cgroup | ne prek RLIMIT_AS ali RLIMIT_DATA |
session.upload_progress.enabled |
0 |
v php.ini, poolu ali konfiguraciji strežnika, ne prek ini_set() ali .user.ini |
fatal_error_backtraces |
0 |
samo PHP 8.5 |
Nastavitev session.upload_progress.enabled=0 je hkrati rešitev za ranljivost CVE-2026-115560, o kateri je bilo poročano 23. oktobra.
Obhodno rešitev za varnostno ranljivost PHP nastaviti pravilno
Odločilno je mesto. Vrednosti morajo biti nastavljene tako, da jih aplikacija ne more prepisati. Poti in imena storitev se po distribuciji razlikujejo; primeri izhajajo iz PHP 8.3.
PHP-FPM, v poolu (npr. /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; samo PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache z mod_php, v konfiguraciji strežnika ali VirtualHost:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Omejitev pomnilnika prek cgroup, tukaj s systemd za storitev FPM. Vrednost prilagodite svojemu strežniku:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Nato znova zaženite vse workerje, sicer nič od tega ne deluje: systemctl restart php8.3-fpm ali pri mod_php Apache. Kako preverite, da noben star proces ne teče več, piše na strani Ponovni zagon PHP-FPM in vseh workerjev. Splošno utrjevanje konfiguracije opisuje stran Varna konfiguracija php.ini.
Po preklopu preizkusite nalaganja in velike obrazce. Premalo velik post_max_size lahko blokira naročila, prijavne obrazce ali nalaganje medijev. To je razlog, da posodobitve ne odlašate dolgo.
Dodatne zaščitne plasti
Web Application Firewall ali virtualno popravljanje lahko pomaga kot nadaljnja plast. Cloudflare je uvedel zaščitna pravila, vendar sam opozarja, da pravila samo na podlagi podatkov zahteve ne zadoščajo. WAF je zato dopolnilo, ne nadomestilo. Več o tem na strani WAF in virtualno popravljanje.
Poleg tega zavarujte dnevnike strežnika od 20. oktobra. Po poročilih medijev je bil prvi poskus napada opažen že 17. oktobra; dnevniki so podlaga, če pozneje morate razjasniti, ali se je pred popravkom kaj zgodilo.
Kako konkretno pomaga PHP SOS?
- Razjasniti stanje: preverimo, ali je posodobitev kratkoročno mogoča ali je potreben prehod, in z vami obravnavamo možnost, da se deli odklopijo z omrežja.
- Nastaviti ukrepe: vrednosti php.net vpišemo na pravo mesto, nastavimo mejo cgroup in znova zaženemo vse workerje.
- Preizkusiti delovanje: po preklopu preverimo obrazce, nalaganja in postopke naročanja.
- Pripeljati do popravka: prek storitve popravljanja PHP načrtujemo posodobitev in vmesne vrednosti nato nadzorovano umaknemo, kjer motijo.
Pogosta vprašanja
Ali obhodna rešitev popolnoma ščiti pred PHP2Shell?
Ne. php.net ukrepe izrecno imenuje prehod in ne popolna zaščita. Tveganje zmanjšajo, dokler posodobitev ni nameščena. BSI (nemški zvezni urad za informacijsko varnost) priporoča, da se strežniki brez popravka začasno odklopijo z omrežja.
Ali lahko nastavitve določim prek .htaccess ali .user.ini?
Za session.upload_progress.enabled php.net ini_set() in .user.ini izrecno izključuje. Tudi za memory_limit velja: vrednost mora biti nastavljena tako, da je aplikacija ne more prepisati. To uspe v php.ini, v poolu FPM s php_admin_value ali v konfiguraciji strežnika Apache.
Ali kot obhodna rešitev zadošča Web Application Firewall?
Kot dodatna plast lahko pomaga. Cloudflare je uvedel zaščitna pravila, vendar sam opozarja, da pravila samo na podlagi podatkov zahteve ne zadoščajo. WAF ne nadomešča ne posodobitve ne vmesnih ukrepov na strežniku.
Kaj naj storim, če imam samo shared hosting?
Takrat php.ini in ponovni zagon obvladuje ponudnik gostovanja. Vprašajte konkretno, ali je bila posodobitev nameščena ali vmesni ukrepi nastavljeni in ali so bili vsi procesi PHP znova zagnani.