CVE-2026-109618 nu e un cod pentru programatori. E o alarmă pentru oricine are un site în PHP

Ce s-a întâmplat pe 21 octombrie 2026

Pe 20 octombrie 2026, pe site-ul oficial php.net a apărut un anunț prealabil: a doua zi, la 14:00 UTC (17:00 ora României), urma o actualizare de securitate pentru două vulnerabilități critice, ambele cu scorul 9,2 din 10. Detaliile nu erau publice. Toți utilizatorii PHP erau rugați să se pregătească.

Secretul n-a ținut până la capăt. Detalii despre cele două breșe au ajuns pe internet înainte de oră, iar Amazon a raportat ulterior că unul dintre serverele sale-momeală înregistrase încă din 17 octombrie o încercare de exploatare, adică de folosire efectivă a breșei. Pe 21 octombrie, în jurul orei anunțate, PHP a publicat versiunile reparate.

Tot pe 21 octombrie, CISA, agenția americană de securitate cibernetică, a cerut actualizarea imediată, iar instituțiile europene de securitate cibernetică au publicat o declarație comună. Directoratul Național de Securitate Cibernetică (DNSC) a emis și el o alertă, actualizată după apariția corecțiilor, în care scrie, citat de Ziare.com, că „orice server PHP neactualizat și expus în Internet trebuie considerat la risc ridicat de compromitere”.

Cele două vulnerabilități au coduri oficiale: CVE-2026-109618 și CVE-2026-109619. Presa și firmele de securitate le spun pe scurt PHP2Shell. Dacă ai un site în WordPress, WooCommerce, Magento, Drupal sau Laravel, te privesc direct, pentru că toate rulează pe PHP. Partea incomodă: corecția nu se instalează singură, iar pe o găzduire partajată nici n-o instalezi tu. O instalează cine administrează serverul.

Ca să știi ce ai de făcut, îți trebuie trei lucruri: să afli ce versiune de PHP ai, să știi cine îți administrează serverul și să înțelegi ce îți spune, de fapt, un cod CVE. Începem cu ultimul, pentru că fără el alertele de securitate rămân de neînțeles.

Numărul de rechemare al lumii software — ce este un CVE

Un CVE este un identificator public și unic, de forma CVE-AN-NUMĂR, atribuit unei vulnerabilități de securitate cunoscute, ca oricine din lume să se refere la exact aceeași problemă.

Acronimul vine din engleză, de la Common Vulnerabilities and Exposures, adică „vulnerabilități și expuneri comune”. O vulnerabilitate e o greșeală într-un program, pe care cineva o poate folosi ca să facă ceva ce n-ar trebui: să citească date, să intre fără parolă, să preia controlul.

Cel mai ușor îl înțelegi prin comparație cu o rechemare auto. Când un producător descoperă un defect la frâne, campania de rechemare primește un număr. Producătorul, service-ul, asiguratorul și proprietarul vorbesc despre același număr, fără să descrie de fiecare dată defectul. Un CVE face același lucru pentru software: firma de găzduire, producătorul, scanerul de securitate și agenția națională de securitate cibernetică spun „CVE-2026-109618” și știu toți despre ce e vorba.

Programul CVE există din 1999. E operat de MITRE, o organizație americană non-profit, și finanțat de CISA. Codurile nu le dă însă o singură instituție. Pe 23 octombrie 2026, după statisticile cve.org, le dădeau 559 de organizații din 43 de țări, numite CNA (CVE Numbering Authorities, autorități de numerotare): producători de software, firme de securitate, echipe naționale de răspuns la incidente.

Un lucru pe care cve.org îl spune explicit: CVE nu este o bază de date, ci un sistem de nume. Detaliile tehnice, scorurile și corecțiile stau în altă parte: în avertismentele producătorului și în două baze publice, americana NVD (National Vulnerability Database) și europeana EUVD (European Vulnerability Database), a ENISA, agenția Uniunii Europene pentru securitate cibernetică. În EUVD, cele două coduri PHP2Shell apar ca EUVD-2026-107260 și EUVD-2026-107265.

