# Închideți imediat vulnerabilitatea de securitate PHP

> Vulnerabilitatea PHP este încă deschisă? Aplicăm patchul la distanță, repornim toate procesele și livrăm dovada. Sunați-ne sau scrieți-ne pe WhatsApp.

Sursa: https://phpsos.de/ro/soforthilfe/php-luecke-sofort-schliessen/  
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:** Cine vrea să aibă vulnerabilitatea PHP2Shell închisă chiar azi are nevoie de patru lucruri: actualizarea corectă, repornirea tuturor proceselor PHP, verificarea codului malițios deja introdus și o dovadă. Sunteți afectat? Sunați-ne. Vă ajutăm. Ne ocupăm de aceasta la distanță, de la primul mesaj.

> **Acționați imediat:**
> **Acum nu ștergeți nimic și nu reinstalați nimic.** Și la aplicarea patchului se aplică regula: mai întâi salvați, apoi modificați. Dacă a pătruns deja ceva, avem nevoie de starea fișierelor și a logurilor. [Anunțați urgența](https://phpsos.de/ro/notfall/), iar noi clarificăm împreună cu dumneavoastră ordinea.

## De ce vulnerabilitatea nu poate aștepta

Cele două vulnerabilități CVE-2026-109618 și CVE-2026-109619 se află în PHP însuși și permit cod malițios de la distanță, fără autentificare. BSI a declarat nivelul de avertizare 3 (portocaliu) și recomandă actualizarea imediată. Dacă aceasta nu este posibilă imediat, serverele web ar trebui scoase temporar din rețea. Potrivit rapoartelor din presă, au existat primele tentative de atac observate încă înainte de publicarea patchurilor, la 21.10.2026. Cloudflare a observat tentative și a lansat reguli de protecție, dar avertizează că regulile bazate doar pe datele cererii nu sunt suficiente.

Important pentru operatori: o actualizare a CMS-ului nu închide vulnerabilitatea PHP. Potrivit rapoartelor, nici WordPress.org nu planifică o actualizare împotriva ei, deoarece vulnerabilitatea se află în interpretor. Ea se închide doar la nivelul PHP, adică la ceea ce serverul dumneavoastră execută efectiv.

## Ce faceți imediat

1. **Cunoașteți versiunea țintă.** Sunt remediate PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. PHP 8.2 atinge la 31.12.2026 sfârșitul suportului; luați și aceasta în calcul.
2. **Cuprindeți toate sistemele.** Inclusiv serverele de test, imaginile de container și sistemele vechi accesibile din internet.
3. **Clarificați responsabilitatea.** La pachetele de hosting și la serverele administrate, aplică furnizorul. Întrebați în scris despre versiune și repornire.
4. **Păstrați logurile.** Începând cu 20.10.2026, potrivit presei de specialitate.
5. **Stabiliți fereastra de timp.** O repornire întrerupe scurt cererile în curs. Stabiliți un moment în care cineva poate lua decizii.
6. **Nu așteptați dacă este deschis.** Dacă nu se poate aplica imediat patchul, analizați cu noi izolarea sau măsurile provizorii.

## Cum ajută PHP SOS concret?

1. **Imaginea situației:** Cuprindem sistemele, versiunile PHP, modurile de operare, furnizorii de hosting și accesibilitatea și stabilim ordinea: mai întâi sistemele cele mai expuse.
2. **Salvare și închidere:** Salvăm starea actuală, aplicăm actualizarea sau aducem hostingul la starea dovedit corectată și repornim toate procesele. La containere reconstruim imaginea și o lansăm.
3. **Verificare și curățare:** Deoarece un patch nu elimină codul malițios, verificăm semnele unei intruziuni anterioare și curățăm la nevoie.
4. **Securizare și raport:** Primiți o dovadă scrisă pentru fiecare sistem și recomandări pentru ca următoarea actualizare să meargă mai repede. Oferta o descrie [serviciul de patch PHP](https://phpsos.de/ro/leistungen/php-patch-service/).

## Actualizare, repornire, dovadă: ce contează

Cea mai frecventă greșeală este o actualizare fără repornire. Atâta timp cât procesele vechi rulează în memorie, codul vulnerabil rămâne activ, chiar dacă fișierele sunt noi. Instrucțiunile se află pe pagina [Repornirea PHP-FPM și a tuturor workerilor](https://phpsos.de/ro/php2shell/php-fpm-neustart/). A doua greșeală este să dați crezare afișării: distribuțiile și furnizorii de hosting livrează adesea backporturi, iar atunci numărul versiunii rămâne același. De încredere este changelog-ul pachetului cu numerele CVE, în familia Debian cu `apt-get changelog <paket>`.

În plus, potrivit manualului PHP, de la versiunile de securitate se aplică noua directivă `memory_hard_limit_percent`. Dacă o versiune PHP nu o cunoaște, este afectată. Testul este scurt:

```bash
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
```

Trebuie rulat pentru fiecare versiune și mod de operare, deoarece linia de comandă poate folosi o altă versiune PHP decât serverul web. La final consemnăm rezultatul, pentru ca să-l puteți arăta furnizorului de hosting, asigurătorului sau clientului.

## Dacă actualizarea nu este posibilă imediat

Există motive pentru care o actualizare nu este posibilă azi: o aplicație veche care nu rulează pe versiuni PHP mai noi, un furnizor de hosting fără aprobare, o imagine de container într-un pipeline fix. Pentru aceste cazuri, php.net menționează măsuri provizorii care, în mod expres, nu sunt o protecție completă: setarea `memory_limit=-1` astfel încât aplicațiile să nu o poată suprascrie, limitarea `post_max_size`, `session.upload_progress.enabled=0` și, pe PHP 8.5, `fatal_error_backtraces=0`, fiecare cu repornire. La acestea se adaugă reguli de protecție la margine, care nu înlocuiesc o actualizare. Un sfat care circulă, de a bloca toate cererile cu `PHPSESSID`, este respins în mod expres de autorii de specialitate.

Ce măsuri se potrivesc sistemului dumneavoastră și ce pot strica discutăm înainte. Mai multe găsiți pe pagina [Măsuri imediate dacă nu puteți aplica încă patchul](https://phpsos.de/ro/php2shell/sofortmassnahmen-ohne-patch/) și la tema [WAF și patching virtual](https://phpsos.de/ro/leistungen/waf-virtuelles-patching/). Pentru PHP 8.1 și mai vechi se aplică o situație proprie, descrisă la [PHP 8.1 și mai vechi: ce se aplică acum](https://phpsos.de/ro/php2shell/php-8-1-und-aelter/).

## Ce ar trebui să ne trimiteți

- Lista serverelor și a furnizorilor de hosting, în măsura în care există
- Rezultatul comenzii `php -v` pentru fiecare sistem și indicarea modului de operare
- Indicarea dacă se folosesc containere, Plesk, cPanel sau o ofertă administrată
- Fereastra de timp dorită și o persoană de contact pentru reporniri
- Indicii despre orice neregulă de la 17.10.2026

## De ce PHP SOS

Lucrăm Made in Germany și suntem specializați în securitate IT de peste 25 de ani, împreună cu rețeaua noastră de parteneri din profesioniști cyber. Aveți un singur interlocutor, care însoțește actualizarea, verifică repornirea și livrează dovada. Lucrăm la distanță, fără deplasare, și documentăm fiecare pas. Nu promitem minuni: un patch închide vulnerabilitatea, dar nu dovedește că nu s-a întâmplat nimic înainte, și vă spunem și aceasta.

## Sunteți afectat? Sunați-ne. Vă ajutăm.

Nu lăsați vulnerabilitatea deschisă mai mult. Sunați-ne sau scrieți-ne pe WhatsApp. Preluăm cazul de la primul mesaj și rămânem alături până când incidentul este încheiat și documentat. [Anunțați acum urgența](https://phpsos.de/ro/notfall/).


## Întrebări frecvente

**Pot închide singur vulnerabilitatea de securitate PHP sau am nevoie de ajutor?**  
O actualizare este realizabilă pentru administratori, dar predispusă la erori: trebuie să se aplice versiunea care livrează efectiv, iar toate procesele trebuie repornite. Cine are mai multe servere, imagini de container sau un furnizor de hosting cu particularități economisește timp și erori cu sprijin.

**Trebuie repornit PHP după actualizare?**  
Da. Fișierele noi singure nu sunt suficiente atâta timp cât procesele PHP vechi rulează în memorie. Toți workerii, respectiv toate procesele, trebuie repornite; la mod_php, serverul web.

**Ce fac dacă nu există încă o actualizare pentru versiunea mea PHP?**  
Pentru PHP 8.1 și mai vechi, proiectul PHP nu mai livrează actualizări oficiale. Atunci sunt necesare un backport al furnizorului, dovedit ca fiind corectat, o migrare la o versiune întreținută sau măsuri provizorii, care însă nu oferă o protecție completă.

**Este suficient să setez session.upload_progress.enabled la 0?**  
Nu. Potrivit rapoartelor de specialitate, setarea singură nu închide ambele vulnerabilități; actualizarea PHP rămâne obligatorie. Setați-o doar în php.ini, în pool-ul FPM sau în configurația serverului, nu prin ini_set() sau .user.ini.

**De unde știu că vulnerabilitatea este cu adevărat închisă după aceea?**  
Printr-o dovadă pe sistemul care rulează: versiunea sau changelog-ul pachetului, un test pentru noua directivă memory_hard_limit_percent și confirmarea că toate procesele au fost repornite după actualizare.

## Surse

- [php.net: comunicate de securitate](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [Manualul PHP: configurația de bază (ini.core)](https://www.php.net/manual/en/ini.core.php)
- [BSI: Oficiul Federal German pentru Securitatea Informațiilor](https://www.bsi.bund.de/)