Pe scurt: O soluție provizorie pentru vulnerabilitatea PHP2Shell poate reduce riscul, dar nu înlocuiește actualizarea. php.net menționează pentru aceasta limite fixe de memorie și de încărcare, dezactivarea session upload progress și, la PHP 8.5, fatal_error_backtraces=0. Dacă nici aceasta nu este posibilă pe termen scurt, BSI recomandă scoaterea temporară din rețea a serverului web.
Ce poate face o soluție provizorie și ce nu
Măsurile provizorii de la php.net trebuie să îngreuneze condițiile în care vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 pot fi exploatate. Ele sunt în mod expres o protecție incompletă. Vulnerabilitățile sunt remediate doar în PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35 sau într-un backport confirmat al furnizorului dumneavoastră.
Măsurile sunt utile atunci când actualizarea nu este încă posibilă dintr-un motiv concret: o fereastră de mentenanță este încă în așteptare, o aplicație trebuie mai întâi testată sau operați PHP 8.1 sau mai vechi, pentru care nu mai există actualizare oficială. Ele sunt atunci o punte, nu un scop.
Planificați, de aceea, odată cu soluția provizorie și actualizarea: cine o realizează, în ce fereastră de mentenanță și cine verifică după aceea că toți workerii au fost reporniți? O tranziție fără dată de încheiere riscă să devină o stare permanentă.
Opțiunea 1: scoaterea temporară a serverului din rețea
BSI a emis nivelul de avertizare 3 (portocaliu) și recomandă scoaterea temporară din rețea a serverelor web afectate, dacă actualizarea nu este posibilă imediat. Unii furnizori au făcut acest lucru preventiv; asta nu înseamnă că acele site-uri au fost hackuite.
Pentru multe companii, o indisponibilitate a magazinului sau a portalului este costisitoare. O cântărire poate fi utilă: acces doar prin VPN sau adrese IP aprobate, o pagină statică de mentenanță în locul aplicației PHP sau oprirea unor site-uri individuale, nenecesare, de pe server. Cu cât este mai puțin PHP accesibil din exterior, cu atât suprafața de atac este mai mică.
Important este ca decizia să fie luată în mod conștient și consemnată: cine a decis și când să lase serverul online și cu ce măsuri de protecție? Asta ajută ulterior în raport cu asigurătorul, protecția datelor și conducerea.
Măsurile provizorii de la php.net
| Măsură | Valoare | Observație |
|---|---|---|
memory_limit |
-1, fără posibilitate de suprascriere |
limita de memorie se setează apoi prin container sau cgroup |
post_max_size |
8M fără încărcări, 32M cu încărcări |
upload_max_filesize sub aceasta |
| Limită de memorie | prin container/cgroup | nu prin RLIMIT_AS sau RLIMIT_DATA |
session.upload_progress.enabled |
0 |
în php.ini, pool sau configurația serverului, nu prin ini_set() sau .user.ini |
fatal_error_backtraces |
0 |
doar PHP 8.5 |
Setarea session.upload_progress.enabled=0 este totodată remediul pentru vulnerabilitatea CVE-2026-115560, raportată la 23 octombrie.
Cum setați corect soluția provizorie pentru vulnerabilitatea PHP
Decisiv este locul. Valorile trebuie setate astfel încât o aplicație să nu le poată suprascrie. Căile și numele serviciilor diferă în funcție de distribuție; exemplele pornesc de la PHP 8.3.
PHP-FPM, în pool (de ex. /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
; doar PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache cu mod_php, în configurația serverului sau în 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
Limită de memorie prin cgroup, aici prin systemd pentru serviciul FPM. Valoarea o adaptați serverului dumneavoastră:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Apoi reporniți toți workerii, altfel nu acționează nimic din toate acestea: systemctl restart php8.3-fpm sau, la mod_php, Apache. Cum verificați că nu mai rulează niciun proces vechi aflați la Cum reporniți PHP-FPM și toți workerii. Securizarea generală a configurației o descrie Cum configurați sigur php.ini.
Testați încărcările de fișiere și formularele mari după trecere. Un post_max_size prea mic poate bloca comenzi, formulare de candidatură sau încărcări de media. Este un motiv să nu amânați mult actualizarea.
Straturi suplimentare de protecție
Un Web Application Firewall sau patchingul virtual poate ajuta ca strat în plus. Cloudflare a implementat reguli de protecție, dar avertizează chiar el că regulile bazate doar pe datele cererii nu sunt suficiente. Un WAF este, de aceea, o completare, nu un înlocuitor. Mai multe la WAF și patching virtual.
Salvați în plus logurile serverului începând cu 20 octombrie. Potrivit rapoartelor din presă, o primă tentativă de atac a fost observată deja la 17 octombrie; logurile sunt baza, dacă mai târziu trebuie clarificat dacă înainte de patch s-a întâmplat ceva.
Cum ajută PHP SOS concret?
- Clarificarea situației: Verificăm dacă o actualizare este posibilă pe termen scurt sau dacă este necesară o tranziție și discutăm cu dumneavoastră opțiunea de a scoate părți din rețea.
- Setarea măsurilor: Introducem valorile de la php.net în locul potrivit, setăm limita cgroup și repornim toți workerii.
- Testarea funcționării: După trecere verificăm formularele, încărcările și procesele de comandă.
- Drumul spre patch: Prin serviciul de patch PHP planificăm actualizarea și retragem apoi, în mod controlat, valorile provizorii acolo unde deranjează.
Întrebări frecvente
Mă protejează complet soluția provizorie de PHP2Shell?
Nu. php.net numește măsurile în mod expres provizorii și nu o protecție completă. Ele reduc riscul până la aplicarea actualizării. BSI (Oficiul Federal German pentru Securitatea Informațiilor) recomandă scoaterea temporară din rețea a serverelor fără patch.
Pot seta setările prin .htaccess sau .user.ini?
Pentru session.upload_progress.enabled, php.net exclude în mod expres ini_set() și .user.ini. Și pentru memory_limit se aplică: valoarea trebuie setată astfel încât aplicația să n-o poată suprascrie. Aceasta reușește în php.ini, în pool-ul FPM cu php_admin_value sau în configurația serverului Apache.
Este suficient un Web Application Firewall ca soluție provizorie?
Ca strat suplimentar poate ajuta. Cloudflare a implementat reguli de protecție, dar subliniază chiar el că regulile bazate doar pe datele cererii nu sunt suficiente. Un WAF nu înlocuiește nici actualizarea, nici măsurile provizorii de pe server.
Ce fac dacă am doar hosting partajat?
Atunci php.ini și repornirea se află la furnizorul de hosting. Întrebați concret dacă actualizarea a fost aplicată sau măsurile provizorii setate și dacă toate procesele PHP au fost repornite.