PHP a publicat pe 21 octombrie 2026 remedierea pentru CVE-2026-109618 și CVE-2026-109619 — împreună, php2shell. Combinate, permit executarea de comenzi pe server fără autentificare prealabilă.
Am adăugat pentru ele două verificări în ClickScan, platforma self-serve care rulează alături de munca pe care o facem manual. Ambele sunt gratuite până pe 31 decembrie 2026, iar instrucțiunile sunt în articolul de pe ClickScan.
Ce merită însă atenția unui CISO nu sunt verificările în sine. Este distincția pe care sunt construite, iar ea se aplică oricărei verificări automate pe care o vei accepta vreodată drept dovadă.
Pasiv și activ, și de ce diferența ține de guvernanță
PHP Runtime Check este pasivă. Stabilește dacă un server intră în intervalul afectat folosind doar ce face serverul deja public, așa că nu are nevoie de nicio autorizare și poate fi rulată pe orice adresă.
PHP Runtime Audit este activă. Merge mai departe și găsește servere afectate pe care verificarea pasivă nu le vede. Nu trimite payload-uri și nu scrie nimic, dar este îndreptată către o gazdă anume, nu citește ce este publicat pentru toată lumea — de aceea cere dovada că activul îți aparține.
Pe scurt: Check îți spune ce se vede din exterior. Audit îți spune ce ar putea fi văzut.
Granița aceea nu este o comoditate de produs. Este aceeași linie care separă recunoașterea de testare în orice angajament și determină ce poți autoriza și ce poate face legal un terț asupra unui activ care îți aparține.
Dacă achiziționezi servicii de scanare — de la noi sau de la oricine altcineva — aceasta este întrebarea de pus. Care dintre verificări citesc date publicate și care sunt îndreptate către gazdele mele? Un furnizor care nu poate trasa clar linia este un furnizor al cărui scop nu îl poți scrie într-un contract.
Categoria de rezultat pe care majoritatea uneltelor nu o au
Aici este partea care contează cel mai mult pentru dovezi.
Dacă rulezi PHP dintr-un pachet de distribuție — Debian, Ubuntu, RHEL — numărul versiunii poate părea vulnerabil deși corecția este deja aplicată, pentru că distribuțiile fac backport fără să schimbe numărul versiunii.
Așa că, în cazul acesta, nu declarăm o vulnerabilitate. Raportăm că nu putem stabili și trimitem la changelog-ul distribuției.
Este un rezultat care arată mai prost și care este mai bun. Gândește-te cât te costă alternativele:
- O unealtă care declară vulnerabil un pachet cu backport generează un fals pozitiv pe care echipa ta pierde o zi să îl infirme — și, mai rău, o învață că rezultatele acelei unelte pot fi ignorate.
- O unealtă care tratează tăcerea drept „conform" generează un fals negativ, adică exact eșecul pe care nu îl descoperă nimeni până mai târziu.
O a treia categorie — nu s-a putut determina — este ceea ce face un raport utilizabil ca dovadă, nu ca material de vânzare. Este aceeași regulă pe care o aplicăm atunci când un test de spoofing este refuzat din motivul greșit și pentru orice nu a fost efectiv atins de o scanare.
Pentru o evaluare NIS 2 sub articolul 21, transpus prin OUG nr. 155/2024, aceasta este diferența dintre un proces de gestionare a vulnerabilităților care produce înregistrări apărabile și unul care produce zgomot. Un evaluator care citește „nu s-a putut determina, vezi changelog-ul distribuției, verificat 24 octombrie" se uită la un proces funcțional. Un evaluator care citește o listă de constatări dintre care jumătate erau greșite se uită la o unealtă pe care a cumpărat-o cineva.
Un număr de versiune este un indiciu, nu o determinare
Episodul acesta este al doilea într-o săptămână care face aceeași observație, din altă direcție.
Node2Shell, vulnerabilitatea Brotli relatată peste tot drept una Node.js, înșală detecția bazată pe versiune în ambele sensuri: unele proiecte sunt deja corectate, deși raportează un număr vechi de versiune, iar altele raportează un număr care pare actual și nu sunt. php2shell o înșală în sens invers, acolo unde backport-urile de distribuție fac sigură o versiune care pare vulnerabilă.
Lecția pentru un program de gestionare a vulnerabilităților: construiește procesul astfel încât o potrivire de versiune să deschidă o întrebare, nu să o închidă, iar „nu s-a putut stabili" să fie un rezultat consemnabil, cu responsabil și termen, nu un gol pe care îl abandonează cineva în tăcere.
Unde se oprește o verificare
O verificare externă răspunde bine la o singură întrebare: se vede expunerea aceasta din exterior, acum? Lucrul acesta este realmente valoros, este ieftin și poate rula continuu — de aceea am construit platforma.
Nu răspunde la ce atinge un atacator odată ajuns înăuntru, dacă o singură credențială recuperată deschide patru sisteme sau dacă segmentarea de pe schemă există și în rețea. Și nu îți spune dacă secretele au plecat deja înainte să corectezi — pentru php2shell aceasta este o chestiune de rotire a credențialelor, nu una de scanare.
Întrebările acelea au nevoie de un om. Un test de penetrare intern răspunde direct la întrebarea despre ce se poate atinge, o evaluare a suprafeței externe de atac construiește inventarul pe care verificările îl monitorizează apoi, iar un audit de conformitate stabilește ce dovezi va accepta efectiv evaluatorul tău.
Jumătatea automată și jumătatea expertă nu sunt concurente. Scanarea îți spune ce s-a schimbat de săptămâna trecută. Testul îți spune ce înseamnă.
Cum rulezi verificările
Intri pe app.clickscan.ai cu adresa ta de e-mail — fără formular de înregistrare, cu un cod de unică folosință primit pe e-mail. Adaugi activul ca domeniu, URL sau adresă IP, treci dovada deținerii pentru verificările active și pornești scanarea. Gratuit până pe 31 decembrie 2026.
Surse: Anunțul de lansare PHP din 21 octombrie 2026 · Înregistrarea CVE-2026-109618 · Înregistrarea CVE-2026-109619
Situația pachetelor de distribuție pentru php2shell era corectă la momentul redactării și continuă să se schimbe; verifică față de avertizarea propriului furnizor, nu față de un număr de versiune.
Acest articol conține informații cu caracter general, nu consultanță juridică sau de reglementare.