PHP2Shell: vulnerabilitățile critice din PHP care pun în pericol magazinele online

Înainte
Banner Zero Day PHP2Shell cu un server, un terminal care afișează comanda whoami și un semn de avertizare roșu

🇷🇴 Acest articol este disponibil și în limba engleză. / 🇬🇧 Prefer to read this in English? [Click here for the English version].

Două vulnerabilități critice din PHP, cunoscute cu numele de PHP2Shell, pot afecta magazine online găzduite pe un server cu PHP 5.4 sau mai nou. Potrivit cercetătorilor de la Sansec, ele permit executarea de cod de la distanță (Remote Code Execution). PHP va publica remedierea acestora miercuri, 21 octombrie 2026, la ora 17:00 (ora României).

Majoritatea vulnerabilităților descoperite de cercetători afectează de regulă o singură platformă. PHP2Shell afectează însă chiar limbajul de bază pe care rulează Magento, Shopware sau WooCommerce. Sansec se așteaptă ca atacurile în masă să înceapă în primele 15 minute după publicarea patch-ului, așa că fiecare oră de pregătire contează.

Ce este PHP2Shell?

PHP2Shell este numele dat celor două vulnerabilități, înregistrate ca CVE-2026-109618 și CVE-2026-109619. Echipa de securitate PHP le-a dat amândurora un scor de 9,2 pe scala CVSS v4.0, adică sunt de nivel critic.

Informațiile despre acestea erau sub embargo, dar au apărut în spațiul public pe 20 octombrie. Firma de securitate watchTowr a confirmat apoi că este vorba de vulnerabilități de execuție de cod de la distanță. Tot atunci a apărut și o captură de ecran a unui instrument de exploatare care susține că funcționează pe toate versiunile de PHP începând cu 5.4.0.

Detaliile tehnice complete și versiunile corectate vor fi publicate odată cu lansarea. Echipa PHP își rezervă dreptul să lanseze remedierea mai devreme dacă detaliile devin publice sau dacă atacurile au început deja.

De ce nu se rezolvă din codul magazinului

Atacul vizează PHP-ul în sine și acționează înainte de aplicația magazinului în sine. O actualizare de Magento, un modul de securitate sau o regulă de firewall la nivel de aplicație nu te pot proteja complet. Remedierea se face la nivel de infrastructură, prin actualizarea PHP pe servere.

Mai este un detaliu important: PHP oferă suport doar pentru versiunile 8.2 și mai noi. Dacă magazinul tău rulează pe PHP 8.1 sau pe o versiune mai veche, nu vei primi un patch oficial. Ai nevoie fie de o remediere portată (backport) de furnizorul de hosting, fie de migrarea pe o versiune de PHP suportată oficial.

De ce este important pentru deținătorii de magazine online?

Un atacator care poate executa cod de la distanță pe server poate dobândi acces la tot ce rulează acolo. În funcție de cât de departe ajunge, riscurile principale includ:

  • Furtul datelor de card și al informațiilor personale: scripturi malițioase (skimmers) injectate în pagina de checkout.
  • Acces neautorizat la baza de date: comenzile, datele clienților și credențialele conturilor pot fi compromise.
  • Backdoor-uri persistente: conturi de administrator ascunse sau canale de acces care rămân active și după patch și le pot permite atacatorilor accesul ulterior.
  • Pierderea încrederii cumpărătorilor: la care se adaugă costuri mari pentru investigație și remediere.

Ce ar trebui să faci acum? (Mic plan de acțiune)

  1. Verifică ce versiune de PHP ai: află exact ce versiune rulează pe toate serverele magazinului tău, nu doar pe cel de producție.
  2. Vorbește azi (21 octombrie 2026) cu furnizorul de hosting: dacă nu administrezi tu serverul, cere-i să fie pregătit să aplice actualizarea imediat după lansare.
  3. Planifică migrarea la o versiune suportată dacă ești pe PHP 8.1 sau mai vechi: versiunile fără suport nu vor primi patch oficial.
  4. Aplică măsura temporară recomandată de Sansec: detaliile sunt în secțiunea de întrebări frecvente de la finalul articolului.
  5. Actualizează PHP imediat ce apare patch-ul: apoi verifică dacă noua versiune servește efectiv cererile magazinului, nu doar linia de comandă.
  6. Urmărește canalele oficiale: monitorizează php.net și articolul Sansec, care va fi actualizat pe măsură ce apar informații noi.

