Ukratko: Zaobilazno rješenje za PHP sigurnosnu ranjivost PHP2Shell može smanjiti rizik, ali ne zamjenjuje ažuriranje. php.net za to navodi čvrsta ograničenja memorije i prijenosa, isključivanje Session Upload Progressa i na PHP-u 8.5 fatal_error_backtraces=0. Ako ni to nije kratkoročno moguće, BSI (njemački Savezni ured za sigurnost informacijske tehnologije) preporučuje web-poslužitelj privremeno isključiti s mreže.
Što zaobilazno rješenje može, a što ne
Privremene mjere php.net-a trebaju otežati uvjete pod kojima se ranjivosti CVE-2026-109618 i CVE-2026-109619 mogu iskoristiti. One izričito nisu potpuna zaštita. Ranjivosti su ispravljene samo u PHP-u 8.5.12, 8.4.27, 8.3.36 i 8.2.35 ili u potvrđenom backportu Vašeg pružatelja.
Mjere su smislene ako ažuriranje iz konkretnog razloga još nije moguće: prozor za održavanje tek slijedi, aplikaciju prvo treba testirati ili koristite PHP 8.1 ili stariji za koji više nema službenog ažuriranja. Tada su most, a ne cilj.
Zato uz zaobilazno rješenje istodobno planirajte i ažuriranje: tko ga provodi, u kojem prozoru za održavanje i tko poslije provjerava da su svi workeri ponovno pokrenuti? Prijelaz bez završnog datuma lako postaje trajno stanje.
Opcija 1: poslužitelj privremeno isključiti s mreže
BSI je proglasio razinu upozorenja 3 (narančasta) i preporučuje pogođene web-poslužitelje privremeno isključiti s mreže ako ažuriranje nije odmah moguće. Neki su pružatelji to učinili iz opreza; to ne znači da su te stranice hakirane.
Za mnoge je tvrtke ispad shopa ili portala skup. Procjena može biti smislena: pristup samo putem VPN-a ili odobrenih IP adresa, statična stranica o održavanju umjesto PHP aplikacije ili isključivanje pojedinih nepotrebnih web-stranica na poslužitelju. Što je manje PHP-a dostupno izvana, to je manja površina napada.
Važno je odluku donijeti svjesno i zabilježiti je: tko je kada odlučio ostaviti poslužitelj na mreži i s kojim zaštitnim mjerama? To kasnije pomaže prema osiguravatelju, zaštiti podataka i upravi.
Privremene mjere php.net-a
| Mjera | Vrijednost | Napomena |
|---|---|---|
memory_limit |
-1, bez mogućnosti nadjačavanja |
ograničenje memorije tada postaviti putem kontejnera ili cgroupa |
post_max_size |
8M bez prijenosa, 32M s prijenosima |
upload_max_filesize ispod toga |
| Ograničenje memorije | putem kontejnera/cgroupa | ne putem RLIMIT_AS ili RLIMIT_DATA |
session.upload_progress.enabled |
0 |
u php.ini, poolu ili konfiguraciji poslužitelja, ne putem ini_set() ili .user.ini |
fatal_error_backtraces |
0 |
samo PHP 8.5 |
Postavka session.upload_progress.enabled=0 ujedno je i mjera za ranjivost CVE-2026-115560 prijavljenu 23. listopada.
Ispravno postaviti zaobilazno rješenje za PHP sigurnosnu ranjivost
Odlučujuće je mjesto. Vrijednosti moraju biti postavljene tako da ih aplikacija ne može nadjačati. Putanje i nazivi usluga razlikuju se po distribuciji; primjeri polaze od PHP-a 8.3.
PHP-FPM, u 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 s mod_php, u konfiguraciji poslužitelja ili u VirtualHostu:
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
Ograničenje memorije putem cgroupa, ovdje preko systemd-a za FPM uslugu. Vrijednost prilagodite svom poslužitelju:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Zatim ponovno pokrenite sve workere, inače ništa od toga ne djeluje: systemctl restart php8.3-fpm ili kod mod_php Apache. Kako provjeriti da više ne radi nijedan stari proces, piše na stranici Ponovno pokretanje PHP-FPM-a i svih workera. Opće ojačavanje konfiguracije opisuje Sigurna konfiguracija php.ini.
Nakon prelaska testirajte prijenose i velike obrasce. Preuska vrijednost post_max_size može blokirati narudžbe, obrasce za prijave ili prijenose medija. To je jedan od razloga da se ažuriranje ne odgađa dugo.
Dodatni zaštitni slojevi
Web aplikacijski vatrozid ili virtualno zakrpanje može pomoći kao dodatni sloj. Cloudflare je uveo zaštitna pravila, ali i sam upozorava da pravila samo na temelju podataka zahtjeva nisu dovoljna. WAF je stoga dopuna, a ne zamjena. Više na stranici WAF i virtualno zakrpanje.
Osim toga osigurajte zapisnike poslužitelja od 20. listopada. Prema medijskim izvješćima prvi je pokušaj napada uočen već 17. listopada; zapisnici su osnova ako kasnije budete morali razjasniti je li se prije zakrpe nešto dogodilo.
Kako PHP SOS konkretno pomaže?
- Razjasniti stanje: Provjeravamo je li ažuriranje kratkoročno moguće ili je potreban prijelaz te s Vama razgovaramo o opciji da se dijelovi isključe s mreže.
- Postaviti mjere: Vrijednosti php.net-a upisujemo na pravo mjesto, postavljamo cgroup ograničenje i ponovno pokrećemo sve workere.
- Testirati funkcioniranje: Obrasce, prijenose i procese narudžbe provjeravamo nakon prelaska.
- Voditi do zakrpe: Putem usluge PHP zakrpe planiramo ažuriranje i prijelazne vrijednosti nakon toga kontrolirano vraćamo ondje gdje smetaju.
Česta pitanja
Štiti li zaobilazno rješenje potpuno od PHP2Shella?
Ne. php.net te mjere izričito naziva prijelaznima, a ne potpunom zaštitom. One smanjuju rizik dok se ažuriranje ne instalira. BSI preporučuje poslužitelje bez zakrpe privremeno isključiti s mreže.
Mogu li postavke zadati putem .htaccess ili .user.ini?
Za session.upload_progress.enabled php.net izričito isključuje ini_set() i .user.ini. I za memory_limit vrijedi: vrijednost mora biti postavljena tako da je aplikacija ne može nadjačati. To uspijeva u php.ini, u FPM poolu s php_admin_value ili u Apache konfiguraciji poslužitelja.
Je li web aplikacijski vatrozid dovoljan kao zaobilazno rješenje?
Kao dodatni sloj može pomoći. Cloudflare je uveo zaštitna pravila, ali i sam upozorava da pravila samo na temelju podataka zahtjeva nisu dovoljna. WAF ne zamjenjuje ni ažuriranje ni privremene mjere na poslužitelju.
Što učiniti ako imam samo shared hosting?
Tada php.ini i ponovno pokretanje ovise o pružatelju hostinga. Pitajte konkretno je li ažuriranje instalirano ili privremene mjere postavljene i jesu li svi PHP procesi ponovno pokrenuti.