Pe scurt: Ce faceți ca client de hosting la vulnerabilitatea PHP2Shell? Actualizarea PHP, de regulă, nu trebuie să o instalați dumneavoastră, aceasta o preia la shared hosting furnizorul de hosting. Sarcinile dumneavoastră sunt altele: obțineți o confirmare scrisă a nivelului de patch, alegeți în meniul clientului o versiune PHP suportată și verificați dacă site-ul dumneavoastră prezintă lucruri neobișnuite. Cele 15 întrebări cele mai frecvente despre acestea le răspunde acest articol pe scurt și pe rând.
Vulnerabilitate PHP ca client de hosting: sunt afectat, ce fac?
Din 21 octombrie 2026 primim multe întrebări de la companii al căror site se află la un furnizor de hosting. Cele mai multe se învârt în jurul acelorași puncte. Cine vrea să citească responsabilitățile mai detaliat le găsește la Shared hosting: ce face furnizorul și ce trebuie să faceți dumneavoastră.
1. Este site-ul meu afectat în general?
Dacă site-ul dumneavoastră rulează cu WordPress, Shopware, TYPO3, Joomla, Contao sau alt sistem PHP, serverul de dedesubt poate fi afectat. Paginile HTML pure, fără PHP, nu sunt. La nevoie ajută o privire în meniul clientului: dacă există acolo o setare pentru versiunea PHP, folosiți PHP.
2. Care este diferența dintre shared hosting și serverul propriu?
La shared hosting împărțiți un server operat de furnizorul de hosting cu alți clienți; furnizorul de hosting întreține PHP. La serverul root sau vServer propriu sunteți responsabil dumneavoastră. La serverul gestionat, contractul reglementează cine instalează actualizările.
3. Furnizorul meu de hosting a trimis un e-mail circular. Mai trebuie să fac ceva?
Citiți exact ce scrie în el. Un e-mail circular confirmă adesea doar că furnizorul de hosting „lucrează la subiect”. Aveți nevoie de o declarație despre pachetul dumneavoastră: ramura PHP, nivelul de patch, momentul și repornirea.
Responsabilitate și actualizare
4. Instalează furnizorul de hosting actualizarea automat?
De regulă da, pentru versiunile PHP pe care le oferă pe serverele sale. Dacă s-a întâmplat deja și dacă sunt acoperite și versiunile mai vechi diferă de la un furnizor la altul. Întrebați.
5. Meniul meu de client arată un număr de versiune vechi. Sunt neprotejat?
Nu neapărat. Mulți furnizori de hosting încorporează corecții ca backport, numărul rămânând atunci același. Plesk, de exemplu, poate afișa în continuare 8.2.34, deși eroarea este remediată. Hotărâtoare este confirmarea furnizorului de hosting.
6. Folosesc încă PHP 7.4 sau 8.1. Ce fac acum?
Aceste ramuri nu mai primesc actualizări oficiale de la proiectul PHP. Unii furnizori de hosting livrează corecții proprii, alții nu. Clarificați în scris și planificați trecerea la o ramură suportată. Verificați mai întâi în cerințele de sistem ale CMS-ului dumneavoastră ce versiuni PHP suportă.
7. Pot schimba singur versiunea PHP?
La majoritatea furnizorilor de hosting da, în meniul clientului. Cum se face și la ce să fiți atenți dinainte descrie articolul Schimbarea versiunii PHP în zona clientului de hosting. Faceți înainte o copie de siguranță.
8. Ajută actualizarea WordPress sau a pluginurilor?
Împotriva PHP2Shell nu, deoarece vulnerabilitatea se află în PHP. Actualizările CMS-ului sunt totuși utile, pentru că închid alte vulnerabilități.
Verificare și dovadă
9. Cum obțin o dovadă de la furnizorul de hosting?
Printr-o solicitare scrisă care cere date concrete: nivelul pachetelor pentru fiecare ramură PHP, data instalării, repornirea tuturor proceselor PHP. Un model de copiat oferă ghidul Solicitarea confirmării actualizării PHP de la furnizorul de hosting.
10. Pot seta măsurile provizorii prin .user.ini?
Nu. php.net descurajează explicit setarea setărilor provizorii prin ini_set() sau .user.ini. Ele aparțin configurației serverului, iar aceasta este administrată la shared hosting de furnizorul de hosting.
11. Site-ul meu a fost scurt timp offline. Am fost hackuit?
Nu neapărat. Unii furnizori de hosting au oprit site-uri preventiv sau au repornit servere. Întrebați care a fost motivul înainte de a trage concluzii.
12. Cum recunosc că site-ul meu a fost atacat?
Indicii posibile sunt conturi de administrator necunoscute, fișiere PHP noi în directorul de upload, redirecționări către pagini străine, pagini străine în indexul Google sau avertismente în Search Console. Rugați furnizorul de hosting să păstreze logurile de acces începând cu 20 octombrie.
Când ceva nu se potrivește
13. Furnizorul de hosting nu răspunde sau răspunde evaziv. Ce fac?
Întrebați în scris și fixați un termen rezonabil. Dacă răspunsul nu vine, ar trebui să tratați serverul ca neverificat și să vă gândiți să mutați temporar site-ul pe o pagină de urgență statică.
14. Ar trebui să schimb furnizorul de hosting?
O schimbare în mijlocul situației creează riscuri proprii. Este utilă dacă furnizorul de hosting nu oferă informații pe termen lung sau continuă să opereze versiuni PHP vechi fără corecție. Ce trebuie avut în vedere descrie Schimbarea furnizorului de hosting după un incident.
15. Trebuie să raportez ceva?
Dacă există indicii ale unui atac și pot fi afectate date cu caracter personal, poate exista o obligație de notificare conform RGPD, de regulă în 72 de ore. Clarificați cu responsabilul dumneavoastră cu protecția datelor sau cu un avocat. Aceasta nu este consultanță juridică.
Lista dumneavoastră scurtă de verificare
- Întrebați furnizorul de hosting în scris despre nivelul de patch și repornire.
- Verificați versiunea PHP în meniul clientului, înlocuiți ramurile depășite.
- Parcurgeți conturile de administrator și directorul de upload.
- Verificați avertismentele din Search Console.
- La lucruri neobișnuite, cereți ajutor înainte de a șterge fișiere.
Cum ajută PHP SOS concret?
- Clarificare cu furnizorul de hosting: Formulăm solicitarea sau purtăm discuția și evaluăm răspunsul.
- Verificarea site-ului: Căutăm urme în fișiere, baza de date și conturi, în măsura în care pachetul de hosting o permite.
- Curățare: Dacă găsim cod malițios, îl eliminăm și schimbăm toate accesurile.
- Documentare: Primiți starea în scris.
La o suspiciune concretă ajută asistența de urgență pentru site-uri hackuite.
Concluzie
Ca client de hosting nu purtați la PHP2Shell povara actualizării, dar purtați răspunderea pentru site-ul dumneavoastră. Cele mai multe întrebări se rezolvă cu un răspuns scris clar al furnizorului dumneavoastră de hosting. Ce rămâne după aceea este privirea asupra propriului site: conturi, fișiere, indicații Google. Cine le-a făcut pe ambele și-a făcut partea și poate, la nevoie, dovedi că a acționat cu diligență.
Întrebări frecvente
Cine este responsabil pentru actualizarea PHP la web hosting?
La shared hosting, de regulă furnizorul de hosting, deoarece el operează serverul și instalarea PHP. Dumneavoastră sunteți responsabil pentru site-ul dumneavoastră, pentru accesurile dumneavoastră și pentru alegerea versiunii PHP în meniul clientului. La serverele gestionate, contractul reglementează împărțirea.
De ce afișează furnizorul meu de hosting o versiune PHP veche?
Mulți furnizori de hosting și multe distribuții încorporează corecția ca backport în versiunea existentă. Numărul rămâne atunci același, deși vulnerabilitatea este închisă. De aceea, bazați-vă pe o confirmare scrisă a furnizorului de hosting, nu pe afișaj.
Ce pot verifica singur ca client de hosting?
Puteți controla versiunea PHP setată în meniul clientului, puteți parcurge conturile de administrator ale CMS-ului dumneavoastră, puteți căuta fișiere necunoscute în directorul de upload și puteți verifica avertismentele din Search Console. Nivelul de patch al serverului în sine îl poate dovedi doar furnizorul de hosting.
Ajută o setare de firewall din pachetul de hosting?
Regulile de firewall ale furnizorului de hosting sau ale unui serviciu plasat în față pot reduce riscul. Ele nu înlocuiesc însă actualizarea PHP de pe server. De aceea, întrebați întotdeauna mai întâi despre actualizare.