Cronologie (ora României)

  • 20 octombrie 2026, 18:20: o postare pe Hacker News anunță două vulnerabilități RCE în PHP, care urmează să fie făcute publice.
  • 20 octombrie 2026: PHP anunță o lansare critică de securitate, iar watchTowr confirmă scurgerea de informații.
  • 21 octombrie 2026, 17:00: lansarea programată a patch-ului de securitate PHP.

Protejează-ți magazinul online cu CloudEBS

PHP2Shell arată că securitatea unui magazin online nu ține doar de platformă, ci și de serverul pe care rulează aceasta. La CloudEBS găzduim magazine online pe hosting propriu, optimizat pentru e-commerce, inclusiv pentru Magento, și ne ocupăm de actualizarea PHP pentru clienții noștri de hosting.

Cum te poate ajuta echipa CloudEBS: verificăm versiunea de PHP și configurația serverului tău, aplicăm măsurile temporare și actualizarea imediat ce aceasta apare. Dacă rulezi o versiune de PHP fără suport, te ajutăm să planifici migrarea în siguranță.

Ai nevoie de un audit de securitate pentru magazinul tău?
Dacă vrei să afli cât de expus este magazinul tău și dincolo de PHP2Shell, putem face pentru tine un audit de securitate al platformei. Verificăm atât aplicația (versiunea, patch-urile, extensiile), cât și serverul pe care rulează, iar la final primești un raport cu riscurile găsite și pașii de remediere, în ordinea priorității. Auditul este neintruziv, așa că magazinul funcționează normal pe toată durata verificării.

Scrie-ne prin formularul de mai jos și verificăm împreună dacă magazinul tău este pregătit.

    Întrebări Frecvente (FAQ)

    Ce setări pot aplica până la publicarea patch-ului?

    Sansec recomandă două setări care pot opri un atac înainte să apuci să actualizezi PHP, fără să fie însă o garanție. Le adaugi în php.ini sau într-un fișier .ini separat din conf.d:

    session.upload_progress.enabled = 0
session.use_strict_mode = 1

    Cum aplic setările dacă serverul folosește PHP-FPM?

    PHP-FPM nu citește php.ini-ul folosit în linia de comandă, așa că setările trebuie adăugate în fiecare pool care servește PHP, de exemplu în /etc/php/8.3/fpm/pool.d/www.conf:

    php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[session.use_strict_mode] = on

    După modificare, reîncarcă procesele PHP-FPM (systemctl reload php8.3-fpm, cu versiunea ta în locul lui 8.3), apoi verifică dacă valorile sunt active într-o cerere servită de PHP-FPM, nu în linia de comandă. Dacă folosești mod_php, setările se pun în php.ini și repornești Apache.

    Pot afecta aceste setări funcționarea magazinului?

    Nu, conform articolului Sansec, ambele setări sunt sigure pentru un magazin obișnuit. Dezactivarea upload progress oprește doar barele native de progres la încărcarea fișierelor, pe care Magento nu le folosește, iar modul strict pentru sesiuni este recomandat de PHP pentru orice site.

    Mă protejează setările dacă sesiunile magazinului sunt stocate în Redis?

    Nu. Dacă sesiunile sunt stocate în Redis sau în baza de date, cum se întâmplă la multe magazine pe Magento, session.use_strict_mode nu are niciun efect, nici de protecție, nici de perturbare. De aceea, actualizarea PHP rămâne singura cale sigură.

    Postat la 21.10.2026