Pe scurt: La o vulnerabilitate PHP precum PHP2Shell, în cazul hostingului web hosterul este responsabil de actualizarea PHP, nu dumneavoastră. Sarcina dumneavoastră este să obțineți o confirmare scrisă, să alegeți în meniul clientului o versiune PHP acceptată și să verificați site-ul pentru urme ale unui atac. Un patch al hosterului nu elimină programele malițioase care au ajuns anterior pe site-ul dumneavoastră.
Situația, în cuvinte simple
PHP este limbajul de programare pe care rulează majoritatea site-urilor, magazinelor și CMS-urilor precum WordPress. PHP2Shell desemnează două erori critice în PHP însuși (CVE-2026-109618 și CVE-2026-109619). Prin ele, atacatorii pot executa cod propriu pe server fără parolă. BSI (Oficiul Federal German pentru Securitatea Informațiilor) a declarat nivelul de avertizare 3 (portocaliu) și recomandă o actualizare imediată.
La shared hosting, mulți clienți împart un server. Tehnica de dedesubt, adică sistemul de operare, serverul web și PHP, este operată de hoster. Dumneavoastră administrați doar site-ul, baza de date și accesele. De aceea nu puteți instala singur actualizarea PHP și nici nu trebuie să o faceți.
Hosting web și vulnerabilitatea PHP: cine este responsabil?
Împărțirea rezultă din contractul dumneavoastră. În majoritatea tarifelor se aplică aproximativ următoarea distribuție:
| Sarcină | Hosterul | Dumneavoastră ca client |
|---|---|---|
| Actualizarea pachetelor PHP | da | nu |
| Repornirea proceselor PHP | da | nu |
| Setarea valorilor provizorii la nivel de server | da | nu |
| Alegerea versiunii PHP a site-ului dumneavoastră | oferă | alege |
| Actualizarea CMS-ului, pluginurilor și temelor | nu | da |
| Date de acces și conturi de administrator | nu | da |
| Verificarea site-ului pentru cod malițios | parțial | da |
| Evaluarea din perspectiva protecției datelor | nu | da |
Ultimul rând este important: dacă pe site-ul dumneavoastră apare un incident cu date cu caracter personal, de regulă răspunderea revine dumneavoastră ca operator, nu hosterului. Mai multe găsiți la Obligația de notificare RGPD.
Ce ar trebui să faceți acum
1. Obțineți o confirmare. Întrebați în scris hosterul dumneavoastră dacă versiunile PHP din pachetul dumneavoastră sunt protejate împotriva ambelor CVE-uri, de când, și dacă toate procesele PHP au fost repornite. Un model gata făcut găsiți la Cum întrebați hosterul despre starea patchului. Nu vă mirați dacă în meniul clientului apare în continuare un număr de versiune mai vechi, precum 8.2.34: unii furnizori livrează corecțiile ca backport, fără ca numărul să se schimbe.
2. Verificați versiunea PHP. Priviți în meniul clientului ce versiune PHP folosește site-ul dumneavoastră. PHP 8.1 și mai vechi nu mai primesc actualizări oficiale de la proiectul PHP. PHP 8.2 ajunge la sfârșitul suportului pe 31.12.2026. Dacă CMS-ul dumneavoastră suportă o versiune mai nouă, verificați în cerințele de sistem ale producătorului, de exemplu pe wordpress.org.
3. Controlați site-ul. Fiți atenți la conturi de administrator necunoscute, redirecționări neașteptate, fișiere străine în accesul FTP și avertismente în Google Search Console. O listă de semne tipice găsiți la Am fost deja compromis?.
4. Faceți o copie de siguranță. Descărcați o copie de siguranță actuală a fișierelor și a bazei de date și păstrați-o separat. Cereți în plus hosterului să păstreze jurnalele de acces ale pachetului dumneavoastră începând cu 20.10.2026.
După confirmarea hosterului, schimbați preventiv parolele pentru meniul clientului, FTP/SFTP, baza de date și administratorii CMS și activați, acolo unde este posibil, autentificarea în doi factori.
Ce nu puteți rezolva singur la shared hosting
Măsurile provizorii recomandate de php.net, de exemplu session.upload_progress.enabled=0, au efect doar dacă sunt setate în configurația serverului. O intrare în .user.ini sau prin ini_set() în cod nu este suficientă, potrivit php.net. Limitele de memorie la nivel de cgroup și repornirea proceselor PHP țin, de asemenea, de hoster.
Dacă hosterul dumneavoastră nu răspunde sau răspunde evaziv, aveți trei posibilități: să insistați și să fixați un termen, să puneți temporar site-ul în modul de mentenanță sau să treceți la un furnizor cu o poziție clară. BSI recomandă scoaterea temporară din rețea a serverelor web dacă o actualizare nu este posibilă imediat.
Verificați în plus dacă tariful dumneavoastră mai este actual. Pachetele care rulează neschimbate de mulți ani se află uneori pe generații mai vechi de servere, cu versiuni PHP mai vechi pe care hosterul le mai întreține doar limitat. Trecerea la un tarif actual al aceluiași furnizor se face adesea cu efort redus și aduce versiuni PHP mai noi. Întrebați despre asta dacă răspunsul privind starea patchului este nemulțumitor.
Dacă site-ul este deja suspect
Un patch la hoster închide vulnerabilitatea pentru viitor. El nu elimină însă o ușă din spate pe care atacatorii au instalat-o anterior și nu dovedește că nu s-a întâmplat nimic înainte. Dacă găsiți nereguli, nu ștergeți fișiere la întâmplare. Salvați mai întâi starea sistemului, pentru ca cauza să poată fi reconstituită ulterior.
Cum ajută PHP SOS concret?
- Formulăm împreună cu dumneavoastră solicitarea către hoster și evaluăm tehnic răspunsul acestuia.
- Verificăm site-ul dumneavoastră pentru webshell-uri, conturi străine și fișiere manipulate și, în caz de constatări, îl curățăm prin eliminarea malware-ului.
- La suspiciune acută preluăm asistența de urgență pentru site-uri compromise, cu asigurarea probelor.
- Vă ajutăm la alegerea unei versiuni PHP potrivite și testăm apoi site-ul.
Întrebări frecvente
Trebuie să actualizez singur PHP ca client de hosting?
De regulă nu, deoarece la shared hosting PHP face parte din platforma hosterului. Adesea puteți însă alege versiunea PHP din meniul clientului. Dacă acolo apare o versiune fără actualizări oficiale, ar trebui să schimbați sau să întrebați hosterul cum o protejează.
Site-ul meu este offline. Am fost atacat?
Nu neapărat. Unii furnizori au scos site-uri din rețea ca măsură de precauție, pentru a închide vulnerabilitatea. Întrebați hosterul care este motivul și cereți-i să confirme dacă există indicii ale unui atac asupra pachetului dumneavoastră.
Pot seta singur măsurile provizorii în .user.ini?
Pentru session.upload_progress.enabled, php.net precizează explicit că .user.ini și ini_set() nu sunt suficiente. Această setare trebuie făcută de hoster în configurația serverului.
Ce ar trebui să am în scris de la hoster?
O confirmare că versiunile PHP din pachetul dumneavoastră sunt protejate împotriva CVE-2026-109618 și CVE-2026-109619, de când este valabil acest lucru și că procesele PHP au fost repornite. Păstrați acest răspuns împreună cu documentele dumneavoastră.