Pe scurt: PHP2Shell și Log4Shell au în comun faptul că sunt vulnerabilități critice într-un element de bază foarte răspândit, prin care atacatorii pot executa cod fără autentificare. Ele diferă prin vizibilitate, încadrare și situația atacurilor cunoscute. Cea mai importantă lecție din Log4Shell se aplică astăzi neschimbat: cine știe unde rulează elementul afectat acționează în ore, nu în săptămâni.
De ce apare comparația tocmai acum peste tot
În decembrie 2021, Log4Shell a ținut lumea IT în tensiune săptămâni întregi. BSI (Oficiul Federal German pentru Securitatea Informațiilor) a declarat atunci cel mai înalt nivel de alertă, roșu. Aproape cinci ani mai târziu, la PHP2Shell apare în multe articole același nume, adesea însoțit de întrebarea: „Va fi iar la fel de grav?”
Comparația este la îndemână și este utilă dacă este făcută corect. Ea arată ce tipare se repetă și ce experiențe pot folosi direct companiile astăzi. Cum încadrează BSI situația actuală explică articolul Nivelul de alertă portocaliu BSI.
PHP2Shell și Log4Shell în comparație directă
| Trăsătură | Log4Shell (2021) | PHP2Shell (2026) |
|---|---|---|
| Software afectat | biblioteca Java Log4j | mediul de execuție PHP însuși |
| Identificator | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 |
| Evaluare | CVSS 10.0 (v3) | CVSS v4.0 9.2 |
| Efect | execuție de cod fără autentificare | execuție de cod fără autentificare |
| Nivel de alertă BSI | 4 / roșu | 3 / portocaliu |
| Situația la avertisment | compromiteri cunoscute, potrivit relatărilor de atunci | încercări de atac relatate, potrivit BSI inițial fără atacuri reușite confirmate pe scară largă |
| Vizibilitate | adesea ascuns adânc în aplicații | vizibil pe server, dar nivelul de patch greu de citit din cauza backporturilor |
| Anunțuri ulterioare | mai multe CVE-uri suplimentare în câteva săptămâni | indicație despre CVE-2026-115560 pe 23.10. |
Ce au în comun cele două vulnerabilități
Un element de bază, nenumărate aplicații. Log4j se afla în software Java de tot felul, PHP susține WordPress, Shopware, TYPO3 și nenumărate dezvoltări proprii. În ambele cazuri nu este afectat un produs, ci o fundație.
Nu este nevoie de autentificare. Ambele vulnerabilități permit execuția de cod de la distanță fără autentificare. Aceasta le face atractive pentru atacuri automatizate.
Patchul nu este sfârșitul. La Log4Shell s-a văzut că multe sisteme fuseseră atacate deja înainte de actualizare. Și la PHP2Shell se aplică: un patch nu elimină software malițios introdus. Potrivit relatărilor din presă, o primă încercare de atac a fost observată deja pe 17 octombrie.
Anunțuri ulterioare. După Log4Shell au apărut, în câteva săptămâni, alte CVE-uri privind Log4j. La PHP a venit, la două zile după patchuri, indicația despre CVE-2026-115560. De ce sunt probabile alte anunțuri explică După PHP2Shell: de ce sunt probabile alte anunțuri.
Unde șchiopătează comparația
Cea mai mare diferență se află în vizibilitate. Log4j era adesea încorporat ca parte a unei aplicații, uneori imbricat de mai multe ori. Mulți operatori pur și simplu nu știau că îl folosesc. PHP, în schimb, nu este un secret pe un server web. În schimb, la PHP2Shell apare o altă neclaritate: distribuțiile și furnizorii de hosting instalează corecții ca backport, iar numărul de versiune afișat rămâne același. PHP se vede, dar nu imediat dacă este actualizat.
O a doua diferență este situația de plecare la actualizare. La Log4Shell, producătorii de aplicații de specialitate trebuiau adesea să livreze mai întâi versiuni noi. La PHP2Shell, actualizările sunt disponibile pentru toate ramurile suportate. Devine dificil la PHP 8.1 și mai vechi, pentru care proiectul PHP nu mai publică actualizări oficiale.
O a treia diferență privește locul atacului. La Log4Shell, orice loc în care o aplicație înregistra intrări putea fi periculos, deci și sisteme interne care primeau date din internet doar indirect. La PHP2Shell, în centru se află serverul web, care primește direct cererile. Aceasta face căutarea sistemelor afectate ceva mai clară: mai întâi vin toate serviciile PHP accesibile public, apoi aplicațiile interne.
În sfârșit, diferă situația exploatării. Pentru Log4Shell au circulat devreme instrumente simple de atac, iar compromiterile erau cunoscute, potrivit relatărilor de atunci, încă de la momentul avertismentului. La PHP2Shell, Cloudflare și Patchstack relatează încercări de atac, watchTowr a reprodus una dintre vulnerabilități, după propriile declarații, iar BSI nu a raportat inițial atacuri reușite confirmate pe scară largă. Aceasta se poate schimba. Este însă un motiv pentru care comparația nu este bună ca prognoză.
Folosiți experiențele din Log4Shell în propria casă: ce liste, procese și contacte au ajutat atunci? Multe dintre ele pot fi reutilizate direct pentru PHP2Shell.
Cinci lecții din Log4Shell care ajută astăzi
- Inventar înainte de patch: Cine avea în 2021 o listă actuală a sistemelor sale a fost mai rapid. Se aplică la fel și astăzi. Un ghid oferă articolul Inventarul tuturor site-urilor și serverelor.
- Cunoașteți dependențele: O listă de componente ale elementelor software, pe scurt SBOM, răspunde în minute la întrebarea „Unde folosim asta?”. Pentru aplicațiile PHP ajută privirea în Composer, descrisă în Verificarea dependențelor Composer.
- Păstrați logurile: După Log4Shell, multe companii nu au mai putut clarifica dacă au fost afectate, deoarece lipseau logurile. Presa de specialitate recomandă la PHP2Shell să salvați logurile începând cu 20 octombrie.
- Verificați ulterior: Un patch nu răspunde la ce s-a întâmplat înainte. O verificare a urmelor face parte din proces.
- Fiți pregătiți pentru anunțuri ulterioare: Prima actualizare este rareori ultima. Cine a configurat o dată corect calea de actualizare o repetă rapid.
Cum ajută PHP SOS concret?
- Inventariere: Stabilim unde rulează PHP în compania dumneavoastră, în ce versiune și mod de operare.
- Patch și repornire: Instalăm actualizări și dovedim starea pentru fiecare sistem.
- Verificarea urmelor: Salvăm logurile și căutăm lucruri neobișnuite începând cu 17 octombrie.
- Observare permanentă: Vă ținem sistemele în vedere, pentru ca anunțurile ulterioare să nu înceapă iar de la zero.
Cum arată monitorizarea continuă descrie Monitorizarea de securitate pentru serverele web.
Concluzie
PHP2Shell nu este Log4Shell, dar rimează. Ambele lovesc o fundație, ambele au nevoie de mai mult decât un patch. Companiile care au preluat din 2021 inventarul, păstrarea logurilor și căile de actualizare sunt astăzi avantajate. Pentru toate celelalte, acum este momentul să recupereze.
Întrebări frecvente
Este PHP2Shell la fel de grav ca Log4Shell?
Ambele sunt vulnerabilități critice în software foarte răspândit, prin care atacatorii pot executa cod fără autentificare. BSI a încadrat Log4Shell în 2021 la roșu, iar PHP2Shell la portocaliu. O deosebire importantă: la Log4Shell erau deja cunoscute, potrivit relatărilor de atunci, compromiteri la momentul avertismentului, iar la PHP2Shell nu erau cunoscute inițial, potrivit BSI, atacuri reușite confirmate pe scară largă.
Ce a fost Log4Shell?
Log4Shell a fost o vulnerabilitate critică în biblioteca Java Log4j, devenită cunoscută în decembrie 2021 și înregistrată sub CVE-2021-44228. Log4j se afla ca element constitutiv în foarte multe aplicații, adesea fără ca operatorii să știe.
Vor veni și alte vulnerabilități după PHP2Shell?
Este posibil. După Log4Shell au urmat, în câteva săptămâni, alte CVE-uri privind Log4j. La PHP a existat deja pe 23 octombrie o indicație despre CVE-2026-115560, care se aplică doar la o configurație neobișnuită. Planificați anunțuri ulterioare.
Ce este un SBOM?
Un Software Bill of Materials este o listă de componente a tuturor elementelor software din care constă o aplicație. Cu ajutorul ei se poate stabili rapid, la o vulnerabilitate nouă, unde este folosit elementul afectat.