Pe scurt: Vulnerabilitatea PHP2Shell constă în două erori critice în PHP, baza majorității site-urilor și magazinelor online. Prin ele, atacatorii pot executa cod malițios pe servere web fără parolă. BSI (Oficiul Federal German pentru Securitatea Informațiilor) avertizează cu nivelul portocaliu și recomandă: actualizați imediat, altfel scoateți temporar din rețea serverele afectate. Pentru conducere, aceasta înseamnă astăzi: clarificați responsabilitatea, cereți actualizarea și dovada, decideți asupra unei opriri și documentați totul.
Situația în trei propoziții
Pe 21 octombrie 2026, proiectul PHP a publicat actualizări pentru două vulnerabilități critice, cunoscute sub numele PHP2Shell. Este afectat PHP însuși, nu un produs anume, deci potențial orice site, orice magazin și orice portal care rulează cu PHP. BSI a declarat nivelul de alertă 3 / portocaliu, firme de securitate relatează încercări de atac, iar atacuri reușite confirmate pe scară largă nu erau cunoscute inițial, potrivit BSI.
Autorități precum BKA (Oficiul Federal German de Poliție Criminală) și mai multe orașe și-au oprit site-urile preventiv, potrivit relatărilor din presă. A fost prudență, nu semnul unui atac.
Ce înseamnă vulnerabilitatea PHP pentru conducere și companii
Întrebarea nu este dacă folosiți PHP. Aproape orice companie o face undeva: site, magazin, portal pentru candidați, zonă pentru clienți, intranet, sistem de tichete, microsite al unei agenții. Întrebarea este dacă aceste sisteme sunt la zi și cine este responsabil pentru ele.
Dacă un atac reușește, atacatorul poate, în cel mai rău caz, prelua serverul. Consecințe posibile sunt scurgerea de date, conținut manipulat, redirecționări către pagini de fraudă, indisponibilitatea magazinului sau folosirea abuzivă a serverului pentru alte atacuri. Dacă pot fi afectate date cu caracter personal, apar obligații de notificare; termenul conform art. 33 RGPD este, de regulă, de 72 de ore. Detalii se află la obligația de notificare conform RGPD. Aceasta nu este consultanță juridică.
Ce costuri apar de obicei în caz grav încadrează articolul Posturi de cost ale unui hack.
Unde este adesea trecut cu vederea PHP în companii
Site-ul principal îl au în vedere majoritatea. Sunt trecute mai degrabă cu vederea sistemele de la margine: portalul pentru candidați al unui furnizor extern, landing page-ul unei campanii anterioare, o zonă de parteneri pentru comercianți, sistemul de tichete al suportului, un cloud de fișiere pe un server propriu sau interfața web a unui stocator de rețea. Și sistemele de test ale agențiilor sunt adesea accesibile public și rulează pe același server cu site-ul real.
Pentru conducere, lecția este simplă: întrebarea către IT nu este „Este site-ul nostru actualizat?”, ci „Sunt actualizate toate sistemele noastre cu PHP, inclusiv cele ale prestatorilor?”. Diferența dintre cele două întrebări este adesea exact locul în care un atac reușește.
Ce nu este situația
La fel de important este încadrarea în jos. PHP2Shell nu este un motiv de activism care deranjează funcționarea mai mult decât este necesar. Cine a actualizat dovedit, a repornit toate procesele PHP și nu găsește nimic neobișnuit la verificare poate reveni la funcționarea normală. O oprire temporară este o opțiune pentru cazurile neclarificate, nu o obligație pentru toți.
Cinci întrebări pentru IT sau prestatorul dumneavoastră
Aceste întrebări le puteți pune astăzi. Răspunsurile ar trebui să vină în scris.
- Care dintre sistemele noastre rulează cu PHP? O listă cu adresă, scop și operator.
- Este fiecare sistem actualizat? Versiune corectată 8.5.12, 8.4.27, 8.3.36 sau 8.2.35, ori un backport confirmat de furnizor.
- Au fost repornite toate procesele PHP? Fără repornire, actualizarea nu are efect.
- Ce se întâmplă cu sistemele pe PHP 8.1 sau mai vechi? Pentru acestea nu există actualizări oficiale. Care este planul?
- S-a verificat dacă s-a întâmplat ceva înainte de actualizare? Loguri salvate începând cu 20 octombrie, urme căutate?
Dacă site-ul dumneavoastră se află la un furnizor de hosting, ajută o solicitare formală. Un model oferă ghidul Solicitarea confirmării actualizării PHP de la furnizorul de hosting.
Deciziile care ar trebui luate astăzi
| Decizie | Opțiuni | Temei |
|---|---|---|
| Cine conduce? | o persoană responsabilă intern, un partener extern | responsabilitatea trebuie să fie clară |
| Sisteme neactualizate | actualizare imediată, măsuri provizorii, oprire temporară | recomandarea BSI, situația datelor, relevanța pentru venituri |
| Verificarea urmelor | intern, extern, doar la constatări neobișnuite | nevoia de protecție a datelor de pe server |
| Comunicare | informare internă, pregătirea clienților, așteptare | situația după verificare |
| Sisteme vechi | planificați migrarea, izolați, opriți | PHP 8.1 și mai vechi, fără actualizări oficiale |
Consemnați cine a decis ce, când și pe ce bază de informare. O notă scurtă, datată, este suficientă. Ulterior, față de asigurători, clienți sau autorități de supraveghere, ea valorează adesea mai mult decât orice explicație dată după aceea.
De ce este importantă această documentare pentru conducere explică pagina Răspunderea conducerii în cazul vulnerabilităților de securitate IT. Aceasta este informare generală și nu consultanță juridică.
Ce nu ar trebui să credeți
Trei afirmații aud directorii frecvent în prezent, iar toate trei sunt false:
- „Am actualizat WordPress, deci suntem în siguranță.” Vulnerabilitatea se află în PHP, nu în CMS. O actualizare a CMS-ului nu o închide.
- „Suntem prea mici, nu ne atacă nimeni.” Atacurile se desfășoară automatizat. Se caută servere vulnerabile, nu nume cunoscute.
- „Actualizarea este instalată, deci subiectul este încheiat.” Un patch nu elimină software malițios introdus înainte și nu dovedește că nu s-a întâmplat nimic.
Cum ajută PHP SOS concret?
- Imagine de situație pentru conducere: Întocmim o scurtă prezentare a sistemelor dumneavoastră PHP, cu starea și recomandarea pentru fiecare sistem.
- Punerea în aplicare: Aplicăm patchul, repornim sau setăm măsuri provizorii acolo unde o actualizare nu este încă posibilă.
- Verificare: Salvăm logurile și căutăm urme ale unui atac.
- Dovadă: Primiți o documentație pe care o puteți folosi intern și față de terți.
Desfășurarea o descrie asistența de urgență PHP2Shell.
Concluzie
PHP2Shell este o vulnerabilitate tehnică cu o sarcină de management. Tehnica o rezolvă specialiștii. Conducerea se asigură că cineva este responsabil, că cele cinci întrebări primesc răspuns și că deciziile sunt luate în mod conștient și documentate. Încape într-o dimineață, dacă începe astăzi.
Întrebări frecvente
Trebuie conducerea să se ocupe personal de PHP2Shell?
Nu de implementarea tehnică, dar da de coordonare. Conducerea ar trebui să se asigure că responsabilitățile sunt clare, că recomandarea BSI este pusă în aplicare și că deciziile, precum o oprire temporară, sunt luate în mod conștient și documentate.
Cum explic vulnerabilitatea într-o singură propoziție?
În PHP, software-ul pe care rulează majoritatea site-urilor și magazinelor, există două erori critice prin care persoane străine pot porni programe pe server fără parolă; există o actualizare disponibilă și trebuie instalată.
Cât costă să nu faci nimic?
Nu se poate cuantifica la nivel general. Consecințe posibile ale unui atac reușit sunt timpi de nefuncționare, scurgere de date, obligații de notificare, efort de curățare și de analiză criminalistică IT, precum și pierderea încrederii clienților. O actualizare cu verificare este, de regulă, mult mai puțin costisitoare.
Este suficient dacă se ocupă furnizorul de hosting?
La shared hosting, furnizorul de hosting instalează, de regulă, actualizarea. Cereți o confirmare scrisă, inclusiv pentru repornirea proceselor PHP. Dacă s-a întâmplat ceva înainte de actualizare, confirmarea nu răspunde; pentru aceasta este nevoie de o verificare a site-ului.