PHP2Shell | Panică mondială și ghidul complet de patch

Panica a fost instituțională și documentabilă: NSA, CISA, ENISA, ANSSI, BSI și centrele naționale de securitate cibernetică din Canada, Olanda și Marea Britanie au emis alerte în aceeași zi. Premierul Japoniei a avertizat public. Coreea de Sud a ridicat nivelul de alertă. Partea bizară a poveștii: până acum, nimeni nu a confirmat vreo instituție efectiv spartă.

Publicitate online pe Critic Arad

Pachete reclame online pentru firme

Alege ziarul preferat de audiența ta

Ajungi usor in fața aradenilor

Verifică rezultatele online

Transparența 100%

de la 1.290 lei

Vezi oferte

PHP2Shell nu e o problemă de plugin, de temă sau de cod scris prost. E în PHP însuși, limbajul pe care rulează aproximativ 70% din web. Codul vulnerabil există din 2012.

Articolul are două părți: ce s-a întâmplat cu PHP2Shell, documentat pe surse oficiale, și un ghid de aplicare a corecției, comandă cu comandă, pentru administratorii de sistem.

1. Ce este, de fapt, PHP2Shell

PHP2Shell nu e o vulnerabilitate, ci două, publicate împreună de echipa de securitate PHP pe 21 octombrie 2026, în jurul orei 14:00 UTC. Numele PHP2Shell le acoperă pe amândouă, pentru că exploit-ul care a circulat le combină într-un singur atac.

Ambele componente ale PHP2Shell au scorul CVSS v4.0 de 9.2, cu vectorul identic AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H. Traducerea în limbaj obișnuit: atacul vine prin rețea, nu cere parolă, nu cere ca cineva să dea click și compromite complet confidențialitatea, integritatea și disponibilitatea serverului.

Un detaliu care contează. Red Hat a scorat PHP2Shell la 8.1, iar NVD la 9.8. Diferența nu e o greșeală: Red Hat argumentează că instalările sale standard folosesc PHP-FPM, unde execuția de cod e dificil de realizat practic, nu mod_php. Echipa PHP consideră, dimpotrivă, că mod_php e scenariul cel mai periculos și singurul demonstrat cu exploit funcțional.

Versiunile corectate sunt 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Google Cloud a confirmat că intervalul vulnerabil pornește de la PHP 5.4 și merge până la 8.5.11 inclusiv. PHP 8.1 și tot ce e mai vechi nu primesc corecție oficială; echipa a publicat doar backporturi minimale de sursă pentru 7.4, 8.0 și 8.1, pe ramuri dedicate în php-src.

2. Cronologia: de la 1 august la exploatare în masă

PHP2Shell nu a fost descoperit de o singură persoană și nici dintr-un accident.

Elementul cel mai important din tabel e rândul din 17 octombrie. Amazon a documentat, prin CJ Moses, directorul său de securitate, o tentativă de exploatare cu patru zile înainte de anunț, dintr-o rețea comercială de anonimizare. Consecința practică pentru orice administrator: investigația de compromitere nu începe de la data patch-ului, ci de la 17 octombrie.

Despre volumul atacurilor PHP2Shell, cifrele publice vin de la Matthew Prince, directorul general al Cloudflare: mii de tentative în cele 10 ore dinaintea anunțului, zeci de mii în primele 45 de minute după, sute de mii în două ore, milioane ulterior. Nu există niciun număr absolut publicat, iar Prince a vorbit despre tentative observate, nu despre tentative blocate.

Contrazicerea merită notată: firma de securitate Imperva a declarat că nu a văzut niciun trafic care să corespundă tiparelor de exploatare monitorizate.

3. Harta globală: cine a închis ce

Aproape toate măsurile au fost preventive. Nu am găsit nicio instituție publică, din nicio țară, confirmată compromisă prin PHP2Shell.

La nivel european, ENISA, Comisia Europeană, CERT-EU și Europol au emis o declarație comună pe 21 octombrie. Nu afirmă exploatare activă; recomandă izolarea aplicațiilor expuse dacă patch-ul nu se poate aplica imediat.

