Awarely Monitor
AwarelyMonitor
Toate articolele
Vulnerabilități exploatate8 min

PHP2Shell: CVE-2026-109618 și 109619, fixuri de la 14:00 UTC

PHP a publicat pe 21 octombrie 2026 un aviz de securitate pentru două vulnerabilități critice de execuție de cod de la distanță, CVE-2026-109618 și CVE-2026-109619, cunoscute ca „PHP2Shell”, ambele cu scor CVSS 4.0 de 9,2. Fixurile au apărut pe 21 octombrie, de la ora 14:00 UTC: PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Detaliile ajunseseră publice cu o zi înainte, iar mai multe surse raportează tentative de exploatare.

Fiindcă PHP rulează aplicații web, panouri de control, CMS-uri și aparate de la furnizori, prima sarcină nu este patch-ul, ci răspunsul la întrebarea „unde avem PHP?”. Mai jos separăm ce confirmă PHP și NCSC de ce raportează cercetătorii și ce rămâne contradictoriu.

Ce confirmă PHP și NCSC

Avizul PHP din 21 octombrie („Critical remote code execution vulnerabilities, update now”) descrie două defecte. CVE-2026-109618: tratarea erorilor de memorie insuficientă poate întrerupe PHP când datele interne ale cererii sunt doar parțial inițializate, iar curățarea cererii le tratează apoi ca valide. CVE-2026-109619: starea internă a unei cereri poate supraviețui eliberării memoriei, iar o cerere ulterioară pe același worker o poate folosi. Ambele pot permite execuție de cod neautentificată.

PHP spune că toate instalările care servesc cereri web sunt expuse, inclusiv PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed, iar riscul este cel mai mare la mod_php, unde există un exploit demonstrat în care o cerere neautentificată declanșează atacul înainte de rularea codului aplicației. NCSC din Regatul Unit spune că problema „poate permite atacatorilor să execute comenzi pe orice server web care rulează PHP” și îndeamnă la acțiune imediată. Avizul PHP nu listează versiunile afectate; listează versiunile corectate.

Cronologie, în UTC

  • ▸20 octombrie: detaliile ajung publice înainte de dezvăluirea coordonată. Potrivit Huntress, o postare dispărută ulterior a circulat prin capturi de ecran, iar watchTowr a confirmat scurgerea în câteva ore. Tot pe 20 octombrie, PHP anunță un release de urgență, cu o zi înainte de embargoul inițial.
  • ▸21 octombrie, 07:43: Cloudflare raportează primele atacuri asupra site-urilor PHP și activează reguli WAF, potrivit Sansec.
  • ▸21 octombrie, 14:00: PHP publică versiunile corectate. Huntress notează lansarea la circa 13:30 UTC, iar Sansec la 14:00; avizul PHP spune că lansarea fusese programată pentru 14:00 UTC.

Ce diferă între surse

Exploatarea: Sansec relatează atacuri timpurii observate de Cloudflare, watchTowr spune că a văzut exploatare pe rețeaua sa de honeypot-uri, Huntress nu vedea exploatare în baza sa de parteneri la 14:00 UTC, iar Sophos și Unit 42 nu raportau exploatare confirmată. Aceste observații nu se contrazic neapărat, fiindcă vin din medii diferite, dar nu pot fi adunate într-o cifră. PoC-ul: Unit 42 spune că a văzut cod de exploatare, Sophos citează un utilizator care pretinde că a construit unul funcțional, fără să-l confirme, iar Huntress nu știa de un PoC public.

Versiunile afectate: înainte de patch, rapoartele vorbeau despre PHP 5 până la 8. Sansec spune că cel mai vechi cod afectat datează din PHP 5.4.0, iar NCSC spune „orice versiune”. Linia oficială acoperă doar 8.2 și mai noi. Pentru 8.1 și mai vechi, PHP spune că nu mai primește actualizări de la proiect, dar a publicat copii minimale ale corecțiilor în sursă pentru 7.4, 8.0 și 8.1, iar unele distribuții și furnizori LTS oferă backporturi. Unit 42 numără peste 22,6 milioane de instanțe expuse potențial vulnerabile, prin telemetria Cortex Xpanse; este o estimare a expunerii, nu o cifră de compromiteri.

Nu am putut citi pagina Plesk privind PHP livrat cu Plesk (403); o căutare o rezumă ca listând PHP 7.4–8.1 afectat și fără patch încă. Verifică direct la Plesk, la distribuția ta sau la furnizorul aparatului.