Volumul spune și el ceva. În 2025 au fost publicate 48.244 de înregistrări CVE, în medie peste 130 pe zi. În primele șase luni din 2026 au fost 35.872, aproape 200 pe zi. Un patron nu are cum să citească 200 de alerte pe zi, și nici nu trebuie: are nevoie să afle repede de cele care îl privesc.

Ce spun literele și cifrele — cum se citește un cod CVE

Ia ca exemplu CVE-2026-109618, prima vulnerabilitate PHP2Shell. Are trei părți.

• CVE e prefixul fix. Spune doar că e un identificator din programul CVE.
• 2026 e anul din cod. Ține de momentul în care codul a fost rezervat sau făcut public, nu de data descoperirii. La PHP2Shell, cele două se întâmplă să cadă în același an: breșa a fost găsită în august 2026 și publicată în octombrie.
• 109618 e numărul de ordine, de cel puțin patru cifre. Nu e un clasament și nici numărul de vulnerabilități din an; e doar numărul rezervat pentru acest cod.

Lângă cod, o înregistrare CVE are o descriere, produsele afectate și linkuri spre avertismentele oficiale. Poate avea și o stare: RESERVED (rezervat, detaliile nu sunt încă publice), DISPUTED (contestat, cineva nu e de acord că e o vulnerabilitate) sau REJECTED (respins, de ignorat).

Și două lucruri pe care codul nu ți le spune: cât de gravă e problema și dacă te privește pe tine. Pentru primul există scorul CVSS. Pentru al doilea, trebuie să știi ce versiune rulezi.

Cât de grav e? — scorul CVSS, explicat pe PHP2Shell

CVSS înseamnă Common Vulnerability Scoring System, sistemul comun de notare a vulnerabilităților. E întreținut de FIRST, forumul internațional al echipelor de răspuns la incidente, și dă fiecărei vulnerabilități o notă de la 0 la 10. Notele PHP2Shell sunt date în versiunea 4.0 a sistemului.

Gândește-te la el ca la triajul de la urgențe: îți spune cât de grav e cazul, nu dacă tu ești pacientul. Notele se împart în cinci trepte.

Nota vine dintr-un șir de litere care descrie atacul. Pentru ambele vulnerabilități PHP2Shell, avertismentele oficiale PHP dau același șir: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Arată ca o parolă, dar se citește bucată cu bucată.

• AV:N: atacul vine prin rețea, adică de oriunde de pe internet.
• PR:N și UI:N: atacatorul nu are nevoie de cont și nici ca tu să dai clic pe ceva.
• VC:H, VI:H, VA:H: dacă reușește, impactul asupra serverului e mare: poate citi date, le poate modifica și poate opri serviciul.
• AC:H: atacul e greu. Specificația FIRST spune că reușita depinde de ocolirea unor tehnici de protecție aflate deja pe server.
• AT:P: atacul cere anumite condiții de configurare și de rulare, care nu există peste tot.

AC:H și AT:P arată că atacul nu e banal de reușit, dar nota rămâne în treapta critică. Iar „greu” nu înseamnă „imposibil”. Potrivit The Register, firma de securitate VulnCheck spunea pe 22 octombrie 2026 că a făcut peste noapte un exploit funcțional, adică un program care chiar profită de vulnerabilitate, pentru CVE-2026-109618.

Exploit-ul merge pe PHP 8.4.26, o versiune nereparată, cu setările recomandate pentru producție, și ocolește ASLR, o protecție standard care amestecă aleatoriu adresele din memorie. Nu e public, iar chiar VulnCheck avertizează că dificultatea tehnică nu trebuie confundată cu protecția.

Grav nu înseamnă atacat — EPSS și catalogul KEV

Scorul CVSS măsoară cât rău poate face o vulnerabilitate. Nu măsoară cât de probabil e să fie folosită. Pentru asta există alte două unelte, amândouă gratuite.

