Pe scurt: Dacă bănuiți că serverul dumneavoastră a fost hackuit prin PHP2Shell, contactați-ne acum. Sunteți afectat? Sunați-ne. Vă ajutăm. Preluăm, de la primul mesaj, izolarea, conservăm urmele, închidem vulnerabilitatea, eliminăm codul malițios și documentăm incidentul până la încheierea lui.
Acum nu ștergeți nimic și nu reinstalați nimic. Fișierele șterse și logurile suprascrise sunt urmele care arată dacă și cum a pătruns cineva. Scoateți serverul din rețea dacă este necesar, dar lăsați-l neschimbat. Anunțați urgența, iar noi vă spunem următorul pas.
Sunteți afectat? Semne că PHP2Shell a fost deja folosit
PHP2Shell este numele a două vulnerabilități critice din PHP însuși, prin care atacatorii pot executa cod malițios la distanță, fără autentificare. Până acum nu există o amprentă univocă. De aceea contează ce face serverul, nu ce găsește un scanner. Indicii ale unei intruziuni sunt:
- Procese ale serverului web sau PHP-FPM care pornesc un shell precum
shsaubash. Acesta este un semnal de alarmă puternic. - Fișiere PHP noi sau modificate în dosarele de încărcare, de cache sau temporare, pe care nu le-a creat nimeni.
- Cronjoburi, servicii sau chei SSH pe care nu le cunoașteți.
- Conexiuni de ieșire către ținte necunoscute, încărcare brusc ridicată sau trafic neobișnuit.
- Cereri în loguri începând cu 17.10.2026, în special încărcări suspecte și cereri de sesiune înainte de aplicarea patchului.
- Mesaje din partea furnizorului de hosting, a browserului sau a motorului de căutare despre spam, malware sau redirecționări.
Mai multe găsiți la Am fost deja compromis?. Lipsa oricărui semn nu este o dovadă că serverul este curat. Înseamnă doar că, până acum, nu s-a observat nimic.
Ce faceți imediat
- Nu modificați nimic. Nu ștergeți fișiere, nu restaurați un backup, nu reinstalați înainte ca starea să fie salvată.
- Salvați logurile. Rugați furnizorul de hosting sau departamentul IT să nu suprascrie jurnalele de acces, de erori și de sistem. Presa de specialitate recomandă păstrarea logurilor începând cu 20.10.2026.
- Decideți asupra accesibilității. Dacă datele ar putea fi exfiltrate sau vizitatorii ar putea fi puși în pericol, scoateți pagina din rețea sau treceți-o în modul de mentenanță.
- Adunați accesurile. Notați cine are acces la server, panou, CMS și baza de date. Parolele le schimbați abia după înțelegere și de pe un dispozitiv curat.
- Informați persoanele implicate. Conducerea, responsabilul cu protecția datelor și, dacă există o poliță, asigurătorul.
- Sunați-ne sau scrieți-ne. Cu cât cunoaștem mai devreme situația, cu atât mai mult rămâne dovedibil.
Cum ajută PHP SOS concret?
Lucrăm la distanță, fără deplasare, în toată Germania și Europa.
- Imaginea situației: Clarificăm ce sisteme rulează, ce mod de operare PHP este folosit, ce s-a observat și ce date ar putea fi afectate.
- Salvare și închidere: Salvăm fișierele, baza de date și logurile și stabilim starea înainte de orice modificare. Apoi închidem vulnerabilitatea prin patch sau, dacă acesta nu este încă posibil, prin măsuri provizorii, și repornim toate procesele PHP.
- Verificare și curățare: Căutăm webshell-uri, uși dosnice, cronjoburi și accesuri străine și le eliminăm sau reconstruim starea din surse de încredere. Procedura este descrisă la Eliminarea malware-ului și a webshell-urilor.
- Securizare și raport: Schimbăm secretele afectate, completăm măsurile de protecție și livrăm un raport care separă ce este dovedit, probabil și necunoscut.
Dacă incidentul depășește un singur server, trecem la Incident Response structurat. Dacă sunt necesare probe valabile în fața instanței, implicăm criminalistica IT.
De ce un patch singur nu este suficient după un atac
Vulnerabilitățile se află în interpretorul PHP, nu în CMS. Proiectul PHP a publicat la 21.10.2026 versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Cine a actualizat după aceea și a repornit toți workerii este protejat împotriva atacurilor noi pe această cale. Ceea ce a depus un atacator înainte rămâne însă pe loc: un webshell, un cont suplimentar, o sarcină programată. Tocmai de aceea zilele dintre 17 și 21.10. sunt deosebit de importante.
La aceasta se adaugă un al doilea aspect: un webshell este adesea doar primul pas. Cine a putut executa cod pe serverul web a putut citi și fișiere de configurare și a putut prelua din ele accesurile la baza de date, la e-mail și la API. Aceste secrete trebuie înlocuite, altfel ușa rămâne deschisă deși PHP este corectat. Cum verificați rațional fișierele și momentele de timp descrie ghidul despre recunoașterea webshell-urilor.
Obligația de notificare și documentarea
Dacă ar fi putut fi afectate date cu caracter personal, poate deveni necesară o notificare către autoritatea de supraveghere în termen de 72 de ore. Termenul curge de la luarea la cunoștință, nu de la încheierea investigației. Dacă cazul dumneavoastră face obiectul notificării decid responsabilul cu protecția datelor sau avocatul; noi nu oferim consultanță juridică. Documentarea noastră oferă baza pentru aceasta. Mai multe despre termen găsiți la Obligația de notificare RGPD în 72 de ore, iar pașii următori în Lista de verificare după un hack.
Ce ar trebui să ne trimiteți
- Descrierea a ce se observă de când și cine a observat
- Tipul serverului: server propriu, server administrat sau pachet de hosting, plus furnizorul de hosting
- Rezultatul comenzii
php -vși, dacă îl cunoașteți, modul de operare (PHP-FPM, mod_php, LiteSpeed) - Momentul actualizării PHP, dacă a fost deja efectuată
- Accesul la server sau permisiunea de a vorbi cu furnizorul dumneavoastră de hosting
- O persoană de contact cu competență de decizie pentru oprire și reporniri
De ce PHP SOS
Lucrăm Made in Germany și suntem specializați în securitate IT de peste 25 de ani, împreună cu rețeaua noastră de parteneri din profesioniști cyber. Aveți un singur interlocutor, care vă însoțește de la primul mesaj până la încheiere. Tot ce facem este documentat, pentru ca dumneavoastră să puteți dovedi față de conducere, asigurător și autorități. Nu promitem nimic ce nu poate ține nimeni: dacă lipsesc logurile, spunem deschis, și precizăm ce este dovedit și ce rămâne supoziție.
Sunteți afectat? Sunați-ne. Vă ajutăm.
Nu așteptați până când bănuiala devine certitudine. Sunați-ne sau scrieți-ne pe WhatsApp. Preluăm cazul de la primul mesaj și rămânem alături până când incidentul este încheiat și documentat. Anunțați acum urgența.
Întrebări frecvente
Este suficient să actualizez PHP dacă serverul meu a fost poate deja hackuit?
Nu. Actualizarea închide vulnerabilitatea, dar nu elimină software-ul malițios deja introdus și nu dovedește că nu s-a întâmplat nimic înainte. După patch, serverul trebuie verificat pentru urme de intruziune.
Cum recunosc un atac PHP2Shell reușit?
Nu există indicatori de compromitere (IOC) publicați și confirmați. Detectarea se bazează pe comportament: procese ale serverului web care pornesc un shell, fișiere PHP noi în dosarele de încărcare sau de cache, cronjoburi sau chei SSH necunoscute și conexiuni de ieșire suspecte.
Ar trebui să scot serverul din rețea dacă bănuiesc o intruziune?
Adesea este corect, deoarece BSI recomandă chiar, dacă actualizarea nu este posibilă imediat, scoaterea temporară din rețea a serverului web. Important este să nu ștergeți nimic și să păstrați logurile și fișierele, pentru ca incidentul să poată fi elucidat.
Trebuie să informez autoritatea pentru protecția datelor după un atac PHP2Shell?
Dacă ar putea fi afectate date cu caracter personal, poate fi necesară o notificare în termen de 72 de ore. Decizia o luați împreună cu responsabilul dumneavoastră cu protecția datelor sau cu un avocat; noi furnizăm faptele tehnice pentru aceasta.
Au fost deja hackuite servere prin PHP2Shell?
Potrivit rapoartelor din presă, primele tentative de atac au fost observate începând cu 17.10.2026, iar Cloudflare a raportat tentative de atac observate. BSI nu a raportat inițial atacuri reușite confirmate la scară largă. În cazul concret, aceasta se poate clarifica doar pe server.