PHP2Shell este numele folosit pentru vulnerabilitățile critice PHP divulgate la 21 octombrie 2026. Dacă site-ul tău rulează PHP, întrebarea imediată este dacă mediul de execuție care deservește vizitatorii include corecțiile de securitate. Actualizarea unui plugin sau un panou de firewall afișat cu verde nu răspunde la această întrebare.
PHP2Shell afectează mediul de execuție PHP de sub site-uri și poate permite executarea de cod de la distanță fără autentificare. PHP a publicat corecții în 8.2.35, 8.3.36, 8.4.27 și 8.5.12, iar tu trebuie să confirmi o versiune corectată sau un backport documentat de furnizor în mediul care deservește efectiv cererile web. Păstrează controalele defensive active, dar nu considera un WAF sau o modificare temporară de configurare drept înlocuitor pentru patch.
Stare verificată: 21 octombrie 2026, 17:15 UTC. Acest ghid reflectă corecțiile publicate, nu anunțul anterior potrivit căruia lansarea era încă în așteptare. Verifică din nou avertizările indicate înainte de a face modificări, deoarece pachetele furnizorilor și recomandările de răspuns pot evolua rapid.
PHP2Shell: ce s-a confirmat efectiv?
Echipa de securitate PHP identifică două vulnerabilități care pot permite executarea de la distanță fără autentificare. Avertizarea sa oficială arată că instalațiile PHP care deservesc cereri web sunt expuse și evidențiază Apache cu mod_php drept configurația cu riscul cel mai ridicat. Mediul de execuție, compilarea și gestionarea cererilor influențează posibilitatea de exploatare.
| Identificator | Descrierea PHP | Riscul practic |
|---|---|---|
| CVE-2026-109618 | Corupere la epuizarea memoriei în timpul curățării cererii | O stare nevalidă a cererii poate fi folosită când PHP gestionează un eșec de alocare |
| CVE-2026-109619 | Stare globală reziduală care aparține cererii | O cerere ulterioară pe același proces worker poate întâlni referințe către memorie eliberată |
Ambele avertizări au un scor CVSS v4.0 de 9.2. Citește rapoartele primare pentru CVE-2026-109618 și CVE-2026-109619 , în loc să te bazezi pe soluția provizorie propusă într-o postare pe rețele sociale.
Acesta este un motiv să acționezi prompt, nu o dovadă că fiecare site PHP a fost deja compromis. O vulnerabilitate critică, o tentativă de atac și o intruziune confirmată sunt constatări diferite. Răspunsul tău trebuie să stabilească situația aplicabilă propriilor sisteme.
Ce versiuni PHP corectează PHP2Shell?
Versiunile de securitate pentru ramurile întreținute, publicate astăzi, sunt enumerate mai jos. Tabelul versiunilor este un punct de pornire pentru verificarea unei instalări upstream. Pachetele distribuțiilor pot include corecțiile într-o revizie diferită a pachetului.
| Ramură PHP | Versiunea de securitate care corectează ambele vulnerabilități |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Aceste versiuni sunt confirmate în anunțurile de lansare PHP . Dacă furnizorul distribuției sau al găzduirii folosește corecții retroportate, solicită avertizarea sa de securitate și revizia exactă a pachetului instalat. Un simplu șir de versiune poate clasifica greșit un pachet al furnizorului deja corectat sau un mediu de execuție inclus, dar depășit.
PHP 8.1 și versiunile mai vechi nu mai primesc actualizări upstream obișnuite. PHP a oferit și backport-uri minime ale codului sursă pentru 7.4, 8.0 și 8.1, dar acestea nu restabilesc suportul continuu. Stabilește o corecție susținută de un furnizor responsabil sau un plan de actualizare. Tabelul de suport PHP explică suportul actual al ramurilor.
Verifică separat containerele, instalările PHP încorporate și echipamentele de tip appliance. Recomandările operaționale NCSC-NL avertizează explicit că actualizarea PHP pe gazdă nu actualizează neapărat aceste medii de execuție.
Sunt afectate WordPress, Laravel și alte site-uri PHP?
Începe cu interpretorul care execută aplicația. Un site WordPress, o aplicație Laravel și un portal PHP personalizat pot folosi un mediu de execuție depășit, chiar dacă au coduri de aplicație complet diferite. Instalarea celei mai recente versiuni de temă, plugin sau framework nu instalează o corecție de securitate pentru mediul de execuție PHP.
Pentru găzduirea administrată, întreabă ce versiune PHP sau pachet corectat deservește fiecare site, dacă modificarea a ajuns pe fiecare nod și dacă procesele worker au fost repornite acolo unde era necesar. Solicită dovezi de la platforma de găzduire, în loc să interpretezi o notificare de actualizare a aplicației drept confirmare.
Pentru sistemele administrate intern, include în inventar site-urile secundare, interfețele administrative, gazdele virtuale vechi și mediile de previzualizare. O aplicație de producție poate fi actualizată în timp ce un site mai vechi rămâne accesibil public pe aceeași infrastructură. Înregistrează un responsabil și o decizie de remediere pentru fiecare mediu expus.
Nu deduce că un formular de încărcare nefolosit face o implementare sigură. Avertizările PHP descriu căi de procesare a cererilor în mediul de execuție. Funcțiile aplicației vizibile unui vizitator nu reprezintă o evaluare completă a expunerii.
Cum aplici patch-ul și verifici mediul care deservește vizitatorii
Stabilește ce rulează efectiv
Identifică integrarea cu serverul web, pachetul mediului de execuție sau imaginea containerului, sursa configurației și responsabilul serviciului. Corelează inventarul cu numele de gazdă utilizat de clienți. Un inginer care verifică gazda greșită poate produce un raport de versiune convingător, dar irelevant.
Aceste comenzi doar pentru citire identifică instalarea din linia de comandă și configurația ei:
1php -v
2php --ini
Ele nu dovedesc ce rulează PHP-FPM, Apache sau o altă integrare care deservește cereri web. Folosește informații de găzduire autentificate sau o verificare administrativă controlată pentru a stabili mediul de execuție folosit. Nu lăsa publică o pagină de diagnostic care expune configurația și detaliile mediului.
Pentru o implementare în containere, verifică imaginea și instanța aplicației care primesc efectiv trafic, nu doar imaginea înlocuitoare dintr-un registru. Include în evidența modificărilor toate instanțele din spatele echilibratorului de sarcină și serviciile worker separate, dacă există.
Aplică remedierea oferită de furnizor și testează aplicația
Folosește procedura de actualizare documentată a sursei de pachete întreținute sau a furnizorului imaginii. Înregistrează revizia instalată și avertizarea furnizorului care acoperă ambele CVE-uri. Planifică repornirile serviciilor sau înlocuirea instanțelor potrivit implementării, fără să presupui că descărcarea unui pachet modifică procesele care rulează.
Păstrează jurnalele relevante înaintea modificărilor care pot întrerupe serviciul. Menține o copie de siguranță verificată și un plan de recuperare, apoi testează fluxuri reprezentative ale aplicației după actualizare. Autentificarea, sesiunile, finalizarea comenzilor, încărcările și procesarea în fundal sunt candidate utile acolo unde aplicația le utilizează.
Finalizează schimbarea verificând din nou mediul de execuție care deservește cererile. Păstrează dovezi despre instanțele actualizate, momentul redirecționării traficului și persoana care a acceptat verificările aplicației. Un proces de implementare marcat ca reușit este o dovadă utilă, dar nu reprezintă întreaga verificare.
Protejează WAF Cloudflare împotriva PHP2Shell?
Cloudflare raportează că a implementat protecții WAF pentru PHP2Shell pentru clienții WAF Free și plătiți și că a observat trafic de atac. Anunțul descrie protecții care iau în calcul informații despre cerere și răspuns. De asemenea, recomandă explicit clienților să aplice corecțiile PHP în ciuda acestor protecții.
Pentru un anumit site, confirmă că traficul relevant trece efectiv prin serviciul protejat și că regulile aplicabile sunt active. Revizuiește excepțiile, regulile de ocolire și orice origine accesibilă separat. Acestea sunt verificări ale implementării, nu o afirmație că anunțul Cloudflare garantează protecție pentru orice cale posibilă către aplicație.
Păstrează datele evenimentelor WAF ca parte a investigației. O cerere blocată poate demonstra că o regulă a identificat acea cerere. Nu poate certifica faptul că originea nu a fost accesată pe altă cale sau că nu a avut loc o intruziune anterioară.
Folosește WAF ca un strat defensiv suplimentar în timp ce finalizezi actualizarea mediului de execuție. Nu amâna corecția PHP doar pentru că panoul înregistrează tentative blocate.
Măsurile temporare nu reprezintă o remediere completă pentru PHP2Shell
Dacă aplicarea patch-ului este temporar blocată, urmează avertizările PHP actuale împreună cu inginerul sau furnizorul responsabil de sistem. Avertizarea privind starea reziduală
explică de ce dezactivarea session.upload_progress.enabled trebuie să aibă loc înainte de parsarea cererii și necesită repornirea proceselor worker. Avertizează explicit să nu te bazezi pe ini_set() sau pe .user.ini din FPM în acest scop.
Acea schimbare blochează căile confirmate legate de sesiuni, nu toate variantele. PHP 8.5 are și recomandări separate privind fatal_error_backtraces. Copierea unui scurt fragment de configurare de pe un forum nu dovedește că ambele vulnerabilități au fost tratate.
Avertizarea privind epuizarea memoriei descrie alte controale, inclusiv limite pentru cereri și modificări ale gestionării limitelor de memorie. Acestea au implicații asupra resurselor și disponibilității. Analizează instrucțiunile complete pentru implementarea reală, în loc să elimini cu ușurință limitele de memorie pe un server de producție.
Dacă expunerea nu poate fi redusă acceptabil înainte de patch, discută restricționarea accesului public la aplicația afectată. Documentează măsura temporară, limitele ei, persoana responsabilă și remedierea permanentă planificată. O soluție provizorie trebuie să aibă o condiție de eliminare sau revizuire, nu să devină o setare permanentă nedocumentată.
Ce ar trebui să monitorizezi după verificarea expunerii?
Pornește de la o referință de funcționare normală și păstrează intervalul de timp relevant. Corelează cererile web cu evenimentele PHP, ale serverului web și ale gazdei, în loc să tratezi o singură cerere neobișnuită drept un diagnostic complet. Acolo unde lipsesc jurnale, înregistrează explicit această limitare.
| Observație | Întrebare pentru investigație |
|---|---|
| Opriri neașteptate ale proceselor PHP sau erori de memorie | S-a schimbat comportamentul aplicației și ce cereri au fost gestionate în apropierea acelui moment? |
| Fișiere executabile noi sau modificate | A existat o implementare aprobată sau o scriere neexplicată? |
| Procese copil sau conexiuni de ieșire neașteptate | Procesul web are un motiv legitim pentru acea activitate? |
| Detectări WAF și înregistrări de acces la origine | Ce cereri au fost blocate și ce căi au ajuns la origine? |
| Modificări ale conturilor, sarcinilor programate sau secretelor | Fiecare modificare poate fi atribuită unui operator autorizat? |
Acestea sunt puncte de pornire pentru investigație, nu indicatori specifici PHP2Shell sau dovezi de compromitere. Operațiunile normale pot produce simptome similare. Totodată, absența alertelor nu dovedește că un sistem fără patch era sigur.
Dacă dovezile sugerează o intruziune, păstrează-le și organizează gestionarea incidentului în paralel cu aplicarea patch-ului. Actualizarea interpretorului nu elimină persistența, nu anulează furtul acreditărilor și nu stabilește ce date au fost accesate. Tratează aceste aspecte ca întrebări separate în planul de răspuns.
Întrebări frecvente
Ce este exploitul PHP2Shell? PHP2Shell desemnează vulnerabilitățile PHP urmărite ca CVE-2026-109618 și CVE-2026-109619. Ele privesc gestionarea memoriei în mediul de execuție și pot permite executarea de cod de la distanță fără autentificare. Nu sunt doar un defect al unui plugin WordPress.
Ce versiuni ar trebui să verific pentru patch-ul PHP2Shell? Corecțiile pentru ramurile cu suport, publicate la 21 octombrie 2026, sunt PHP 8.2.35, 8.3.36, 8.4.27 și 8.5.12. Pentru backport-urile distribuțiilor, obține avertizarea furnizorului și confirmă revizia exactă a pachetului corectat instalat în mediul care deservește cererile.
Actualizarea WordPress remediază PHP2Shell? Actualizarea exclusivă a WordPress nu actualizează interpretorul PHP de dedesubt. Menține aplicația actualizată, dar verifică separat corecția de securitate a mediului de execuție PHP cu furnizorul de găzduire sau inginerul responsabil de server.
Un site aflat în spatele Cloudflare este automat sigur? Cloudflare raportează protecții WAF, dar traseul traficului, regulile aplicabile și expunerea originii necesită în continuare verificare. Păstrează protecțiile active și corectează PHP. Un panou de firewall nu dovedește că mediul de execuție este remediat sau că nu a existat o compromitere anterioară.
Este suficientă dezactivarea progresului încărcărilor din sesiuni? Nu. PHP descrie măsura drept blocare a căilor confirmate legate de sesiuni, nu a tuturor variantelor. Trebuie aplicată la nivelul corect al configurației, cu repornirea proceselor worker. Rămâne necesară actualizarea la un mediu corectat sau la un backport verificat al furnizorului.
Pot testa un exploit public pe site-ul meu de producție? Preferă dovezi privind versiunile, pachetele și configurația pentru verificarea inițială. Dacă validarea cere testare cu exploit, organizeaz-o cu autorizare explicită într-un mediu controlat, cu izolare, monitorizare și plan de recuperare. Nu rula scripturi de exploatare neverificate în producție.
Instalarea patch-ului dovedește că serverul nu a fost compromis? Nu. Patch-ul tratează vulnerabilitățile mediului de execuție, în timp ce evaluarea incidentului examinează activitatea anterioară, persistența, acreditările și posibilul acces la date. Menține aceste activități corelate și consemnează limitele dovezilor disponibile.
Ai nevoie de ajutor pentru verificarea, monitorizarea sau corectarea site-ului PHP?
Te putem ajuta să stabilești ce medii de execuție PHP deservesc site-urile tale, să evaluezi expunerea, să analizezi jurnalele și controalele defensive disponibile și să planifici patch-ul sau trecerea necesară la o versiune cu suport. Dacă mediul necesită supraveghere continuă, putem conveni un domeniu de monitorizare, responsabilitatea pentru alerte și un proces de escaladare în funcție de riscurile identificate.
Serviciul nostru de securitate a aplicațiilor sprijină evaluarea și investigația, iar serviciul de securitate a serverelor acoperă zona găzduirii și a configurării. Putem colabora cu furnizorul tău de găzduire pentru a verifica remedierile furnizorului, coordona modificările și documenta verificările aplicației după actualizare.
Rezultatul util este o evidență clară a ceea ce a fost verificat, corectat, rămâne incert și are un responsabil pentru urmărire. Nu promitem o certificare a siguranței pe baza unui șir de versiune sau a unei singure scanări. Domeniul lucrării și disponibilitatea se stabilesc înainte de începerea activității.
Contactează-ne pentru verificarea expunerii la PHP2Shell, monitorizare de securitate sau asistență la aplicarea patch-urilor . Include soluția de găzduire, domeniile afectate, versiunile PHP cunoscute și persoana autorizată să aprobe modificări. Nu trimite parole sau tokenuri de acces în solicitarea inițială.