EPSS (Exploit Prediction Scoring System, sistemul de predicție a exploatării) e tot un proiect FIRST. Estimează probabilitatea ca o vulnerabilitate să fie exploatată în următoarele 30 de zile. Pe 22 octombrie 2026, CVE-2026-109618 avea 5,3%, iar CVE-2026-109619 avea 5,8%. Pare puțin, dar le plasa peste 92–93% dintre toate vulnerabilitățile notate de EPSS.

KEV (Known Exploited Vulnerabilities) e catalogul CISA al vulnerabilităților despre care agenția are dovezi că sunt exploatate în lumea reală. Pe 23 octombrie 2026 avea 1.754 de intrări, iar PHP2Shell nu era printre ele. În alerta din 21 octombrie, CISA scria că nu observase exploatare la momentul publicării.

Aici e o nuanță care contează: o încercare de atac nu e un atac reușit. Amazon a văzut o încercare pe 17 octombrie pe un honeypot, adică un server pus intenționat la vedere ca să atragă atacatori și să le studieze metodele. Firma watchTowr spune că a observat exploatarea ambelor vulnerabilități din 21 octombrie, tot în rețeaua sa de servere-momeală, fără să spună dacă au existat compromiteri. Iar Sansec scria pe 22 octombrie că exploit-urile publice nu funcționează pe o instalare PHP implicită și că exploatarea în masă pare mai puțin probabilă decât se credea în ziua lansării. Toate pot fi adevărate în același timp. Concluzia practică rămâne aceeași: actualizezi.

Două uși lăsate deschise în motor — ce este PHP2Shell, vulnerabilitatea critică din PHP

PHP2Shell este numele public a două vulnerabilități critice din motorul PHP, CVE-2026-109618 și CVE-2026-109619, care pot permite unui atacator fără cont să ruleze cod pe serverul unui site.

PHP e limbajul de programare care rulează pe server și construiește paginile înainte să ajungă în browserul vizitatorului. Pe el sunt construite WordPress, WooCommerce, Magento și Drupal. După W3Techs, pe 23 octombrie 2026 PHP era folosit de 69,3% dintre site-urile al căror limbaj de server poate fi identificat.

Un shell e linia de comandă a unui server, locul unde administratorul scrie instrucțiuni. În jargonul securității, „a obține un shell” înseamnă a putea da comenzi serverului ca și cum ai fi administratorul lui. Numele seamănă cu Log4Shell (2021) și React2Shell (2025), alte vulnerabilități cu „shell” în nume, care dădeau și ele acces la server. Iar în iulie 2026 am scris aici despre alerta wp2shell, o breșă din WordPress cu nume asemănător.

Concret, sunt două greșeli diferite în felul în care PHP își gestionează memoria.

• CVE-2026-109618, execuție de cod prin coruperea memoriei. Când PHP rămâne fără memorie în mijlocul unei cereri, o abandonează brusc. Unele date rămân pe jumătate pregătite și, la curățenia de la final, pot fi tratate ca valide. Un atacator care provoacă intenționat lipsa de memorie, de exemplu cu o cerere de încărcare de fișiere construită special, poate strecura acolo instrucțiunile lui. Seamănă cu un ospătar care, rămas fără tăvi în mijlocul comenzii, lasă bonul scris pe jumătate; la închidere, casa de marcat îl citește ca pe o comandă completă.
• CVE-2026-109619, execuție de cod prin stare rămasă în urmă. PHP păstrează câteva informații de la o cerere la alta. Uneori ele arată spre memorie deja eliberată, iar următoarea cerere procesată de același proces le poate folosi înainte să fie resetate. E ca o cameră de hotel predată următorului oaspete cu biletele celui dinainte încă pe noptieră.

Două detalii fac PHP2Shell mai serios decât media. Primul: nu ține de codul site-ului tău. Firma Wiz, una dintre cele care au descoperit vulnerabilitățile, scrie că până și o aplicație „Hello World”, cea mai simplă pagină posibilă, poate fi vulnerabilă pe o versiune afectată. Al doilea: pe serverele Apache cu modulul mod_php, echipa PHP a demonstrat un atac care pornește înainte să ruleze vreo linie din aplicație. De aceea consideră riscul cel mai mare acolo.

