PHP2Shell, explicat pe înțelesul tuturor

Dacă ai un site, un magazin online sau o aplicație web, sunt șanse mari ca în săptămâna 20–23 octombrie 2026 să nu fi observat nimic. Pentru oamenii care administrează servere, însă, a fost una dintre cele mai tensionate săptămâni din ultimii ani. Unii au oprit servere întregi pentru câteva ore. Guverne europene și-au scos temporar site-urile de pe internet.

Totul a pornit de la două vulnerabilități critice descoperite în PHP, botezate de comunitate PHP2Shell. Mai jos explicăm, fără jargon, ce s-a întâmplat, de unde a pornit, de ce contează și ce ar trebui să faci tu.

Ce este PHP și de ce te privește, chiar dacă n-ai auzit de el

PHP este un limbaj de programare care rulează pe serverul unui site. Când deschizi o pagină, PHP este cel care, în spate, „gătește” pagina: ia produsele din baza de date, verifică dacă ești logat, calculează coșul de cumpărături și trimite rezultatul către browserul tău.

Nu îl vezi niciodată, dar este peste tot. Conform W3Techs, PHP este folosit de aproximativ 70% dintre site-urile la care se poate identifica tehnologia de pe server. Pe PHP rulează WordPress, WooCommerce, Magento, Drupal, Joomla, PrestaShop, Laravel și o mare parte din site-urile instituțiilor publice, ale băncilor și ale magazinelor online.

Cu alte cuvinte: dacă PHP are o problemă gravă, o mare parte din internet are o problemă gravă.

Ce s-a întâmplat, pe scurt

Pe 21 octombrie 2026, echipa PHP a lansat actualizări de urgență pentru două vulnerabilități (codurile oficiale CVE-2026-109618 și CVE-2026-109619). Fiecare a primit un scor de gravitate de 9,2 din 10.

Ce înseamnă concret: în anumite condiții, un atacator putea trimite o cerere special construită către un site și putea ajunge să execute propriul cod pe server, fără să aibă cont, parolă sau vreun alt acces. În limbaj de specialitate se numește „execuție de cod la distanță, fără autentificare” – cel mai grav tip de problemă pe care o poate avea un server web.

Iar pentru că defectul este în PHP însuși, nu într-un anumit site sau plugin, cercetătorii au demonstrat atacul pe versiunile cele mai noi de WordPress, Drupal și Joomla. Teoretic, chiar și o pagină simplă de tip „Hello World” putea fi vulnerabilă.

Cum funcționa problema, explicat cu o analogie

Imaginează-ți un restaurant foarte aglomerat. Ospătarii (în cazul nostru, „procesele” PHP) servesc rând pe rând sute de clienți. După fiecare client, masa trebuie strânsă complet înainte să se așeze următorul.

Cele două probleme arătau cam așa:

• Prima (CVE-2026-109618): dacă un client cerea ceva atât de mare încât bucătăriei i se termina spațiul (în termeni tehnici, serverul atingea limita de memorie), comanda era întreruptă brusc, la jumătate. Masa rămânea pe jumătate pregătită, iar la strângere ospătarul trata acele lucruri neterminate ca și cum ar fi fost în regulă.
• A doua (CVE-2026-109619): uneori, după ce un client pleca, pe masă rămâneau lucruri care nu mai trebuiau să fie acolo. Următorul client, servit de același ospătar, le putea folosi.

Un atacator foarte priceput putea „aranja” intenționat masa astfel încât următorul pas să ajungă să execute instrucțiunile lui. Asta e, foarte simplificat, PHP2Shell.

De unde a pornit: o problemă veche de peste 10 ani

Partea cea mai surprinzătoare este vârsta problemei. Conform cercetătorilor, codul afectat există încă din PHP 5.4, lansat în 2012. Practic, orice versiune de PHP din ultimul deceniu este afectată de cel puțin una dintre cele două probleme.

Și nu a fost complet necunoscută:

• Încă din 2004 și apoi în 2020 au existat semnalări despre probleme în felul în care PHP gestionează epuizarea memoriei.
• În 2024, un dezvoltator din echipa PHP a observat problema de memorie în timp ce repara altceva, în urma primului audit extern de securitate al limbajului. Cineva a teoretizat atunci că ar putea fi exploatată, dar nimeni nu a găsit o cale concretă.
• Echipa a avut mai multe variante de reparație, dar fiecare avea un cost: una strica compatibilitatea cu aplicațiile existente, alta crea risc de blocare a serverelor, alta obliga mii de extensii să fie modificate. Lucrul s-a oprit și a repornit timp de luni de zile.

Fundația PHP a recunoscut deschis, după incident: „Nu vom pretinde altceva: întârzierea a fost un eșec structural.”

Mult timp, exploatarea a fost considerată atât de complicată încât complexitatea însăși funcționa ca o formă de protecție. Pentru un atac real trebuia înțeles exact cum PHP alocă și refolosește memoria, iar fiecare versiune, configurație și aplicație schimba regulile jocului.

Partea cu adevărat nouă: inteligența artificială

Aici povestea devine importantă pentru toată lumea, nu doar pentru programatori.

În vara lui 2026, mai multe echipe au folosit modele de inteligență artificială pentru a analiza codul PHP, independent una de alta:

• 30 iulie: firma de securitate Calif începe un audit al PHP, în cadrul programului „Patch the Planet” al OpenAI, folosind modelul GPT-5.6 Sol.
• 11 august: Calif raportează o vulnerabilitate critică. În aceeași zi, OpenAI raportează independent aceeași cauză.
• 19 august: echipa Wiz Research găsește prima vulnerabilitate folosind propriul sistem AI și modele de la Google și OpenAI.
• 20–21 august: Wiz confirmă că poate prelua controlul asupra unui site Drupal, apoi a unui site WordPress, fără autentificare.
• 24 august: Wiz raportează ambele probleme echipei PHP.

Ce a schimbat AI-ul? Nu a „ghicit” o problemă nouă. A făcut fezabil ceva ce înainte era aproape imposibil de dus la capăt: a ajutat cercetătorii să adapteze atacul la versiuni, configurații și aplicații diferite, să analizeze eșecurile și să încerce din nou, în ore în loc de săptămâni. Wiz susține că un singur cercetător a terminat într-o săptămână ceea ce ar fi luat luni unei echipe de specialiști de top.

De data aceasta, AI-ul a fost în mâinile celor care au găsit problema, au raportat-o și au ajutat la reparare. OpenAI numește această perioadă „fereastra apărătorului”: momentul în care cei buni găsesc problema înaintea atacatorilor și au timp să pregătească reparația.

Întrebarea incomodă este alta: aceleași instrumente sunt disponibile, din ce în ce mai mult, și celor rău intenționați. Data viitoare s-ar putea să nu avem același noroc.

Cronologia săptămânii critice

• 17 octombrie: Amazon observă prima încercare de exploatare în rețeaua sa de „capcane” pentru atacatori – cu patru zile înainte de anunțul public.
• 20 octombrie: codurile vulnerabilităților apar pe forumuri și rețele sociale înainte de termen, cu un scor greșit de 10/10. Seara, un videoclip cu atacul funcționând este publicat din greșeală, apoi șters, dar copiile circulă deja.
• 21 octombrie: lansarea, programată inițial pentru 22 octombrie, este adusă cu o zi mai devreme. Apar versiunile reparate. Cloudflare raportează primele atacuri. Finlanda, Țările de Jos și Franța își scot temporar de pe internet unele site-uri guvernamentale, ca măsură de precauție.
• 21–22 octombrie: administratorii de servere din toată lumea actualizează în grabă. Mulți opresc complet serverele până termină.
• 23 octombrie: PHP anunță o a treia vulnerabilitate (CVE-2026-115560), care afectează doar configurații neobișnuite și pentru care există o măsură temporară de protecție până la următoarea actualizare.

De ce au ales unii să oprească complet serverele

Poate ai văzut postări ale unor administratori care au oprit toate site-urile, ale lor și ale clienților, timp de câteva ore. Poate părea exagerat. Nu este.

