Pe 17 octombrie, serverele-capcana pe care Amazon le tine deschise ca sa vada cine ataca au prins o tentativa de exploatare. Patru zile mai tarziu s-a aflat ce viza: doua vulnerabilitati in PHP despre care, oficial, publicul nu stia nimic.
Le-au botezat PHP2Shell. Numele spune tot. Un atacator fara cont si fara parola trimite o cerere HTTP construita cu grija si ajunge sa ruleze comenzi pe serverul tau. CVE-2026-109618 si CVE-2026-109619, ambele cu scor 9,2 din 10 pe CVSS v4.0.
Cum s-a ajuns la un patch de urgenta
Echipa PHP a facut ceva ce face rar. Pe 20 octombrie a anuntat public ca vine o actualizare critica, programata pentru a doua zi la 14:00 UTC, fara niciun detaliu despre ce repara. Un fel de "pregatiti-va, dar nu va spunem de ce". Doar ca in aceeasi zi detaliile au scapat pe internet, inainte de dezvaluirea coordonata. Pe 21 octombrie au iesit versiunile 8.5.12, 8.4.27, 8.3.36 si 8.2.35.
Ce a urmat se vede in cifrele Cloudflare: zeci de mii de tentative in primele 45 de minute dupa publicare, milioane pana in dimineata zilei urmatoare. Unit 42, echipa de cercetare a Palo Alto Networks, numara peste 22,6 milioane de instante expuse care ar putea fi vulnerabile.
(Am vazut destule alerte "critice" care s-au dovedit praf in ochi, bune doar de vandut licente. Asta nu e una dintre ele.)
Ce e stricat, pe scurt
Ambele probleme stau in nucleul PHP, nu intr-un plugin sau intr-un framework. Prima apare cand PHP ramane fara memorie in mijlocul unei cereri: procesul se opreste brusc, cu datele interne pe jumatate initializate, iar rutina de curatenie le trateaza apoi drept valide. A doua e mai perfida. O bucata de stare ramane agatata dupa ce memoria din spatele ei a fost eliberata, iar urmatoarea cerere procesata de acelasi worker o poate folosi.
Traducerea pentru cine nu scrie cod: aplicatia ta poate fi impecabila. WordPress la zi, pluginuri curate. Nu conteaza, gaura e dedesubt.
Echipa PHP spune explicit ca e expusa orice instalare care serveste cereri web, indiferent ca ruleaza prin PHP-FPM, ca modul Apache, prin php-cgi, FrankenPHP sau LiteSpeed. Riscul cel mai mare il vede la mod_php, unde exploit-ul demonstrat porneste inainte sa ruleze vreo linie din aplicatie.
Ce versiuni de PHP sunt afectate
Pe scurt, aproape toate. Google Cloud listeaza ca vulnerabile toate versiunile de la 5.4 pana la 8.5.11.
| Ramura PHP | Versiunea care repara | Ce mai trebuie stiut |
|---|---|---|
| 8.5 | 8.5.12 | Pe 8.5 exista o masura temporara suplimentara |
| 8.4 | 8.4.27 | - |
| 8.3 | 8.3.36 | - |
| 8.2 | 8.2.35 | Suportul se termina pe 31 decembrie 2026 |
| 8.1 si mai vechi | Nicio versiune oficiala | Doar patch-uri de sursa pentru 7.4, 8.0 si 8.1 |
Partea urata e coada tabelului. PHP 8.1 si tot ce e mai vechi nu mai primesc actualizari de la proiectul PHP. Din cauza gravitatii, echipa a publicat niste patch-uri minimale de sursa pentru 7.4, 8.0 si 8.1, dar ele ajuta doar pe cine isi compileaza singur PHP-ul. Iar daca ai un site pe PHP 5.6 sau 7.0 pe un server uitat intr-un colt, sa fim seriosi: problema ta nu e PHP2Shell. E serverul pe care nu l-a mai atins nimeni de ani de zile.
Am o parere ferma aici. Hostingul "ieftin si stabil" care ruleaza de cinci ani aceeasi versiune de PHP nu e stabil. E nesupravegheat.
Ce faci azi, in ordinea asta
Primul pas e sa afli ce ai. Multe companii au PHP pe server fara sa stie: formularul de contact al site-ului sau aplicatia interna facuta acum sapte ani de un colaborator care nu mai raspunde la telefon. Inventarul se face pe servere, nu din memorie.
# Linux - versiunea PHP din linia de comanda
php -v
# Windows cu IIS - versiunea binarului folosit de FastCGI
C:\PHP\php-cgi.exe -vAtentie la o capcana clasica. php -v iti arata versiunea din linia de comanda, iar serverul web poate folosi alt binar, alt pool FPM sau alt php.ini. Pe IIS, calea reala o gasesti in setarile FastCGI ale serverului, nu in ce ai crede tu ca e instalat.
Al doilea pas e update-ul propriu-zis. Daca PHP-ul vine din managerul de pachete al distributiei, iei de acolo pachetele noi: echipa PHP spune ca distributiile Linux si furnizorii de suport extins au primit patch-urile in avans, deci numarul versiunii poate arata altfel, cu reparatia inclusa. Daca esti pe hosting partajat cu cPanel sau Plesk, intrebi furnizorul, in scris, ce versiune ruleaza acum pe contul tau. Pe Windows cu IIS inlocuiesti folderul PHP cu build-ul nou Non Thread Safe de pe php.net.
Al treilea pas il sar multi, pe bune: restartul. Un proces php-cgi.exe sau un worker FPM pornit inainte de update ruleaza tot codul vechi. Pana nu repornesti serviciul sau application pool-ul, ai instalat patch-ul degeaba.
Daca nu poti face update azi
Exista situatii reale in care nu poti. O aplicatie veche care crapa pe versiunea noua, un furnizor care raspunde in trei zile. Pentru intervalul asta, echipa PHP a publicat masuri care reduc expunerea, cu precizarea ca nu fac instalarea sigura. Inchid doar caile de atac confirmate.
; in php.ini sau in configuratia pool-ului FPM
; nu prin ini_set() si nici prin .user.ini
session.upload_progress.enabled = 0
; doar pe PHP 8.5
fatal_error_backtraces = 0
; pentru aplicatii fara upload de fisiere
post_max_size = 8MMai e o recomandare oficiala, cu efecte secundare: memory_limit=-1, setat in asa fel incat aplicatia sa nu-l poata suprascrie. Scoate limita de memorie pe care se bazeaza prima vulnerabilitate, dar lasa o singura cerere sa manance toata memoria masinii. Fara limite puse la nivel de container sau de server web, schimbi un risc pe altul. Dupa orice modificare in php.ini, restart la fiecare worker.
Pe 23 octombrie a mai aparut o vulnerabilitate PHP, CVE-2026-115560. Echipa o considera putin probabila, fiindca cere o combinatie neobisnuita de configurare si cod. Masura e aceeasi: upload progress oprit. Daca l-ai oprit deja pentru PHP2Shell, n-ai nimic de facut.
Cum vezi daca ai fost deja vizitat
Patch-ul inchide usa. Nu-ti spune daca a intrat cineva intre 17 octombrie si ziua in care ai actualizat.
Semnul cel mai util e simplu de formulat: un proces PHP care porneste un shell. Un worker php-fpm, httpd sau php-cgi.exe care lanseaza bash, sh, cmd.exe sau powershell.exe nu face asa ceva intr-o zi normala. Daca ai un SIEM care colecteaza evenimentele de proces, o regula pe tiparul asta prinde exploatarea si atunci cand logurile serverului web arata curat. Uita-te si dupa fisiere .php noi in folderele de upload sau de cache, aparute dupa 17 octombrie.
Daca gasesti ceva, nu repari pe viu. Izolezi serverul, schimbi parola bazei de date si cheile de API din fisierele de configurare, apoi restaurezi dintr-o copie facuta inainte de 17 octombrie. Aici se vede daca strategia de backup exista doar pe hartie.
Partea care tine de management
Pentru companiile care intra sub NIS2, gestionarea vulnerabilitatilor nu e un moft al IT-ului. Directiva o trece explicit printre masurile minime de securitate. Iar un patch critic aplicat la doua saptamani dupa ce exploit-ul circula public pe GitHub e greu de explicat la un audit. Am scris separat despre cum prioritizezi patch-urile intr-un IMM. Logica e aceeasi, doar ca de data asta nu e marti si nu e Microsoft.
Cele 22,6 milioane de instante expuse nu inseamna 22,6 milioane de servere sparte. Inseamna tot atatia administratori care, saptamana asta, fie au dat un update, fie spera ca nu se uita nimeni la ei.