Sunt afectate, după avertismentul oficial, toate instalările PHP care servesc pagini web: PHP-FPM, Apache cu mod_php, php-cgi, FrankenPHP și LiteSpeed. Nu trebuie să știi pe care o ai; toate sunt afectate. Impactul confirmat e execuția de cod cu drepturile procesului web, adică acces la fișierele site-ului, de regulă inclusiv la cele în care stau parolele bazei de date. RCE (remote code execution, execuție de cod la distanță) înseamnă exact asta: atacatorul nu-ți ghicește parola, ci face serverul să-i ruleze comenzile.

Din august până pe 23 octombrie — cronologia PHP2Shell

Cronologia arată cum trăiește, de obicei, un CVE: descoperire, raportare discretă către producător, reparație sub embargo, adică o perioadă în care detaliile se țin secrete până există corecția, apoi publicare simultană. La PHP2Shell, secretul n-a ținut până la capăt: detaliile au scăpat pe 20 octombrie, cu o zi înainte de publicare.

Merită reținută o dată din tabel: 17 octombrie. Amazon recomandă ca investigațiile să pornească de atunci, nu de la data publicării. Dacă îți administrezi singur serverul, de acolo începi să te uiți în jurnale.

Te privește? — versiunile PHP afectate și cele reparate, inclusiv pe WordPress

Răspunsul scurt: te privește dacă site-ul tău rulează PHP, adică aproape sigur, dacă e făcut în WordPress sau pe o platformă asemănătoare (un CMS, sistem de administrare a conținutului). Răspunsul lung depinde de versiune.

Ramurile vechi sunt problema mare. Pentru PHP 8.1 și mai vechi, proiectul PHP nu mai publică versiuni. Pentru 7.4, 8.0 și 8.1, echipa de securitate a pus totuși la dispoziție corecții minime în codul-sursă, pentru cine își compilează singur PHP-ul, iar unele distribuții Linux și firme de suport extins livrează pachete reparate. Pentru 7.3 și mai jos, echipa PHP n-a publicat nimic, deși Wiz spune că vulnerabilitățile ajung până la PHP 5.4, din 2012.

Atenție și la 8.2: are versiune reparată, 8.2.35, dar suportul de securitate se încheie pe 31 decembrie 2026. Migrarea pe 8.3 sau mai nou merită planificată de pe acum.

Cifrele vin de la W3Techs, care poate număra doar site-urile la care versiunea se vede din afară, deci nu sunt un recensământ. Arată totuși o direcție clară: 48,3% dintre site-urile PHP măsurate rulează o ramură pentru care proiectul PHP n-a publicat o versiune reparată. Asta nu înseamnă automat că sunt vulnerabile, pentru că unele au primit corecții prin distribuție sau prin firma de găzduire. Înseamnă că nu poți ști fără să întrebi.

O capcană care derutează des e numărul versiunii. Pe Ubuntu 24.04, de exemplu, PHP-ul reparat nu apare ca 8.3.36, ci ca pachetul 8.3.6-0ubuntu0.24.04.13, indicat de Ubuntu pentru CVE-2026-109618: distribuția a mutat corecția în versiunea ei, fără să schimbe numărul principal. Pe Ubuntu 22.04, PHP 8.1 a primit pachetul reparat 8.1.2-1ubuntu2.28, deși proiectul PHP nu mai publică versiuni pentru 8.1. Deci un „8.3.6” pe server nu e neapărat o veste proastă, iar „8.3.36” nu e singurul număr bun.

Și încă ceva, pentru WordPress și WooCommerce: actualizarea temei sau a pluginurilor nu rezolvă PHP2Shell. Cloudflare o spune direct în analiza sa: problema e în PHP, deci trebuie actualizat PHP-ul care rulează aplicația.