Un fapt verificat de noi direct. La momentul publicării acestui articol, niciunul dintre cele două CVE-uri nu figura în catalogul CISA al vulnerabilităților exploatate cunoscute. Am descărcat feed-ul oficial: versiunea 2026.10.21, 1.754 intrări, singurele intrări PHP fiind unele vechi, din 2012–2024.

4. România: Poliția Română, DNSC și două formulări diferite

Directoratul Național de Securitate Cibernetică a emis alertă PHP2Shell pe 20 octombrie, actualizată după apariția corecțiilor. Formularea e lipsită de ambiguitate: „Orice server PHP neactualizat și expus în Internet trebuie considerat la risc ridicat de compromitere.”

DNSC indică o fereastră de verificare care începe pe 20 octombrie 2026, ora 15:00 UTC, și adaugă o observație care explică de ce nimeni nu are timp de pierdut: „din experiențele anterioare se constată că vulnerabilitățile critice pot fi exploatate în mai puțin de 24 de ore de la publicarea detaliilor tehnice”.

Alerta trimite explicit la Legea 58/2023, art. 5 lit. a): responsabilitatea securității cibernetice revine celui care deține și administrează sistemul. Cu alte cuvinte, statul avertizează, dar nu patch-uiește pe nimeni.

Alerta DNSC nu menționează nicio instituție românească afectată.

Poliția Română: „upgrade” sau „actualizări de securitate”?

Începând de miercuri seara, politiaromana.ro și paginile inspectoratelor județene au fost înlocuite cu o pagină statică. Am verificat joi dimineața: pagina răspunde normal, e găzduită pe altă infrastructură decât site-ul obișnuit și e identică, octet cu octet, pe toate subdomeniile testate — Timiș, Arad, Alba, Cluj, București.

Asta înseamnă retragere controlată și centralizată, nu o cădere accidentală. Site-urile nu s-au prăbușit; au fost luate jos deliberat, toate odată.

Textul paginii oficiale: „Site-ul Poliției Române este temporar indisponibil pentru lucrări de mentenanță și actualizări de securitate.”

Citatul dat presei de Georgian Drăgan, reprezentant al Inspectoratului General al Poliției Române, sună altfel: site-ul„a intrat într-un proces de upgrade începând de miercuri seara”.

Aceeași instituție, aceeași zi, două registre diferite. Pagina proprie spune „securitate”. Purtătorul de cuvânt spune „up grade”.

Ce se poate afirma și ce nu. Secvența temporală e documentabilă: retragerea a început în intervalul de ore de după publicarea corecțiilor PHP, la 21 octombrie ora 17:00 ora României. Motivul declarat pe canalul propriu include cuvântul „securitate”. Legătura cu PHP2Shell nu este confirmată de nicio sursă oficială — nici IGPR, nici MAI, nici DNSC nu au numit vulnerabilitatea. Rămâne coincidență temporală până la o confirmare. Am trimis întrebare la IGPR.

În rest, verificările noastre pe peste 30 de domenii instituționale românești — gov.ro, mai.gov.ro, anaf.ro, edu.ro, senat.ro, mfinante.gov.ro, igsu.ro, sri.ro, mapn.ro și altele — nu au găsit nicio altă pagină de mentenanță. Afirmațiile din presă că „o serie de site-uri ale unor instituții de stat au fost suspendate” nu au fost confirmate de verificarea directă și nu numesc nicio instituție.

5. Arad: primăria rulează WordPress din 2021

Am verificat, prin cereri publice obișnuite și fără nicio scanare, site-urile instituțiilor arădene.

Versiunea WordPress nu indică direct versiunea PHP, iar fără acea informație nu se poate afirma că un site e vulnerabil. Dar WordPress 5.8.2 e contemporan cu PHP 7.4 și 8.0 — exact ramurile pentru care, spune DNSC, „instalările ajunse la sfârșitul ciclului de viață prezintă riscul cel mai mare”.