Găsește tot PHP-ul

  • ▸Inventariază toate instalările PHP, începând cu cele accesibile din Internet. NCSC cere să nu te limitezi la versiunile vechi.
  • ▸Include PHP livrat în pachet: panouri de control, aparate și servicii de la furnizori și CMS-uri precum WordPress, Drupal, Joomla sau Magento. Huntress notează că PHP-ul din aceste produse e vizat la fel.
  • ▸Notează versiunea exactă, SAPI-ul (mod_php, FPM, FrankenPHP, LiteSpeed, php-cgi) și cine administrează instalarea. NCSC-NL publică un inventar de produse cu dependențe PHP potențial afectate.
  • ▸Pentru PHP 5, 7, 8.0 și 8.1, decide acum: upgrade la o versiune suportată, backport de la distribuție sau LTS, sau izolare în spatele unui VPN ori WAF, cum recomandă Huntress.

Actualizează, apoi atenuează ce nu poți actualiza

Actualizează la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35, începând cu sistemele expuse. Distribuțiile Linux și furnizorii LTS au primit corecțiile în avans, deci verifică pachetele lor; Huntress notează că repository-ul Remi nu avea încă pachete actualizate pe 21 octombrie. PHP 8.2 ajunge la sfârșitul vieții pe 31 decembrie 2026, deci o țintă de 8.2 ține doar temporar.

Dacă nu poți actualiza imediat, avizul PHP listează mitigări pe care le descrie ca reducând expunerea, fără să facă instalarea sigură. Pentru CVE-2026-109618: memory_limit=-1 setat cu php_admin_value, post_max_size mic, limite de cerere la serverul web sau proxy (dimensiune, număr de câmpuri, părți multipart, antete) și o limită de container sau cgroup care oprește doar workerul afectat, nu RLIMIT_AS sau RLIMIT_DATA. Pentru CVE-2026-109619: session.upload_progress.enabled=0 în php.ini sau configurația pool-ului, cu repornirea tuturor workerilor, și fatal_error_backtraces=0 pe PHP 8.5. Sansec notează că memory_limit=-1 lasă o singură cerere să consume toată memoria serverului și că blocarea multipart/form-data oprește încărcările de fișiere. Dacă mitigările nu pot fi aplicate, NCSC spune să iei în calcul scoaterea sistemului din funcțiune.

Ce cauți dacă nu ai putut patch-ui imediat

  • ▸Procese de worker PHP (php-fpm, php-cgi, httpd, apache2) care lansează shell-uri, interpretoare sau unelte de descărcare și rețea, tipare de reverse shell în linia de comandă și comenzi de recunoaștere pornite de pe serverul web, potrivit Huntress.
  • ▸Cereri multipart neobișnuite urmate de erori de limită de memorie sau 500 repetate, cookie-uri PHPSESSID neobișnuit de mari sau malformate și reporniri de workeri fără explicație, potrivit Sansec.
  • ▸Fișiere noi în rădăcina web (webshell-uri), joburi cron, sarcini programate și conturi noi, dacă suspectezi compromitere.
  • ▸Sansec afirmă că memoria eliberată poate ajunge la client într-un cookie PHPSESSID, cu potențiale parole, jetoane de sesiune, chei API sau chei TLS din alte cereri. Este o afirmație a Sansec; dacă ai expus servere și ai indicii, tratează secretele de pe ele ca potențial expuse.
  • ▸Dacă suspectezi compromitere: izolează gazda, păstrează jurnalele web și PHP și cere ajutor de la un furnizor de răspuns la incident, cum sugerează NCSC.

Închide alerta cu dovezi

Pentru fiecare instalare PHP, păstrează versiunea înainte și după, SAPI-ul, data și ora actualizării (cu fusul orar), mitigările aplicate până atunci, rezultatul căutărilor în jurnale și decizia pentru sistemele rămase pe versiuni neacoperite, cu motivul și termenul. Pentru PHP livrat de furnizori, păstrează confirmarea scrisă a furnizorului despre starea corecției.

PHP-ul din pachete face parte din inventar

Urmărește în Awarely Monitor versiunea PHP a fiecărui sistem, inclusiv a celor livrate de furnizori, și dovezile actualizării. Patch-ul și jurnalele rămân în sistemele voastre.