# Sfaturi false periculoase despre PHP2Shell care circulă acum

> Sfaturi PHP2Shell verificate: ce recomandări care circulă nu protejează sau chiar dăunează și ce recomandă în schimb php.net, BSI și autorii de specialitate.

Sursa: https://phpsos.de/ro/blog/gefaehrliche-falschtipps/  
Stadiu: 25.10.2026  
Furnizor: PHP SOS, Asistență de urgență PHP și securitatea serverelor. Ajutor imediat pe WhatsApp: https://wa.me/491736494914?text=Bun%C4%83%20ziua%2C%20PHP%20SOS%2C%20avem%20nevoie%20de%20ajutor%20cu%20serverul%20nostru%20PHP.%20Firma%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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](https://phpsos.de/ro/blog/session-upload-progress-abschalten/). Lista completă a măsurilor provizorii se află la [Măsuri imediate fără patch](https://phpsos.de/ro/php2shell/sofortmassnahmen-ohne-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](https://phpsos.de/ro/blog/waf-oder-update/).

## 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:

1. **Sursa:** Provine recomandarea de la php.net, de la distribuția dumneavoastră, de la BSI sau de la un autor de specialitate numit?
2. **Pretenția:** Este măsura descrisă ca tranziție sau ca soluție? La PHP2Shell, doar actualizarea este o soluție.
3. **Efectul secundar:** Ce se strică atunci când măsura acționează? Un sfat fără indicație despre efecte secundare este incomplet.
4. **Locul aplicării:** Este setarea făcută la nivel de server și nu poate fi suprascrisă, urmată de o repornire a tuturor workerilor?

> **Important:**
> 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](https://phpsos.de/ro/leistungen/waf-virtuelles-patching/) 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.

## Surse

- [php.net: anunțuri de securitate](https://www.php.net/)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [Dr. Web: PHP2Shell și versiunile PHP](https://www.drweb.de/php2shell-update-php-versionen/)
- [Blogul Cloudflare](https://blog.cloudflare.com/)