Situația actuală: PHP2Shell. Două vulnerabilități critice PHP (CVSS 9.2) permit cod malițios fără autentificare. Patchuri din 21.10.2026.Ce este de făcut acum →

Actualizăm, oprim sau așteptăm? Un ajutor de decizie pentru breșa PHP

La o breșă critică în PHP, responsabilii trebuie să decidă rapid. Acest ajutor ordonează cele trei opțiuni, enumeră criterii și arată când așteptarea este justificabilă.

Stadiu 5 min de cititAjutoare de decizie

Pe scurt: Dacă ar trebui să vă scoateți site-ul offline din cauza breșei PHP depinde de o întrebare: rulează PHP pe acest server dovedit într-o stare remediată și au fost repornite toate procesele? Dacă da, nu este necesară nicio oprire. Dacă actualizarea nu este posibilă imediat, BSI recomandă scoaterea temporară a serverului web din rețea. Așteptarea este justificabilă doar dacă sistemul nu folosește PHP, nu este accesibil public sau furnizorul a confirmat în scris patchul.

Situația în care trebuie să decideți

PHP2Shell cuprinde două breșe în PHP însuși, CVE-2026-109618 și CVE-2026-109619, ambele evaluate cu CVSS v4.0 9.2. Ele permit executarea de cod malițios de la distanță, fără autentificare. Versiunile remediate sunt disponibile din 21.10.2026: 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Pentru PHP 8.1 și mai vechi nu mai există actualizări oficiale.

BSI (Oficiul Federal German pentru Securitatea Informațiilor) a emis nivelul de avertizare portocaliu și recomandă actualizarea imediată, ca alternativă oprirea temporară. Potrivit presei, orașul Mainz, instituții ale guvernului landului Hessa și alte instituții publice au scos preventiv site-uri din rețea; Cancelaria de Stat din Hessa nu a raportat niciun atac. Ce pot deduce companiile din aceasta se află la Autoritățile scot site-uri din rețea.

Pentru responsabilii din companii, întrebarea este mai practică: ce facem astăzi cu magazinul nostru online, portalul nostru, site-ul firmei?

Oprirea site-ului, actualizarea sau așteptarea: cele trei opțiuni comparate

Tabelul următor pune opțiunile una lângă alta. El nu înlocuiește evaluarea cazului dumneavoastră concret, dar face vizibilă cântărirea.

Criteriu Patch imediat Oprire temporară Așteptare
Protecție împotriva PHP2Shell Ridicată, dacă patchul și repornirea sunt dovedite Ridicată pe durata opririi Niciuna, cât timp nu este actualizat
Întrerupere a activității Scurtă, pentru actualizare și repornire Ore până la zile Niciuna
Condiție prealabilă Versiune PHP suportată, acces, fereastră de mentenanță Decizia conducerii, pagină statică de înlocuire Motiv dovedit pentru care nu există risc
Efort Redus până la mediu Redus tehnic, ridicat organizatoric Redus, dar efort de verificare pentru dovadă
Caz tipic Server cu PHP 8.2 până la 8.5 Sistem vechi cu PHP 8.1 sau mai vechi, stare neclară Sistem fără PHP sau accesibil doar intern
Risc rezidual O intruziune anterioară rămâne posibilă O intruziune anterioară rămâne posibilă Existent integral

Un rând merită atenție: nici patchul, nici oprirea nu lămuresc dacă s-a întâmplat ceva înainte. Potrivit presei, prima tentativă de atac observată a avut loc la 17.10.2026, deci înaintea patchului. O privire asupra posibilelor urme aparține de aceea fiecărei opțiuni.

În cinci întrebări către decizie

Parcurgeți întrebările pe rând. Primul răspuns clar duce de obicei la decizie.

  1. Rulează pe sistem PHP și este accesibil din internet? Dacă nu, sistemul nu este afectat direct de PHP2Shell. Documentați cum ați stabilit acest lucru.
  2. Este dovedită starea patchurilor? Dovedită înseamnă: versiune remediată sau backport cu numere CVE în changelog-ul pachetului și repornirea tuturor proceselor PHP. Un afișaj de versiune în panou nu este suficient. Cum verificați aflați la Verificarea corectă a versiunii PHP și a nivelului de patch.
  3. Poate fi instalată actualizarea în următoarele ore? Dacă da: patch, repornire, verificare. Până atunci pot ajuta măsuri provizorii.
  4. Nu este posibil, de exemplu din cauza PHP 8.1 sau a lipsei accesului? Atunci oprirea temporară este, potrivit BSI, calea. Măsurile provizorii conform php.net reduc riscul, dar nu protejează complet; detaliile se află la Măsuri imediate dacă nu puteți încă aplica patchul.
  5. Există semne de compromitere? Atunci întrebarea nu mai este „patch sau oprire”, ci „tratarea incidentului”. Opriți, securizați probele, nu ștergeți în grabă.

