Pe scurt: Multe sfaturi despre PHP2Shell care circulă acum în forumuri și rețele sociale nu protejează sau chiar dăunează: blocarea cererilor cu cookie de sesiune, ascunderea mesajelor de eroare, setarea de valori prin .user.ini sau actualizarea doar a CMS-ului. php.net este clar: nu există măsuri provizorii complete, iar actualizarea PHP cu repornirea tuturor proceselor este singura cale sigură.
De ce sunt periculoase sfaturile false în această situație
La o vulnerabilitate critică, cu mare atenție publică, apare o piață pentru soluții rapide. Sfaturile sunt distribuite, prescurtate și transmise mai departe, adesea fără limitările sursei inițiale. La PHP2Shell se adaugă faptul că detaliile au devenit cunoscute, potrivit relatărilor, încă înainte de data oficială, iar situația a fost neclară în primele zile.
Un sfat greșit dăunează dublu. Lasă vulnerabilitatea deschisă și creează senzația că ați făcut ceva. Exact această senzație duce la amânarea actualizării propriu-zise. Unele sfaturi paralizează în plus propriul site.
Nouă sfaturi verificate
Tabelul următor rezumă ce am citit frecvent în ultimele zile și confruntă afirmațiile cu cele ale surselor primare.
| Sfat care circulă | De ce nu rezistă | Ce se aplică în schimb |
|---|---|---|
Blocați toate cererile cu PHPSESSID |
Respins explicit de autorii de specialitate; paralizează autentificările și coșurile de cumpărături | Actualizați PHP |
session.upload_progress.enabled=0 este suficient |
Potrivit relatărilor de specialitate, nu închide ambele vulnerabilități | Măsură provizorie utilă, actualizarea rămâne obligatorie |
Setați valorile prin ini_set() sau .user.ini |
php.net descurajează explicit | La nivel de server în php.ini, pool FPM sau configurația serverului |
| Ascundeți mesajele de eroare | Potrivit php.net, error_reporting, display_errors sau @ nu ajută |
Actualizare; nu afișați totuși public ieșirea de erori |
Limitați memoria prin RLIMIT_AS sau RLIMIT_DATA |
php.net avertizează că tocmai acest lucru poate declanșa situația vulnerabilă | Limită prin container sau cgroup |
| Actualizați WordPress sau pluginurile | Vulnerabilitatea se află în interpretorul PHP, nu în CMS | Actualizați mediul de execuție PHP |
| Cloudflare sau alt WAF este suficient | Protecție doar pentru traficul prin serviciu; serverele accesibile direct rămân deschise | WAF ca strat suplimentar, nu ca înlocuitor |
| Reîncărcați serviciul în loc să îl reporniți | Potrivit Red Hat, o reîncărcare nu este suficientă, workerii existenți pot păstra starea veche | Reporniți complet toți workerii |
| Actualizat înseamnă curat | Un patch nu elimină software malițios introdus înainte | Salvați logurile începând cu 20.10. și căutați urme |
Cele trei neînțelegeri cele mai frecvente, explicate mai detaliat
Interdicția cookie-urilor
Sfatul de a respinge toate cererile cu cookie-ul de sesiune PHPSESSID sună tehnic și hotărât. Autorii de specialitate îl resping explicit. În practică, strică tot ce are nevoie de o sesiune: conturi de clienți, coșuri de cumpărături, zone de administrare, formulare cu protecție împotriva falsificării. Nu este o protecție împotriva vulnerabilității.
Singura setare care rezolvă totul
session.upload_progress.enabled=0 se află în recomandările php.net și este remediul menționat împotriva CVE-2026-115560. În unele articole, de aici s-a făcut „PHP2Shell dezactivat”. Potrivit relatărilor de specialitate, această setare singură nu închide însă ambele vulnerabilități. Și memory_limit=-1 elimină, potrivit php.net, doar declanșatorul controlabil; o eroare de memorie la un nivel mai profund poate ajunge în continuare la calea vulnerabilă. Pe PHP 8.5, fatal_error_backtraces=0 blochează, potrivit php.net, doar calea confirmată prin backtrace-uri.
Cum setați totuși corect și durabil această setare descrie articolul Dezactivarea session.upload_progress. Lista completă a măsurilor provizorii se află la Măsuri imediate fără patch.
Scutul din față
Cloudflare are active, potrivit propriilor declarații, din 21 octombrie reguli de protecție, inclusiv pentru clienții din planul gratuit. Cloudflare însuși atrage însă atenția asupra limitelor: protecția se aplică doar traficului care trece prin Cloudflare. Dacă serverul de origine este accesibil direct, protecția este ocolită. În plus, Cloudflare verifică suplimentar răspunsul serverului, deoarece cererea singură nu este întotdeauna suficientă. De ce un WAF nu înlocuiește actualizarea explică articolul WAF sau actualizare.
Un sfat cu risc: filtrarea cererilor de upload la margine
Nu orice sfat incomod este greșit. Autorii de specialitate propun, ca măsură provizorie, neoficială, blocarea cererilor multipart/form-data în afara căilor reale de upload, la proxy sau în WAF. Aceasta poate reduce suprafața de atac, dar strică formularele și upload-urile dacă lista căilor permise este incompletă.
Cine alege această cale ar trebui să o verifice dinainte într-un mediu de test, să o coordoneze cu departamentele de specialitate și să o documenteze ca măsură cu termen limitat. Nici ea nu este un înlocuitor al actualizării.
Multe soluții WAF oferă pentru aceasta un mod de observare, în care regulile doar înregistrează în jurnal în loc să blocheze. Lăsați o regulă nouă să ruleze astfel câteva zile și analizați ce cereri legitime ar fi afectate. Abia după aceea comutați pe blocare. Astfel evitați ca formularele de candidatură, portalurile pentru clienți sau încărcarea de imagini din magazin să cedeze neobservat.
Cum verificați un sfat înainte de a-l aplica
Patru întrebări separă sfaturile utilizabile de cele periculoase:
- Sursa: Provine recomandarea de la php.net, de la distribuția dumneavoastră, de la BSI sau de la un autor de specialitate numit?
- Pretenția: Este măsura descrisă ca tranziție sau ca soluție? La PHP2Shell, doar actualizarea este o soluție.
- Efectul secundar: Ce se strică atunci când măsura acționează? Un sfat fără indicație despre efecte secundare este incomplet.
- Locul aplicării: Este setarea făcută la nivel de server și nu poate fi suprascrisă, urmată de o repornire a tuturor workerilor?
Consemnați ce măsuri provizorii ați setat și când. Astfel le puteți verifica ulterior țintit și puteți recunoaște dacă o presupusă protecție a întârziat actualizarea propriu-zisă.
Cum ajută PHP SOS concret?
- Verificăm măsurile care au fost deja puse în aplicare la dumneavoastră și separăm cele eficiente de cele fără efect.
- Instalăm actualizarea PHP, repornim toate procesele și dovedim starea.
- Acolo unde o actualizare nu este încă posibilă, setăm măsuri provizorii conform php.net, la nivel de server și documentate.
- Cu WAF și patch virtual completăm protecția la margine, fără a înlocui actualizarea.
Întrebări frecvente
Protejează blocarea cererilor cu PHPSESSID?
Nu. Autorii de specialitate resping explicit acest sfat care circulă. El paralizează autentificările, coșurile de cumpărături și formularele, fără să închidă vulnerabilitatea din interpretor.
Este suficient session.upload_progress.enabled=0 împotriva PHP2Shell?
Nu. Setarea este una dintre mai multe măsuri provizorii și, potrivit relatărilor de specialitate, nu închide ambele vulnerabilități. Este utilă, dar nu înlocuiește actualizarea PHP.
Ajută dezactivarea display_errors?
Pentru PHP2Shell nu. php.net atrage atenția că ascunderea diagnosticelor prin error_reporting, display_errors sau operatorul @ nu ajută. În producție, display_errors ar trebui totuși să fie dezactivat din alte motive.
Cum recunosc un sfat serios?
Un sfat serios își menționează sursa, descrie limite și numește măsurile provizorii ca atare. Cine promite că o singură setare face actualizarea inutilă greșește la PHP2Shell.