Niciunul dintre site-urile verificate nu expune versiunea de PHP. Am solicitat informația Primăriei Arad și Consiliului Județean Arad în baza Legii 544/2001: ce versiune de PHP rulează și dacă au aplicat corecția din 21 octombrie. [INFORMAȚIE LIPSĂ — cereri Legea 544 trimise la Primăria Arad și CJ Arad]

Cât despre expunerea generală: potrivit W3Techs, PHP rulează pe 69,3% dintre site-urile cu limbaj server identificabil. Dintre acestea, 34,7% sunt pe ramuri ieșite complet din suport — PHP 7, 5 sau 4. Pentru ele nu există corecție oficială și nu va exista. O statistică națională pentru domeniile .ro nu există; nici DNSC, nici ICI nu publică așa ceva.

6. Ghid de patch, pas cu pas

Partea practică. Închiderea PHP2Shell are cinci pași, ordinea lor contează, iar cel ratat cel mai des e penultimul.

Pasul 0: nu te uita la numărul de versiune

Distribuțiile backportează corecția fără să schimbe șirul de versiune. Ubuntu livrează fix-ul în pachete numite 8.3.6, 8.1.2 și 8.5.4. Red Hat, în php-7.4.33-8.module și php-8.0.30-8.el9_8.1. Niciunul nu va afișa „8.3.36” la php -v.

Verificarea se face în changelog, după numărul CVE, nu cu php -v. Cine se uită doar la versiune va trage concluzia greșită în ambele sensuri.

Pasul 1: inventariază ce ai

Debian și Ubuntu:

• dpkg -l 'php*' — lista pachetelor instalate
• ls /etc/php — arată toate versiunile instalate în paralel
• apt-cache policy php8.4-fpm — arată ce versiune e candidată

RHEL, AlmaLinux, Rocky:

• rpm -qa 'php*' | sort
• dnf module list --enabled php
• httpd -M | grep php — verifică dacă rulezi mod_php

Pasul 2: verifică dacă pachetul există pentru tine

Aici e capcana PHP2Shell. La data documentării, situația arăta astfel:

Dacă ești pe AlmaLinux, Rocky, Remi, cPanel sau CloudLinux, dnf upgrade nu închide PHP2Shell deocamdată. Verifică errata înainte de a te declara în siguranță, iar până atunci aplică mitigările de la pasul 5.

Advisory-ul oficial PHP face o recomandare neobișnuită: utilizatorilor depozitului comunitar Remi li se cere explicit să treacă pe pachetele distribuției sau să compileze din surse. E rar ca proiectul PHP să recomande abandonarea unui depozit comunitar.

Pasul 3: aplică actualizarea

Debian și Ubuntu:

• sudo apt-get update
• sudo apt-get install --only-upgrade 'php8.4*' — înlocuiește 8.4 cu versiunea ta
• verificarea fix-ului: zgrep CVE-2026-109618 /usr/share/doc/php8.4-fpm/changelog.Debian.gz

Ubuntu Pro pe versiuni vechi: sudo pro fix CVE-2026-109618

RHEL și derivate:

• sudo dnf update 'php*'
• verificarea fix-ului: rpm -q --changelog php-fpm | head -20

Pentru schimbarea ramurii de module stream pe RHEL 8 sau 9:

• sudo dnf module reset php
• sudo dnf module enable php:8.2
• sudo dnf distro-sync 'php*'

Docker — pinează versiunea exactă, nu tag-ul flotant, pentru că tag-urile de tip php:8.2-fpm au întârziat să se actualizeze:

• docker compose build --pull --no-cache
• docker compose up -d --force-recreate
• docker compose exec serviciu php -v

Pasul 4: repornește tot. Chiar tot.

Acesta e pasul ratat cel mai des, iar advisory-ul PHP2Shell îl repetă de patru ori. Instalarea pachetului nu înlocuiește codul care rulează deja în memorie.

