Pe scurt: Cronologia PHP2Shell cuprinde până acum patru date confirmate: o primă tentativă de atac observată la 17.10, preanunțul php.net din 20.10, patchurile din 21.10, la ora 16:00 în Germania, și un alt anunț despre CVE-2026-115560 din 23.10.2026. Pentru operatori rezultă: aplicați patchul, reporniți toate procesele PHP și salvați logurile cel târziu începând cu 20.10.
De ce contează cronologia PHP2Shell pentru operatori
La o vulnerabilitate de o asemenea gravitate nu contează doar dacă serverul dumneavoastră este patchuit astăzi. Contează și cât timp a fost vulnerabil înainte. Această fereastră de timp stabilește ce loguri salvați, ce fișiere verificați și dacă puteți exclude pe bună dreptate o compromitere.
PHP2Shell afectează PHP însuși, nu un singur CMS. Două vulnerabilități critice, CVE-2026-109618 și CVE-2026-109619, permit executarea de cod malițios de la distanță, fără autentificare. Ambele sunt evaluate cu CVSS v4.0 9,2. O introducere ușor de înțeles găsiți la Ce este PHP2Shell?.
Cronologia următoare cuprinde doar date confirmate la 25.10.2026. Acolo unde o informație se bazează pe rapoarte din presă, acest lucru este menționat.
| Data | Eveniment | Temei |
|---|---|---|
| 17.10.2026 | Prima tentativă de atac observată (Amazon) | rapoarte din presă |
| 20.10.2026 | Preanunț al php.net | php.net |
| 21.10.2026, 14:00 UTC | Publicarea patchurilor (ora 16:00 în Germania) | php.net |
| 23.10.2026 | Anunț despre CVE-2026-115560 | php.net |
| 25.10.2026 | Data acestei prezentări | – |
17 octombrie: prima tentativă de atac observată
Potrivit rapoartelor din presă, la 17.10.2026 a fost observată o primă tentativă de atac, raportată de Amazon. Aceasta s-a întâmplat cu patru zile înainte de patchuri. A existat deci o perioadă în care se încercau deja atacuri, dar nu exista încă nicio actualizare.
Dacă și câte atacuri au reușit în această fază nu este confirmat. Important este ce urmează pentru propria dumneavoastră verificare: un server patchuit astăzi poate să fi fost compromis înainte. Un patch nu elimină software-ul malițios introdus și nu dovedește că înainte nu s-a întâmplat nimic.
20 și 21 octombrie: preanunțul și patchurile
La 20.10.2026 proiectul PHP a anunțat pe php.net actualizările de securitate. La 21.10.2026, ora 14:00 UTC, adică ora 16:00 în Germania, au urmat versiunile corectate.
| Ramură | Ultima versiune vulnerabilă | Corectat în |
|---|---|---|
| PHP 8.5 | 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.34 | 8.2.35 |
Pentru PHP 8.1 și mai vechi nu mai există actualizări oficiale, ci doar backporturi minime la nivel de sursă pentru 7.4, 8.0 și 8.1. Potrivit presei de specialitate, sunt afectate aproape toate versiunile până la PHP 5.4. Sunt afectate modurile de operare PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Cel mai mare risc îl vede echipa PHP la mod_php, unde a fost demonstrat un exploit înainte ca vreun cod al aplicației să ruleze.
Distribuțiile și furnizorii de hosting aplică uneori backporturi. În acest caz, de exemplu Plesk continuă să afișeze 8.2.34, deși serverul este patchuit. Contează starea pachetului și confirmarea furnizorului, nu numărul de versiune afișat. Cum verificați corect, aflați la Cum verificați corect versiunea PHP și starea patchului.
23 octombrie: anunțul despre CVE-2026-115560
La 23.10.2026 proiectul PHP a publicat un alt anunț, de data aceasta despre CVE-2026-115560. Potrivit acestuia, exploatarea este posibilă doar cu o configurare neobișnuită: în configurare apare serialize_handler php_binary sau php_serialize, aplicația îl comută pe php prin ini_set() înainte de session_start(), iar session upload progress este activ.
Măsura provizorie este simplă și ar trebui aplicată indiferent dacă cunoașteți sau nu această situație la dumneavoastră:
; în php.ini, în pool-ul FPM sau în configurația serverului
; nu prin ini_set() sau .user.ini
session.upload_progress.enabled = 0
Apoi reporniți toți workerii PHP. Anunțul complet urmează să apară cu următoarea versiune regulată de bugfix. Până atunci, setarea rămâne soluția provizorie recomandată.
Situația la 25 octombrie: starea lucrurilor și întrebări deschise
BSI (Oficiul Federal German pentru Securitatea Informațiilor) a emis nivelul de avertizare 3 / portocaliu. Recomandă actualizarea imediată și, dacă aceasta nu este posibilă imediat, scoaterea temporară a serverelor web din rețea. BSI se aștepta la o exploatare rapidă și pe scară largă; atacuri reușite confirmate, la scară largă, nu erau cunoscute inițial, potrivit BSI. Evaluarea BSI este rezumată pe pagina Ce recomandă BSI în privința PHP2Shell.
Cloudflare a raportat tentative de atac observate și a implementat reguli de protecție, dar avertizează că regulile bazate doar pe datele cererii nu sunt suficiente. Palo Alto Networks (Unit 42) a numărat peste 22,6 milioane de instanțe expuse, potențial vulnerabile. Indicators of Compromise confirmați nu au fost publicați; detecția se bazează pe analiza comportamentului.
Unii furnizori au scos site-uri offline ca măsură de precauție. Aceasta nu înseamnă automat că acele site-uri au fost hackuite. La data acestei prezentări rămâne deschisă mai ales întrebarea câte servere au fost efectiv compromise în perioada de dinainte de patch.
Ce înseamnă cronologia pentru logurile și verificările dumneavoastră
Din date rezultă trei perioade: înainte de 17.10, între 17.10 și propriul moment de patch și repornire, respectiv după aceea. Perioada de mijloc este cea critică. Cu cât a durat mai mult la dumneavoastră, cu atât mai temeinică ar trebui să fie verificarea.
Presa de specialitate recomandă păstrarea logurilor serverului începând cu 20.10.2026. Salvați și logurile mai vechi existente, înainte ca rotația automată să le șteargă.
O metodă simplă de a salva logurile nemodificate și de a consemna starea:
# Salvarea logurilor într-o arhivă (adaptați căile la sistemul dumneavoastră)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Sumă de control pentru dovada ulterioară
sha256sum /root/logs-sicherung-*.tar.gz
# Cât timp păstrează sistemul logurile?
grep -R "rotate" /etc/logrotate.d/
Notați, de asemenea, când exact a fost aplicată actualizarea și când au fost repornite procesele PHP. Fișierele noi nu protejează cât timp rulează procese vechi în memorie. Cum evaluați logurile salvate descrie ghidul Cum analizați logurile serverului web după un atac.
Cum ajută PHP SOS concret?
- Stabilim împreună cu dumneavoastră fereastra efectivă de vulnerabilitate a serverului: starea pachetelor, momentul patchului, repornirea tuturor workerilor.
- Salvăm logurile și starea sistemului într-un mod verificabil, înainte de a modifica ceva.
- Verificăm semnele de comportament neobișnuit, precum fișiere PHP noi, procese străine și conexiuni ieșite neobișnuite.
- Documentăm rezultatul astfel încât conducerea, responsabilii cu protecția datelor și asigurătorii să poată lucra cu el.
Procesul în detaliu îl descrie Asistența de urgență PHP2Shell.
Întrebări frecvente
Când au fost publicate patchurile PHP2Shell?
Proiectul PHP a publicat versiunile corectate la 21.10.2026, ora 14:00 UTC, adică ora 16:00 în Germania. Sunt corectate PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35.
De la ce dată ar trebui să păstrez logurile serverului?
Presa de specialitate recomandă păstrarea logurilor începând cu 20.10.2026. Deoarece, potrivit rapoartelor din presă, o primă tentativă de atac a fost observată deja la 17.10, merită să salvați și logurile mai vechi existente, înainte ca rotația să le șteargă.
Este CVE-2026-115560 la fel de periculoasă ca primele două vulnerabilități?
Potrivit anunțului din 23.10.2026, exploatarea este posibilă doar cu o configurare neobișnuită a sesiunilor. Ca măsură provizorie se recomandă session.upload_progress.enabled=0, până la apariția următoarei versiuni regulate de bugfix.
Există Indicators of Compromise confirmați pentru PHP2Shell?
Nu, la data de 25.10.2026 nu a fost publicat niciun Indicator of Compromise confirmat. Detecția se bazează pe analiza comportamentului, de exemplu procese neobișnuite, fișiere noi și conexiuni suspecte.