# CVE-2026-109619: RCE prin stare globală învechită > CVE-2026-109619 explicat pe înțelesul tuturor: de ce starea internă între cereri devine periculoasă, ce versiuni PHP sunt remediate și cum vă protejați. Sursa: https://phpsos.de/ro/php2shell/cve-2026-109619/ 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:** CVE-2026-109619 este a doua vulnerabilitate din spatele PHP2Shell. Starea internă care aparține unei cereri poate persista după eliberarea memoriei; o cerere ulterioară din același worker o poate folosi înainte de a fi resetată. Consecința este execuția de cod fără autentificare. Remediul: actualizarea la PHP 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 și repornirea tuturor workerilor. ## Ce este CVE-2026-109619? CVE-2026-109619 (identificator GitHub GHSA-6wmf-4rv5-p3rp) este evaluată cu CVSS v4.0 9.2. Împreună cu [CVE-2026-109618](https://phpsos.de/ro/php2shell/cve-2026-109618/) formează PHP2Shell. Ambele vulnerabilități se află în PHP însuși și nu într-o aplicație. Efectul este același ca la vulnerabilitatea soră: un atacator poate executa cod pe server de la distanță, fără parolă și fără cont de utilizator. Cauza este însă alta. ## De ce este periculoasă starea învechită din worker Un server web PHP nu pornește un proces nou pentru fiecare cerere. La PHP-FPM, Apache cu mod_php, LiteSpeed sau FrankenPHP, un worker procesează una după alta multe cereri. Între două cereri, PHP își resetează starea internă, pentru ca nimic din cererea A să nu ajungă în cererea B. La CVE-2026-109619, această resetare nu reușește complet. Potrivit php.net, starea internă aparținând cererii poate persista după eliberarea memoriei. O cerere ulterioară din același worker poate folosi această stare învechită înainte de a fi resetată. Simplificat: ceva este reutilizat care, de fapt, nu mai este valid. Din punctul de vedere al exploatării, acest lucru este remarcabil. Reutilizarea workerilor este intenționată, pentru că face serverele web rapide: un worker nu trebuie repornit pentru fiecare cerere, să încarce extensii și să aloce memorie. Vulnerabilitatea lovește, așadar, o caracteristică pe care o are practic orice instalare PHP de producție. php.net nu menționează nicio configurație care să evite complet problema; de aceea calea trece prin actualizare. Detalii despre exploatare nu publicăm. Pentru operatori contează următorul lucru: orice mod de operare în care workerii deservesc mai multe cereri trebuie ținut sub observație, iar tocmai acestea sunt modurile obișnuite. ## Cele două vulnerabilități PHP2Shell, comparate | Caracteristică | CVE-2026-109618 | CVE-2026-109619 | |---|---|---| | Identificator GitHub | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp | | Evaluare | CVSS v4.0 9.2 | CVSS v4.0 9.2 | | Declanșator | Out-of-Memory în timpul inițializării datelor cererii | Starea internă persistă după eliberare | | Efect | execuție de cod fără autentificare | execuție de cod fără autentificare | | Remediat în | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Sunt afectate PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Cel mai mare risc îl vede echipa PHP la mod_php; de ce, explicăm la [De ce mod_php prezintă cel mai mare risc](https://phpsos.de/ro/php2shell/mod-php-risiko/). ## Închiderea CVE-2026-109619: actualizare, apoi repornirea tuturor workerilor Tocmai la această vulnerabilitate repornirea este decisivă. Cât timp workerii vechi rulează în memorie, serverul lucrează mai departe cu codul defectuos, chiar dacă fișierele noi sunt de mult pe disc. Verificați versiunea și starea pachetului. Numele pachetelor diferă în funcție de distribuție și de interfața furnizorului de hosting: ```bash php -v php-fpm8.3 -v # binarul FPM poate avea altă versiune decât CLI apt policy php8.3-fpm # Debian/Ubuntu dnf info php-fpm # familia RHEL rpm -q --changelog php-fpm | grep -i "CVE-2026-109619" ``` Apoi reporniți toate serviciile afectate: ```bash sudo systemctl restart php8.3-fpm # pentru fiecare versiune PHP instalată sudo systemctl restart apache2 # la mod_php; pe RHEL serviciul se numește httpd ``` Dacă distribuția sau furnizorul dumneavoastră de hosting aplică un backport, numărul de versiune afișat poate rămâne același. Atunci contează changelogul pachetului și confirmarea scrisă a furnizorului. O verificare pas cu pas găsiți la [Cum reporniți PHP-FPM și toți workerii](https://phpsos.de/ro/php2shell/php-fpm-neustart/). > **Sfat:** > Notați data și ora repornirii. Pentru evaluarea ulterioară, dacă un atac a avut loc înainte sau după patch, acest moment este cel mai important punct de referință. ## Ce mai rămâne de făcut după patch Un patch nu dovedește că înainte nu s-a întâmplat nimic. Potrivit rapoartelor din presă, o primă tentativă de atac a fost observată la 17 octombrie, cu patru zile înainte de patchuri. Păstrați logurile serverului începând cu 20 octombrie, așa cum recomandă presa de specialitate, și verificați serverul pentru anomalii. Indicații oferă pagina [Am fost deja compromis?](https://phpsos.de/ro/php2shell/bin-ich-gehackt-anzeichen/). Gândiți-vă la amploare: la o execuție reușită de cod, atacatorul are drepturile procesului PHP. Poate citi ce are voie să citească aplicația, de exemplu fișiere de configurare cu date de acces la baze de date sau chei API. Dacă un incident se confirmă, aceste date de acces trebuie reînnoite după curățare. ## Cum ajută PHP SOS concret? Prin [serviciul de patch PHP](https://phpsos.de/ro/leistungen/php-patch-service/) aplicăm corecția într-un mod ușor de urmărit: - **Inventariere:** ce versiuni și moduri de operare PHP rulează pe ce server și ce sursă de pachete le livrează? - **Patch:** actualizare din sursa corectă sau măsuri provizorii conform php.net, acolo unde actualizarea este încă blocată. - **Controlul repornirii:** verificăm proces cu proces că rulează doar versiunea corectată. - **Documentare:** versiuni, stări ale pachetelor și momente ale repornirii, pentru ca să puteți dovedi starea. ## Întrebări frecvente **Prin ce se deosebește CVE-2026-109619 de CVE-2026-109618?** CVE-2026-109618 apare când o stare Out-of-Memory întrerupe cererea în mijlocul inițializării. CVE-2026-109619 privește starea care rămâne în worker după încheierea unei cereri. Ambele duc la execuție de cod fără autentificare și sunt remediate în aceleași versiuni PHP. **Ajută dacă repornesc workerii PHP-FPM mai des?** Ca înlocuitor al actualizării nu este potrivit. php.net nu menționează repornirile mai dese ale workerilor ca măsură provizorie. Workerii trebuie totuși reporniți după actualizare, pentru ca versiunea corectată să ruleze efectiv. **Sunt protejat împotriva CVE-2026-109619 printr-o actualizare CMS?** Nu. Vulnerabilitatea se află în PHP și nu în WordPress, Shopware, TYPO3 sau alt sistem. Doar o actualizare PHP sau un backport confirmat de furnizor o închide. **Există urme cunoscute ale unui atac prin CVE-2026-109619?** Indicators of Compromise confirmați nu au fost publicați până acum. Detecția se bazează pe analiza comportamentului, de exemplu fișiere PHP noi, conexiuni neobișnuite spre exterior sau cronjoburi necunoscute. ## Surse - [php.net: anunțuri de securitate](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [BSI: Oficiul Federal German pentru Securitatea Informațiilor](https://www.bsi.bund.de/)