Iar PHP nu stă doar în site-uri. Declarația comună din 21 octombrie a Comisiei Europene, ENISA, CERT-EU, Europol (EC3) și rețelei echipelor naționale de răspuns la incidente avertizează că multe produse comerciale și open-source folosesc PHP în spate și pot fi afectate chiar dacă nu par să-l folosească. Centrul național de securitate cibernetică al Olandei (NCSC-NL) ține o listă publică cu astfel de produse. Declarația recomandă actualizarea întâi a sistemelor expuse pe internet și, unde asta nu se poate imediat, izolarea aplicațiilor expuse de rețelele publice.

Două mesaje de la firme de găzduire — cum arată o găzduire administrată care e la curent

Partea bună a unui CVE e că oricine îl poate urmări. O firmă de găzduire serioasă face asta în locul tău: are oameni care citesc alertele, știe ce versiuni rulează pe servere și îți spune, înainte să întrebi, dacă ai ceva de făcut. După publicarea corecțiilor PHP2Shell am primit, în română, două mesaje de felul ăsta. Nu numim firmele; ne interesează tipul de mesaj.

Primul a apărut ca fereastră în panoul de client. Numea cele două coduri, CVE-2026-109618 și CVE-2026-109619, spunea că firma a actualizat toate serverele care au activă o opțiune de suport tehnic și administrare la versiunile PHP care includ remedierile, și se încheia cu fraza pe care orice client vrea s-o citească:

„Nu este necesară nicio acțiune din partea dumneavoastră.”

Mesajul e scurt și are tot ce trebuie: numește problema, spune ce s-a făcut și cine nu are nimic de făcut. Mai are un detaliu, ușor de ratat: actualizarea s-a făcut automat pentru serverele cu administrare. Cine are un server fără administrare, de obicei un VPS (server virtual privat) pe care îl gestionează singur, primește de la aceeași firmă doar infrastructura. Acolo, actualizarea PHP e treaba lui.

Al doilea a fost un anunț în portalul de client, datat miercuri, 21 octombrie 2026. Firma scria că e la curent cu vulnerabilitățile identificate la nivelul PHP și că „monitorizăm constant publicarea actualizărilor relevante”. Apoi descria două etape: măsurile de securitate necesare fuseseră implementate la nivelul serverului, iar patch-urile disponibile, aplicate; urmau patch-urile specifice fiecărei versiuni PHP folosite, pe măsură ce devin disponibile.

Al doilea mesaj e mai puțin spectaculos, dar onest: spune deschis că reparația are etape și că unele versiuni PHP urmau să primească patch-ul după 21 octombrie. Pe un server care oferă mai multe versiuni PHP, corecțiile pot sosi pe rând, unele direct de la PHP, altele de la distribuții sau de la producătorii panourilor de găzduire. Mesajul nu descrie măsurile de la nivelul serverului, așa că un client pe o versiune încă nereparată face bine să întrebe când îi vine rândul.

Din cele două se poate face o listă scurtă. La un CVE critic, un mesaj bun de la firma de găzduire:

• numește problema, ideal cu codurile CVE, nu doar „o problemă de securitate”;
• spune ce s-a făcut deja și când;
• spune ce urmează, dacă reparația are etape;
• spune clar cine are ceva de făcut și cine nu.

Asta e diferența practică dintre o găzduire administrată și una pe care o administrezi singur. Nu e vorba că o firmă bună n-are niciodată vulnerabilități; le are toată lumea, pentru că le are PHP-ul. E vorba că cineva e la curent cu ele în locul tău, iar tu afli dintr-un mesaj de trei rânduri, nu dintr-o alertă de presă. Dacă până pe 23 octombrie 2026 n-ai primit nimic de la firma ta, mesajul din secțiunea următoare îți ia un minut.

Ce faci azi, în ordinea asta — cum verifici versiunea PHP și ce ceri găzduirii

Primii trei pași și ultimul sunt pentru tine. Pașii 4–6 sunt pentru cine administrează serverul: tu, dacă ai un server propriu, sau firma de găzduire.