Comanda reload și apachectl graceful nu sunt suficiente pentru mod_php. Motivul, în termeni tehnici: interpretorul e încărcat ca obiect partajat în imaginea procesului Apache. O repornire grațioasă reciclează procesele copil, dar părintele nu face re-exec, deci biblioteca veche rămâne mapată și copiii noi sunt derivați din ea. Doar un restart complet o înlocuiește.

Lista completă a ceea ce trebuie repornit:

• php-fpm, câte un serviciu pentru fiecare versiune instalată
• Apache cu mod_php: systemctl restart apache2 sau systemctl restart httpd, restart complet
• LiteSpeed și OpenLiteSpeed: sudo pkill lsphp
• FrankenPHP, RoadRunner și orice daemon PHP propriu
• Pool-uri FastCGI și, pe Windows, pool-urile IIS
• Worker-i de cozi: php artisan queue:restart, php artisan horizon:terminate, php artisan octane:reload, consumatorii Symfony Messenger
• Supervisor: supervisorctl restart all
• Job-uri cron de lungă durată pornite înainte de patch — acestea trebuie oprite explicit
• Sesiuni WP-CLI, Drush, tmux sau screen uitate deschise

Verificarea că nu mai rulează nimic pe binarul vechi, pe Debian și Ubuntu: sudo needrestart -b -r l. Lista proceselor care încă țin deschise biblioteci șterse se obține inspectând /proc; dacă rezultatul e gol, nu a mai rămas nimic pe codul vechi.

Versiunea se confirmă separat pentru fiecare SAPI — CLI, FPM și modulul Apache sunt trei lucruri diferite și pot rula binare diferite.

Pasul 5: dacă nu poți aplica patch-ul azi

Mitigările oficiale PHP2Shell, din cele două advisory-uri GHSA. Niciuna nu e completă, iar PHP spune explicit că actualizarea e singura remediere reală.

Pentru CVE-2026-109618:

• memory_limit=-1, impus administrativ, astfel încât aplicația să nu îl poată suprascrie
• post_max_size conservator și limitarea dimensiunii cererilor la frontend
• blocarea cererilor multipart la serverul web, dacă aplicația nu are upload-uri
• limită de memorie prin container sau cgroup — nu prin RLIMIT_AS sau RLIMIT_DATA

Pentru CVE-2026-109619:

• session.upload_progress.enabled=0, urmat de repornirea tuturor worker-ilor
• pe PHP-FPM, impus pe pool: php_admin_flag[session.upload_progress.enabled] = off
• doar pe PHP 8.5: fatal_error_backtraces=0
• dacă performanța permite: pm.max_requests=1

Două avertismente care contează. Mitigările nu se aplică prin .user.ini sau ini_set() — se aplică prea târziu în ciclul cererii. Și verificarea că au intrat în vigoare se face printr-o cerere HTTP servită de FPM sau mod_php, nu din linia de comandă: CLI citește alt fișier de configurare și raportează valori care nu se aplică traficului web.

Dacă rulezi PHP 8.1 sau mai vechi și nu poți compila din surse, ultima opțiune onestă e depozitul sury.org, care a publicat backporturi până la PHP 5.6, sau izolarea completă a sistemului de internet.

7. Ce NU te salvează

DNSC enumeră explicit măsurile pe care administratorii le cred suficiente împotriva PHP2Shell și nu sunt. Motivul e același pentru toate: PHP procesează cererea înainte ca aplicația să apuce să verifice ceva.

• Modul de mentenanță al WordPress, Magento sau Drupal — aplicația decide după ce PHP a parsat deja cererea
• Pluginurile de securitate și verificările de autentificare din aplicație, din același motiv
• Dezactivarea încărcării de fișiere prin file_uploads = Off
• Un WAF — ajută doar dacă serverul de origine nu poate fi accesat direct, ocolind filtrarea. Dacă IP-ul real al serverului e cunoscut, WAF-ul e decorativ
• Actualizările automate ale WordPress — nu ating versiunea de PHP de pe server. Wordfence a ținut să precizeze public acest lucru
• Un cod de aplicație curat — PHP2Shell e în interpretor, nu în ce ai scris tu

