# WAF sau actualizare: de ce aveți nevoie de ambele

> WAF în loc de actualizare la PHP2Shell? Ce poate un Web Application Firewall, unde se oprește și de ce doar actualizarea PHP cu repornire închide breșa.

Sursa: https://phpsos.de/ro/blog/waf-oder-update/  
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:** WAF în loc de actualizare nu funcționează la PHP2Shell. Un Web Application Firewall, adică un filtru plasat înaintea site-ului, verifică cererile și poate bloca tipare de atac cunoscute. Breșa în sine se află însă în interpretorul PHP și dispare abia cu actualizarea și repornirea tuturor proceselor PHP. Un WAF este un strat suplimentar sensibil și o punte pentru câteva zile, nu soluția.

## De ce se pune întrebarea atât de des tocmai acum

Mulți operatori au citit în săptămâna PHP2Shell o veste aparent bună: Cloudflare are, potrivit propriilor declarații, reguli de protecție active din 21.10.2026, ora 03:02 UTC, inclusiv pentru clienții din planul gratuit. Cine oricum se află în spatele Cloudflare sau al altui WAF se întreabă, de înțeles, dacă actualizarea mai este urgentă.

Răspunsul sincer este da. Cloudflare însuși face o precizare: regulile bazate doar pe datele cererii nu sunt suficiente, de aceea serviciul verifică suplimentar răspunsul serverului. Cloudflare a observat, de asemenea, tipare de atac modificate. Iar protecția funcționează doar pentru traficul care trece efectiv prin Cloudflare. Detaliile acestui furnizor le descrie [Regulile de protecție Cloudflare împotriva PHP2Shell](https://phpsos.de/ro/blog/cloudflare-waf-php2shell/). Aici este vorba despre cântărirea de principiu, independent de furnizor.

## Ce vede un WAF și ce schimbă o actualizare

Un WAF se află înaintea aplicației. El vede fiecare cerere, o compară cu reguli și o lasă să treacă, o blochează sau o înregistrează. Nu știe cum prelucrează PHP intern cererea. Cele două breșe PHP2Shell apar însă exact acolo: CVE-2026-109618 într-o stare de memorie insuficientă (out-of-memory), în timp ce datele cererii sunt inițializate doar parțial, CVE-2026-109619 printr-o stare internă care persistă după o cerere în același worker.

Actualizarea corectează acest cod. După aceea cauza este eliminată, indiferent cum arată o cerere. Cine vrea să înțeleagă în ce punct al desfășurării unei cereri se întâmplă aceasta găsește bazele la [Ciclul de viață al cererii în PHP](https://phpsos.de/ro/php/request-lebenszyklus/).

## WAF în loc de actualizare: comparația sinceră

| Criteriu | Web Application Firewall | Actualizare PHP cu repornire |
|---|---|---|
| Ce se remediază? | Nimic, tiparele cunoscute sunt oprite | Cauza din interpretorul PHP |
| Protecție la variante noi de atac | Doar dacă regulile sunt adaptate la timp | Da, breșa nu mai există |
| Este posibilă ocolirea? | Da, de exemplu prin accesibilitatea directă a serverului de origine | Nu, cu condiția ca toate procesele PHP să fie repornite |
| Viteză | Adesea activ imediat | Depinde de versiune, acces și fereastra de mentenanță |
| Efecte secundare | Alarme false, formulare sau încărcări perturbate | Rare, la salturi de versiune sunt necesare teste de compatibilitate |
| Utilitate la următoarea breșă | Mare, dacă este întreținut | Niciuna, fiecare breșă are nevoie de propria actualizare |
| Ajută la PHP 8.1 și mai vechi? | Ca soluție de tranziție | Doar prin backport sau migrare |

Tabelul arată de ce cele două măsuri merg împreună. WAF-ul este rapid și larg, dar niciodată complet. Actualizarea este completă, dar doar pentru o anumită breșă și nu este întotdeauna posibilă imediat.

Un punct este adesea trecut cu vederea în practică: un WAF schimbă comportamentul site-ului. Regulile stricte pot bloca comenzi legitime, formulare de contact sau încărcări de fișiere, fără ca cineva să observe imediat. Cine activează în criză un WAF cu reguli stricte ar trebui de aceea să parcurgă el însuși o dată fluxurile principale ale site-ului și să verifice jurnalele primelor zile pentru cereri blocate, dar legitime.

## Cum le combinați sensibil pe ambele

1. **Imediat:** Verificați dacă există un WAF și dacă regulile potrivite sunt active. La Cloudflare, în planurile cu plată, potrivit furnizorului, setați Managed Ruleset pe Block.
2. **Imediat:** Asigurați-vă că serverul de origine este accesibil doar prin WAF, de exemplu prin permiterea în firewall doar a intervalelor lor de adrese. Altfel protecția rămâne în gol.
3. **În următoarea fereastră de mentenanță:** Actualizați PHP la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 sau instalați backportul confirmat al distribuției.
4. **Imediat după aceea:** Reporniți toți workerii și procesele PHP și verificați că nu mai rulează niciun proces vechi. Fișierele noi singure nu sunt suficiente; mai multe la [După actualizare: reporniți PHP-FPM și toți workerii](https://phpsos.de/ro/php2shell/php-fpm-neustart/).
5. **Apoi:** Păstrați regulile WAF, evaluați alarmele false și stabiliți excepții țintite în loc să dezactivați regulile în bloc.

Cu un WAF propriu, bazat pe ModSecurity și OWASP Core Rule Set, se poate obține ceva similar; bazele le descrie [Utilizarea ModSecurity și OWASP Core Rule Set](https://phpsos.de/ro/blog/modsecurity-owasp-crs/). O formă specială este filtrarea, propusă de autori de specialitate, a cererilor de upload în afara căilor reale de upload. Este neoficială, poate strica formulare și intră în exploatare doar după test.

> **Important:**
> Nici WAF-ul, nici actualizarea nu elimină software malițios introdus anterior. Verificați după patch dacă au apărut anomalii începând cu 17.10.2026.

## Când nu aveți nevoie de un WAF și când nu aveți nevoie de un furnizor de servicii

Un WAF nu este obligatoriu pentru fiecare site. Un mic site de firmă la un furnizor de hosting care aplică prompt patchuri PHP și confirmă acest lucru este adesea suficient protejat fără WAF propriu, dacă CMS-ul și pluginurile sunt actuale. Nici cine își poate actualiza singur serverul într-un timp scurt nu are nevoie de WAF ca punte.

Devine sensibil la magazine online, portaluri și aplicații cu multe formulare, la sisteme vechi care nu pot fi actualizate imediat și acolo unde mai multe site-uri trebuie protejate central. Aveți nevoie de un furnizor de servicii pentru aceasta doar dacă configurarea, testele și întreținerea continuă nu sunt acoperite intern.

## Cum ajută PHP SOS concret?

- Verificăm dacă WAF-ul dumneavoastră se află efectiv înaintea tuturor accesurilor și dacă serverul de origine este accesibil direct.
- Configurăm sau adaptăm reguli și testăm formularele, încărcările și interfețele pentru efecte secundare.
- Instalăm actualizarea PHP, repornim toate procesele și documentăm starea.
- Acolo unde actualizarea durează, facem puntea cu [WAF și virtual patching](https://phpsos.de/ro/leistungen/waf-virtuelles-patching/) și cu un termen fix pentru patchul real.

## Concluzie

Întrebarea „WAF sau actualizare” este pusă greșit. Actualizarea închide breșa, WAF-ul câștigă timp și oprește multe altele. Cine mizează doar pe WAF se bazează pe reguli pe care atacatorii le pot ocoli. Cine aplică doar patchuri rămâne la următoarea breșă din nou fără punte.


## Întrebări frecvente

**Este suficient un WAF ca protecție împotriva PHP2Shell?**  
Nu. Un WAF verifică traficul de date și poate bloca tipare de atac cunoscute. Breșa în sine se află în interpretorul PHP și rămâne până când PHP este actualizat și repornit. Cloudflare subliniază explicit că regulile sale nu înlocuiesc actualizarea.

**Sunt automat protejat în spatele Cloudflare?**  
Doar pentru traficul care trece efectiv prin Cloudflare. Dacă serverul de origine este accesibil direct din internet, protecția este ocolită. La planurile cu plată, potrivit Cloudflare, ar trebui să verificați că Managed Ruleset este setat pe Block.

**Merită un WAF și după actualizare?**  
Adesea da. Un WAF poate opri scanările în masă, atacurile cunoscute asupra pluginurilor și utilizarea abuzivă a paginilor de autentificare și câștigă timp la următoarea breșă. Are însă nevoie de întreținere și teste, altfel alarmele false deranjează activitatea.

**Ce este virtual patching?**  
Prin aceasta se înțelege protejarea temporară a unei vulnerabilități prin reguli plasate înaintea aplicației, în loc de modificarea codului. Este o punte până la actualizarea reală, nu un înlocuitor.

## Surse

- [Blogul Cloudflare](https://blog.cloudflare.com/)
- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)
- [php.net: avertizări de securitate](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)