1. Află ce versiune de PHP rulează site-ul. În cPanel sau Plesk vezi de obicei doar ramura, de exemplu 8.3, nu și ultima cifră. Versiunea completă o vezi în WordPress, în pagina Sănătatea site-ului (Site Health), fila Info, secțiunea Server, sau o ceri firmei de găzduire.
2. Compar-o cu tabelul de mai sus. 8.5.12, 8.4.27, 8.3.36, 8.2.35 sau mai nou înseamnă versiune reparată. Un număr mai mic nu e automat o problemă, dacă firma de găzduire confirmă un pachet cu corecția inclusă.
3. Pe găzduire administrată sau partajată, citește mesajele firmei. Dacă n-ai primit nimic, cere confirmarea în scris, cu mesajul de mai jos.
4. Pe un server administrat de tine, actualizează pachetele PHP și repornește toate procesele PHP. DNSC recomandă explicit repornirea tuturor proceselor și verificarea versiunii efectiv folosite: un proces PHP nerepornit rulează în continuare codul vechi, din memorie.
5. Dacă nu se poate actualiza pe loc, se aplică măsurile temporare din avertismentul php.net și se pune un firewall de aplicații web (WAF, un filtru în fața site-ului). Măsurile temporare reduc riscul, nu îl elimină; lista exactă e în avertismentul oficial.
6. Se verifică jurnalele serverului, începând cu 17 octombrie. Semnele descrise de Wiz și Amazon: cereri neobișnuite de încărcare de fișiere urmate de erori de memorie sau de erori 500 repetate, cookie-uri de sesiune (PHPSESSID) neobișnuit de mari și cereri care conțin șirul PHP_SESSION_UPLOAD_PROGRESS. Dacă apar, se anunță imediat firma de găzduire sau administratorul, iar jurnalele se păstrează.
7. Verifică backup-ul. Nu e o măsură contra PHP2Shell. E planul pentru cazul în care ceva a trecut deja.

Ce e și ce nu e fiecare termen — glosar CVE, CVSS, EPSS, KEV, RCE

Termenii din alertele de securitate se amestecă ușor. Tabelul îi pune unul lângă altul, cu ce face fiecare și, mai ales, ce nu face.

Un exemplu de WAF care a contat: Cloudflare a activat reguli pentru PHP2Shell pe 21 octombrie, la 03:02 UTC, cu mai bine de 10 ore înainte de publicarea versiunilor reparate, inclusiv pentru clienții pe planul gratuit. Ajută, dar chiar Cloudflare scrie că trebuie actualizat PHP-ul și recomandă ca firewall-ul să rămână pornit în timpul actualizării.

AI-ul a găsit breșa. Ce înseamnă asta pentru tine — mai multe CVE-uri, mai des

PHP2Shell are și o latură nouă. Firma de securitate Calif a găsit prima dintre vulnerabilități în august 2026, într-un audit al codului-sursă PHP finanțat de OpenAI prin programul Patch the Planet, lucrând cu modelul GPT-5.6 Sol. Wiz a ajuns independent la aceleași probleme câteva săptămâni mai târziu, cu GPT-5.6 Sol, cu Gemini 4 Argon de la Google și cu propriile unelte. Cloudflare îi enumeră pe cei care au raportat: Calif, Wiz, OpenAI și Quarkslab.

Nu e o mașină care a găsit singură breșa. Oamenii de la Calif și Wiz au folosit AI-ul ca unealtă, iar Calif spune, citat de The Next Web, că niciun model nu scoate la iveală „toate erorile” cu instrucțiuni simple. Wiz scrie că modelele au redus mult efortul de a adapta exploit-urile la versiuni, configurații și aranjamente de memorie diferite.

Nu știm cât din creșterea numărului de CVE-uri vine din AI. Știm doar că volumul a crescut: aproape 200 pe zi în prima jumătate din 2026, față de circa 132 pe zi în 2025. Pentru un patron, concluzia e simplă: actualizările de securitate devin rutină, nu eveniment. Contează mai puțin să urmărești fiecare alertă și mai mult să ai pe cineva, în firmă sau la găzduire, care le urmărește pentru tine.

