← Toate știrile
ARTICOL
Zvonuri
23 octombrie 2026 3 min de citit
Realizat de Neska

PHP2Shell: actualizează PHP azi, ambele breșe RCE sunt deja exploatate

Două breșe critice în PHP, CVE-2026-109618 și CVE-2026-109619, permit execuția de cod fără autentificare și sunt exploatate activ. Versiunile corectate au apărut pe 21 octombrie.

În acest articol
  1. Ce este confirmat
  2. Vulnerabilitatea PHP2Shell: ce versiuni de PHP sunt sigure
  3. Ce se spune
  4. De ce contează pentru tine
  5. Ce să faci astăzi

Vulnerabilitatea PHP2Shell înseamnă, de fapt, două breșe critice în limbajul PHP, CVE-2026-109618 și CVE-2026-109619, care permit unui atacator fără credențiale să ruleze cod pe un server web. Proiectul PHP a publicat versiunile corectate pe 21 octombrie 2026, iar primele atacuri au fost observate în aceeași zi. Dacă un server al tău sau al unui client rulează PHP, actualizează-l astăzi.

O sală mare de servere văzută de sus, cu rânduri de rack-uri și indicatoare pentru serverele de e-mail și serverele web.
Foto: Florian Hirzinger - www.fh-ap.com (CC BY-SA 3.0), Wikimedia Commons.

Ce este confirmat

Proiectul PHP a primit primele rapoarte pe 11 august 2026. Amazon Threat Intelligence a semnalat o încercare de exploatare pe 17 octombrie, înainte de divulgarea publică. Pe 20 octombrie detaliile au apărut online înaintea datei stabilite, iar PHP a mutat lansarea de urgență pe 21 octombrie. În acea zi, watchTowr a observat exploatare activă în rețeaua sa de honeypot-uri.

CVE-2026-109618 se află în gestionarea erorilor de memorie epuizată: dacă PHP rămâne fără memorie în timp ce pregătește datele cererii, acestea rămân inițializate doar parțial, iar curățarea finală le tratează drept valide. CVE-2026-109619 este o eroare de stare globală neresetată, care duce la un use-after-free pe heap, cu citire de memorie și execuție de cod. Ambele permit execuția de cod de la distanță, fără autentificare, cu privilegiile contului serverului web. Avizele furnizorilor de securitate le evaluează la 9,2 pe scara CVSS v4.0.

Este vizată orice instalare PHP care servește cereri web: Apache cu mod_php, PHP-FPM, php-cgi, LiteSpeed și FrankenPHP. Proiectul PHP consideră riscul cel mai mare pentru mod_php, deoarece atacul poate reuși înainte de rularea oricărui cod al aplicației. Din același motiv, un firewall pentru aplicații web sau un agent RASP din interiorul procesului PHP poate să nu îl oprească.

Vulnerabilitatea PHP2Shell: ce versiuni de PHP sunt sigure

  • PHP 8.5: actualizează la 8.5.12.
  • PHP 8.4: actualizează la 8.4.27.
  • PHP 8.3: actualizează la 8.3.36.
  • PHP 8.2: actualizează la 8.2.35.
  • PHP 8.1, 8.0 și 7.4: nicio versiune oficială. Există backport-uri minimale doar ca cod sursă sau ca pachete de la distribuții și furnizori LTS.
  • PHP 7.3 și anterioare, inclusiv PHP 5: nicio corecție, trebuie să treci la o ramură suportată.

Distribuțiile Linux corectează adesea o breșă fără să schimbe numărul versiunii: verifică changelogul pachetului, nu doar rezultatul comenzii php -v.

Zvon

Ce se spune

Sursele nu sunt de acord asupra stadiului exploit-ului. Unii cercetători susțin că cele două breșe sunt deja înlănțuite într-un singur script funcțional și că există analize și un instrument publice. Huntress a scris că nu a reprodus o dovadă de concept, iar JFrog a avertizat că circulă exploit-uri false. Cine descarcă de pe un forum un presupus exploit PHP2Shell riscă să instaleze malware.

La 22 octombrie, breșele nu figurau în catalogul CISA KEV, potrivit watchTowr. Centrul Național de Securitate Cibernetică din Regatul Unit (NCSC) a cerut organizațiilor să actualizeze imediat sau să scoată offline sistemele expuse. VirusTotal estimează că peste 5,1 milioane de gazde PHP sunt accesibile de pe internet.

De ce contează pentru tine

Dacă te ocupi de IT pentru o IMM sau pentru mai mulți clienți, PHP nu se află doar în site-urile scrise de tine. Este în WordPress, Joomla, Magento, PrestaShop, în webmail, în aplicații de gestiune vechi și în orice container a cărui imagine de bază include PHP. Un container păstrează PHP-ul cu care a fost construit: trebuie să îl reconstruiești sau să tragi o imagine corectată și să refaci deploy-ul.

Ce să faci astăzi

  1. Fă inventarul: php -v pe fiecare gazdă și docker exec <container> php -v pe fiecare container care servește PHP.
  2. Actualizează la versiunea corectată sau la pachetul corectat al furnizorului tău, apoi repornește PHP-FPM sau Apache.
  3. Dacă nu poți actualiza imediat, scoate sistemul respectiv din accesul direct de pe internet.
  4. Ca măsuri provizorii, care nu protejează complet: session.upload_progress.enabled=0 și repornirea worker-ilor, un post_max_size mic (8M sau 32M dacă ai nevoie de upload-uri) și limite de memorie la nivel de container.
  5. Verifică jurnalele de acces începând cu 17 octombrie și, dacă bănuiești că memoria proceselor a fost citită, schimbă parolele, token-urile și cheile API.

Proiectul PHP spune clar că nicio configurație nu atenuează complet aceste breșe și că actualizarea este singura apărare durabilă. Pentru ajutor la stabilirea priorităților și la aplicarea rapidă a corecțiilor, vezi serviciile noastre de cybersecurity.

Surse: watchTowr, FAQ PHP2Shell; BleepingComputer; Qualys; JFrog; Huntress.

← ← Toate știrile