Pe scurt: Patchingul virtual pentru PHP acoperă timpul până la aplicarea actualizării reale. Combinăm pentru aceasta regulile unui Web Application Firewall cu măsurile provizorii publicate de php.net pentru PHP2Shell și stabilim de la început calea spre patchul obișnuit. Nu oferă protecție completă, dar reduce riscul în perioada de tranziție.
Când este util patchingul virtual pentru PHP
BSI (Oficiul Federal German pentru Securitatea Informațiilor) recomandă în cazul PHP2Shell actualizarea imediată și, dacă aceasta nu este posibilă, scoaterea temporară din rețea a serverelor web. Pentru multe companii, niciuna dintre cele două nu este realizabilă imediat: un magazin trebuie să rămână accesibil, o dezvoltare proprie are nevoie de un test înainte de actualizare sau serverul rulează cu PHP 8.1 și mai vechi, pentru care nu mai există actualizări oficiale.
În aceste cazuri, patchingul virtual este o punte. Nu înlocuiește decizia dacă o funcționare offline ar fi mai potrivită. Această cântărire o faceți dumneavoastră, noi oferim evaluarea tehnică.
De ce un WAF singur nu este suficient
Cloudflare a raportat tentative de atac observate și a implementat reguli de protecție, dar avertizează că regulile bazate doar pe datele cererii nu sunt suficiente. Motivul stă în natura vulnerabilităților. La CVE-2026-109618, o stare Out-of-Memory poate întrerupe PHP în timp ce datele cererii sunt inițializate doar parțial. La CVE-2026-109619, starea internă poate persista după eliberarea memoriei și poate fi folosită de o cerere ulterioară în același worker. Asemenea erori depind de starea serverului, nu doar de conținutul unei singure cereri.
De aceea mizăm pe mai multe straturi: reguli WAF în fața serverului, măsuri provizorii în PHP însuși și o observare întărită a serverului. Fiecare strat oprește o parte, niciunul nu este suficient singur. Împreună vă oferă timpul necesar pentru a aplica actualizarea în mod ordonat.
Măsurile provizorii conform php.net
php.net menționează mai multe setări care reduc riscul, în mod expres fără protecție completă. Important este ca aplicațiile să nu poată suprascrie aceste valori. Un exemplu pentru un pool PHP-FPM cu încărcări de fișiere:
; măsuri provizorii PHP2Shell (fără protecție completă), apoi reporniți toți workerii
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; doar PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Fără încărcări de fișiere, php.net recomandă post_max_size = 8M. Deoarece memory_limit este ridicat, face parte din măsuri o limită de memorie la nivel de container sau cgroup, nu prin RLIMIT_AS sau RLIMIT_DATA. Setarea session.upload_progress.enabled=0 aparține în php.ini, în pool-ul FPM sau în configurația serverului, nu în ini_set() sau .user.ini. Ea este totodată remediul pentru indicația privind CVE-2026-115560. Toate măsurile, pe scurt, găsiți la Măsuri imediate dacă nu puteți încă aplica patchul.
Măsurile provizorii au efect abia după repornirea tuturor workerilor PHP. Și protejează doar împotriva atacurilor viitoare: dacă a pătruns cineva înainte, ele nu răspund.
Când funcționarea offline este alegerea mai bună
Patchingul virtual nu este răspunsul potrivit în orice situație. În unele configurații recomandăm să urmați BSI și să scoateți temporar serverul web din rețea până la aplicarea patchului:
- serverul rulează cu Apache și mod_php, unde echipa PHP evaluează riscul ca fiind cel mai ridicat și unde un exploit a fost demonstrat înainte ca vreun cod de aplicație să ruleze
- pe server se află date deosebit de sensibile, de exemplu date de sănătate, ale clienților unui cabinet sau de plată
- nu există nicio posibilitate de a fixa măsurile provizorii în configurația serverului, de exemplu la anumite pachete de hosting partajat
- există deja semne că serverul a fost atacat
O funcționare offline temporară nu înseamnă că site-ul dumneavoastră a fost hackuit. Unii furnizori au scos site-uri offline din precauție. O scurtă pagină de informare, obiectivă, pentru vizitatori este atunci de regulă soluția mai bună decât o indisponibilitate neexplicată.
Cum ajută PHP SOS concret?
- Verificarea situației: Inventariem versiunile PHP, modurile de operare și straturile de protecție existente, precum CDN, WAF sau reverse proxy. La mod_php indicăm riscul crescut pe care îl vede acolo echipa PHP.
- Construirea straturilor: Activăm sau completăm regulile WAF, fixăm măsurile provizorii în configurația serverului și limităm memoria prin container sau cgroup. Pentru configurații Nginx ne orientăm după Cum securizați Nginx cu PHP-FPM.
- Repornire și test: Toate procesele PHP sunt repornite, apoi verificăm încărcările de fișiere, formularele, autentificarea și finalizarea comenzii.
- Observare: În perioada de tranziție urmărim mai atent prăbușirile workerilor, vârfurile de memorie și procesele neobișnuite.
- Planificarea patchului: Stabilim când și cum vine actualizarea obișnuită și o realizăm prin serviciul de patch PHP.
Ce primiți, de ce avem nevoie și ce nu promitem
Primiți o documentație a tuturor regulilor și setărilor aplicate, cu motivare, rezultatele testelor și un plan de termene și măsuri pentru patchul real. De la dumneavoastră avem nevoie de acces la server sau la panou, acces la CDN sau WAF, dacă există, un interlocutor tehnic și informații despre funcțiile de încărcare ale aplicațiilor dumneavoastră.
Nu promitem că patchingul virtual previne un atac. El reduce riscul pe o perioadă limitată. La PHP 8.1 și versiuni mai vechi nu este o stare permanentă; aici migrarea la o versiune susținută trebuie să intre în plan.
Întrebări frecvente
Ce este patchingul virtual?
Patchingul virtual înseamnă protejarea unei vulnerabilități cunoscute în fața aplicației, în loc să se modifice codul în sine. Aceasta se face de regulă printr-un Web Application Firewall sau prin modificări de configurație. Este o punte, nu un înlocuitor al actualizării.
Este suficient WAF-ul furnizorului meu de CDN împotriva PHP2Shell?
În general nu, singur. Cloudflare a implementat reguli de protecție, dar avertizează chiar el că regulile bazate doar pe datele cererii nu sunt suficiente. WAF-ul este un strat suplimentar alături de măsurile provizorii și de patch.
Cât timp mă pot baza pe patchingul virtual?
Cât mai puțin posibil. El trebuie să acopere timpul până la actualizarea obișnuită, de exemplu până când se eliberează o fereastră de mentenanță sau până când o aplicație a fost testată. La PHP 8.1 și versiuni mai vechi face parte din proces un plan de migrare.
Pot măsurile provizorii să-mi perturbe site-ul?
Da, este posibil. Limitele mai mici de încărcare pot împiedica încărcările de fișiere mari, iar dezactivarea session upload progress afectează indicatoarele de progres la încărcare. Testăm funcțiile cele mai importante după fiecare modificare.