Echipa PHP a spus clar că nu există o soluție provizorie completă: singura protecție reală este actualizarea. Agențiile de securitate din SUA au recomandat ca serverele care nu pot fi actualizate imediat să fie scoase de pe internet. CERT-EU, echipa de securitate a instituțiilor europene, a recomandat izolarea aplicațiilor expuse până la actualizare și verificare.

Pus în balanță: câteva ore în care un site nu răspunde, față de riscul ca cineva să preia controlul serverului, să fure date ale clienților sau să instaleze programe malițioase. Este mai bine să se plângă cineva câteva ore că nu-i merge site-ul decât să plângem toți după.

Cine este cel mai expus

• Site-urile care nu au fost actualizate. Versiunile reparate sunt PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Orice versiune mai veche din aceste serii este vulnerabilă.
• Site-urile pe versiuni vechi de PHP (8.1 sau mai vechi). Pentru 7.4–8.1 există doar corecturi pentru cei care își compilează singuri PHP. Pentru versiunile 5.4–7.3 nu există nicio reparație oficială. Analize de securitate estimează sute de mii de servere expuse pe internet care rulează astfel de versiuni.
• Serverele care rulează PHP ca modul Apache (mod_php), configurația pe care chiar echipa PHP a considerat-o cea mai riscantă.
• Site-urile „uitate”: o pagină de campanie din 2019, un magazin vechi, un subdomeniu de test. Ce nu mai e întreținut nu primește nici actualizări.

Ce trebuie să faci tu, chiar dacă nu ești tehnic

Nu trebuie să știi ce e PHP ca să îți protejezi afacerea. Trebuie doar să pui întrebările potrivite celui care îți administrează site-ul (agenție, freelancer, firmă de hosting):

1. „Site-ul meu rulează pe PHP? Dacă da, pe ce versiune?”
2. „Ați actualizat la o versiune reparată (8.2.35, 8.3.36, 8.4.27 sau 8.5.12 ori mai nouă)? Când?”
3. „Am și alte site-uri, subdomenii sau aplicații vechi care rulează PHP?” Fă o listă cu tot ce ai online.
4. „Ați verificat dacă au existat încercări de atac începând cu 17 octombrie?” Specialiștii recomandă verificarea jurnalelor de la această dată.
5. „Dacă un site rulează pe o versiune fără suport, care e planul de migrare?”

Dacă primești răspunsuri vagi sau nu primești niciun răspuns, acesta este, în sine, un semnal de alarmă.

Lecția mai mare: digitalizarea fără securitate

PHP2Shell nu este doar o poveste despre o eroare de programare. Este o poveste despre cum funcționează infrastructura internetului.

O tehnologie folosită de aproximativ 70% din web, inclusiv de servicii publice, bănci și magazine, este întreținută de un grup mic de dezvoltatori plătiți de Fundația PHP și de câțiva voluntari. Chiar Fundația a cerut public companiilor, firmelor de hosting și guvernelor care depind de PHP să contribuie la finanțarea muncii de securitate.

În paralel, punem tot mai multe date, servicii publice și infrastructură critică în sisteme conectate la internet, adesea în ritmul „digitalizării pe repede înainte”, fără să investim cu aceeași viteză în oamenii și în securitatea care trebuie să le protejeze. Iar AI-ul tocmai a scurtat dramatic timpul necesar pentru a transforma o problemă veche, „prea greu de exploatat”, într-un atac practic.

Concluzia nu este să ne fie frică de tehnologie. Concluzia este că întreținerea, actualizările și oamenii care se ocupă de ele nu sunt un cost opțional. Sunt motivul pentru care, în săptămâna aceasta, cei mai mulți dintre noi n-am observat absolut nimic.

Surse

• Wiz Research – PHP2Shell: AI uncovers critical RCE vulnerabilities
• CERT-EU – Critical Vulnerabilities in PHP (Advisory 2026-018)
• Tenable – PHP2Shell FAQ
• The Next Web – PHP knew about one of the flaws in 2024
• BleepingComputer – PHP ships emergency patches for critical PHP2Shell flaws
• Rapid7 – CVE-2026-109618 and CVE-2026-109619
• Decrypt – Who found the PHP bug