Trei praguri, în ordinea asta

Nu e o concluzie, e un triaj. Te oprești la primul prag pe care nu-l treci.

Primul prag: știi ce versiune de PHP rulează site-ul tău? Dacă nu, afl-o din WordPress sau de la firma de găzduire. Fără versiune, orice alertă e doar zgomot.

Al doilea prag: versiunea e reparată? 8.5.12, 8.4.27, 8.3.36, 8.2.35 sau mai nou, ori un pachet confirmat de furnizor. Dacă ești pe PHP 8.1 sau mai vechi, pragul ăsta e și o întrebare despre migrare: ramurile vechi nu mai primesc versiuni oficiale, la niciun CVE.

Al treilea prag: cine află primul la următorul CVE? Dacă răspunsul e „eu, din presă”, ai un risc care nu ține de PHP. Firma de găzduire, un administrator sau un furnizor ar trebui să afle înaintea ta și să-ți spună dacă ai ceva de făcut.

La găzduirea administrată Cittago, serverele sunt urmărite de oameni la curent cu alertele de felul ăsta, iar actualizările de securitate ale serverului nu cad în sarcina clientului. Dacă vrei ca asta să nu mai fie grija ta, despre asta e găzduirea administrată Cittago. Nu ai nevoie de noi dacă firma ta de găzduire ți-a confirmat deja, în scris, că serverul e actualizat: înseamnă că face exact ce trebuie.

Mai discutăm despre asta peste 3–6 luni 😉

Întrebări cu răspunsuri pe care le considerăm utile

Întrebările pe care și le pune firesc cineva care a văzut un cod CVE într-o alertă și vrea să știe dacă îl privește.

Ultima actualizare: 23 octombrie 2026. Avertismentele PHP (php.net și GitHub), alerta CISA, statisticile cve.org, catalogul KEV, scorurile EPSS, înregistrările EUVD, pagina Ubuntu și datele W3Techs au fost citite pe 22 și 23 octombrie 2026. Pagina DNSC cere o verificare anti-robot, așa că textul alertei l-am citit în preluarea Ziare.com din 22 octombrie 2026. Cele două mesaje ale firmelor de găzduire sunt primite de noi, în română; nu numim firmele. Ce s-a schimbat la actualizarea din 23 octombrie 2026: am adăugat declarația comună UE din 21 octombrie și lista NCSC-NL cu produsele care conțin PHP, linkuri spre sursele oficiale chiar în text și ora publicării corecțiilor, care diferă puțin între surse (13:30–14:00 UTC); am verificat din nou catalogul KEV, unde PHP2Shell tot nu apare. Situația exploatării se schimbă repede. Actualizăm pagina când apar informații noi.

Surse: PHP · Avertismentul de securitate (EN) · GitHub · GHSA-w8hw-w9fx-j79w (EN) · GitHub · GHSA-6wmf-4rv5-p3rp (EN) · PHP · Versiunile suportate (EN) · DNSC · Alerta PHP · Ziare.com · Alerta DNSC · CISA · Alerta din 21 octombrie (EN) · CISA · Catalogul KEV (EN) · ENISA · Declarația comună UE (EN) · NCSC-NL · Produse care conțin PHP (EN) · cve.org · Întrebări frecvente (EN) · cve.org · Statistici (EN) · FIRST · CVSS 4.0 (EN) · FIRST · EPSS (EN) · ENISA · EUVD-2026-107260 · Amazon · MadPot (EN) · watchTowr · PHP2Shell (EN) · Cloudflare · Reguli WAF (EN) · Sansec · PHP2Shell (EN) · Wiz · PHP2Shell (EN) · The Next Web · Calif și OpenAI (EN) · The Register · VulnCheck (EN) · Ubuntu · CVE-2026-109618 (EN) · W3Techs · PHP (EN) · W3Techs · PHP 8 (EN)