Dacă opriți: opriți corect

O oprire trebuie să elimine suprafața de atac, nu doar să ascundă pagina de start. O pagină de mentenanță care este generată în continuare de PHP nu îndeplinește acest scop. Mai bună este o pagină HTML statică, pe care serverul web o livrează fără PHP, sau o redirecționare către un alt server.

Gândiți-vă la tot ce depinde de același PHP: subpagini, interfețe pentru aplicații sau gestiunea mărfurilor, zone de administrare, apeluri inverse de plată. Discutați în prealabil cu furnizorul de plăți și cu logistica dacă este afectat un magazin online. Și informați angajații și clienții în cuvinte clare: pagina este offline preventiv, contactul se face prin telefon și e-mail. Este mai bine decât tăcerea, care alimentează speculațiile.

Important este și sfârșitul opririi. Stabiliți în ce condiție pagina revine online, de exemplu „PHP într-o stare remediată, repornire verificată, prima verificare a urmelor fără constatări”. Astfel, o frână de urgență devine o procedură ordonată.

Important

Oprirea nu este o înfrângere. Potrivit presei, mai multe instituții publice au făcut exact acest lucru, fără să fi existat un atac. O oprire preventivă nu înseamnă automat că un site a fost spart.

Când nu aveți nevoie de un furnizor de servicii

Nu orice decizie necesită ajutor extern. Dacă site-ul dumneavoastră se află la un furnizor de hosting care confirmă în scris starea patchurilor și repornirea și nu există anomalii, sunteți bine poziționat cu o scurtă documentare. Același lucru se aplică dacă propriul IT poate aplica singur patchul pe un server cu versiune PHP suportată și stăpânește verificarea.

Ajutorul merită atunci când rulează sisteme cu versiune PHP veche, starea este neclară, sunt afectate mai multe servere sau există semne ale unei intruziuni.

Cum ajută PHP SOS concret?

  1. Clarificăm împreună cu dumneavoastră, într-un timp scurt, ce sisteme sunt afectate și ce stare a patchurilor este dovedită.
  2. Livrăm conducerii o bază de decizie pe o pagină: opțiuni, riscuri, calea recomandată.
  3. Punem în aplicare calea aleasă, adică patch cu repornire, măsuri provizorii sau o oprire curată cu pagină statică de înlocuire, ca parte a ajutorului nostru imediat PHP2Shell.
  4. Verificăm urmele începând cu 17.10.2026 și documentăm rezultatul.

Concluzie

Patchul este cazul normal, oprirea frâna de urgență corectă, așteptarea justificabilă doar cu dovadă. Cine răspunde sincer la cele cinci întrebări și consemnează decizia în scris acționează în spiritul recomandării BSI și poate arăta mai târziu de ce.

Întrebări frecvente

Trebuie să îmi scot site-ul offline din cauza PHP2Shell?

Nu, dacă PHP rulează deja într-o stare remediată și toate procesele au fost repornite. BSI recomandă oprirea temporară pentru cazul în care o actualizare imediată nu este posibilă.

Ce costă mai mult o oprire: veniturile sau riscul?

La aceasta se poate răspunde doar de la caz la caz. O indisponibilitate de câteva ore este de obicei mai bine planificabilă decât o intruziune ale cărei consecințe și durată nu le cunoaște nimeni. Consemnați cântărirea în scris, indiferent cum se încheie.

Are voie o pagină de mentenanță să ruleze pe același server?

Da, dacă este livrată ca fișier static, fără PHP. Dacă pagina de mentenanță este generată în continuare de PHP, suprafața de atac rămâne.

Este vreodată așteptarea alegerea corectă?

Da, în cazuri clar delimitate: dacă pe sistem nu rulează PHP, dacă nu este accesibil din internet sau dacă furnizorul a confirmat în scris patchul și repornirea. Așteptarea fără astfel de dovezi nu este o opțiune, ci un risc.

Cine ar trebui să ia decizia?

Persoana care răspunde de riscul de afaceri, de regulă conducerea sau proprietarul. IT-ul furnizează faptele. Cine decide ar trebui să fie stabilit în prealabil în planul de urgență.

Surse

Contact imediat

Fiecare oră contează. Scrieți-ne acum.

Descrieți pe scurt sistemul, versiunea PHP și ce ați observat. Ne vom face auziți, clarificăm situația și lucrăm la distanță până când incidentul este încheiat și documentat.

Ajutor imediat