8. Cum verifici dacă ai fost compromis

Nu există încă o listă de indicatori PHP2Shell publicată de echipa PHP. Căutarea e comportamentală.

Fereastra de investigație PHP2Shell începe pe 17 octombrie, data primei exploatări observate de Amazon, nu pe 20 sau 21. DNSC recomandă 20 octombrie ora 15:00 UTC; datele Amazon o împing cu trei zile mai devreme. Ia varianta mai largă.

Înainte de orice: salvează logurile serverului web și ale PHP din acea fereastră, înainte de a aplica patch-ul, de a roti logurile sau de a reconstrui containerele.

Ce se caută:

• în logurile de acces, șirul PHP_SESSION_UPLOAD_PROGRESS în cereri POST de tip upload — singurul marker de payload publicat oficial de Amazon
• cereri multipart/form-data către pagini care nu acceptă upload-uri
• fișiere .user.ini noi sau modificate în rădăcinile web și în directoarele de upload — permit setarea directivei auto_prepend_file, care execută cod la fiecare cerere fără a modifica vreun fișier al aplicației
• valoarea auto_prepend_file, verificată atât din linia de comandă, cât și printr-o cerere web
• fișiere PHP în directoare de upload — în wp-content/uploads nu are ce căuta niciunul
• procese copil neașteptate ale worker-ilor PHP: shell-uri, curl, wget
• crash-uri și segmentation fault inexplicabile în logurile PHP-FPM
• persistență: intrări cron noi, unități systemd noi, chei SSH adăugate, conturi noi de administrator în aplicație

Amazon a publicat și adrese IP observate, dar cu o precizare importantă: aparțin unei infrastructuri de anonimizare partajate, deci se investighează potrivirile, nu se blochează orb.

Despre rotația de credențiale, o clarificare necesară. Advisory-ul oficial PHP confirmă divulgarea de memorie doar pentru CVE-2026-109619. Firma de securitate Sansec a mers mai departe și a afirmat că memoria scursă poate conține parole, token-uri de sesiune, chei API și chei private TLS — afirmație care nu apare în niciun document oficial PHP și nu e însoțită de o demonstrație publicată.

Recomandarea defensibilă: rotește secretele aplicației — token-uri de sesiune, chei API, parole de bază de date, cheile de framework — pe sistemele unde logurile arată indicii de exploatare sau unde logurile lipsesc și nu poți exclude nimic. Regenerarea certificatelor TLS nu are temei documentat și nu o recomandăm fără dovezi.

9. Ce rămâne nelămurit

Onestitatea cere și lista a ceea ce nu știm.

• Nu există nicio compromitere prin PHP2Shell confirmată public, nicăieri în lume. Există tentative documentate și atât.
• Datele de exploatare se contrazic: Amazon raportează activitate PHP2Shell din 17 octombrie, Imperva nu a văzut nimic.
• Legătura dintre retragerea site-ului Poliției Române și PHP2Shell nu e confirmată de nicio sursă oficială.
• Nu se cunoaște numărul serverelor vulnerabile din România. Nicio instituție nu publică această statistică.
• Nu am găsit nicio comunicare publică a vreunui furnizor major de găzduire din România către clienți pe această temă. Am întrebat șase dintre ei. [INFORMAȚIE LIPSĂ — solicitări trimise, răspunsuri neprimite]

Opinie, marcată ca atare: povestea reală nu e PHP2Shell în sine — orice software suficient de vechi ajunge să aibă o gaură gravă. E că o treime din site-urile PHP ale lumii rulează pe versiuni pentru care nu mai există nicio corecție, de la nimeni, oricât de gravă ar fi problema. Pentru acelea, 21 octombrie nu a adus niciun patch. A adus doar o hartă publică a ceea ce e spart.

Publicitate online pe Critic Arad

Pachete reclame online pentru firme

Alege ziarul preferat de audiența ta

Ajungi usor in fața aradenilor

Verifică rezultatele online

Transparența 100%

de la 1.290 lei Vezi oferte