Publicat pe 6 noiembrie 2026 · Echipa mitza.es

Pe 28 octombrie 2026, WordPress a publicat versiunea 7.1.4, o actualizare de securitate care corectează o slăbiciune chiar în procesul de actualizare a nucleului. Șase zile mai târziu, pe 3 noiembrie, agenția americană CISA a adăugat vulnerabilitatea, identificată ca CVE-2026-119977, în catalogul său de vulnerabilități exploatate activ (KEV). Adică: nu mai este un risc teoretic. Rezumăm ce este confirmat la data de 6 noiembrie 2026 și ce încă nu este.
Ce s-a întâmplat, pas cu pas
- 28 octombrie: WordPress.org publică 7.1.4 ca versiune de securitate. Anunțul descrie „o slăbiciune în procesul de actualizare WordPress care poate duce la execuție de cod la distanță în timpul ferestrei de actualizare” și o atribuie lui Umut Bayram, cercetătorul care a raportat-o.
- 3 noiembrie: CISA include CVE-2026-119977 în catalogul KEV, „pe baza dovezilor de exploatare activă”. Termenul pe care îl stabilește pentru agențiile federale din SUA este 6 noiembrie.
- Înainte de alertă: potrivit analizei SOC Prime, care preia telemetria de honeypot-uri publicată de The Hacker News, au existat tentative de exploatare încă de pe 30 octombrie. Sunt tentative înregistrate, nu atacuri reușite confirmate.
O precizare: anunțul WordPress.org nu citează numărul CVE. Legătura dintre acel aviz și CVE-2026-119977 se stabilește prin descrierea vulnerabilității și prin cercetătorul care a raportat-o; CISA trimite la versiunea 7.1.4 în propria sa fișă.
Ce este exact această vulnerabilitate
CISA o clasifică drept o condiție de cursă de tip time-of-check time-of-use (TOCTOU, CWE-367) și explică faptul că ar putea permite atacatorilor neautentificați să execute cod pe server în timpul „ferestrei de actualizare”. Cauza pe care o citează este tehnică, dar ușor de înțeles cu o analogie:
Când WordPress își actualizează nucleul cu un pachet complet, descarcă fișierele noi și le pregătește într-o zonă intermediară înainte de a le înlocui pe cele vechi. Potrivit CISA, aceste căi de pregătire erau previzibile și accesibile de pe web. Este ca și cum, în timp ce schimbi yala de la ușa de acasă, ai lăsa cutia cu cheile noi pe preș câteva minute: pericolul nu există tot restul anului, dar în acele minute oricine trece pe acolo poate profita.
Din ce s-a publicat, riscul se concentrează în acel interval, iar SOC Prime evaluează complexitatea atacului ca fiind ridicată (scor CVSS 3.1 de 8,1 conform analizei sale; nu am putut să-l confirmăm în baza de date NVD). Acesta nu este un motiv să aștepți: patch-ul este disponibil, iar WordPress recomandă actualizarea imediată.
Versiuni afectate
SOC Prime indică faptul că vulnerabilitatea afectează WordPress de la versiunea 4.7 până la 7.1.3, iar corecția a fost portată în ramurile vechi care încă primesc patch-uri de securitate. WordPress.org confirmă acest ultim aspect: corecțiile au fost portate „în toate ramurile eligibile pentru corecții de securitate (în prezent până la 4.7)”, dar avertizează că acele versiuni vechi sunt publicate pe măsură ce sunt gata. Dacă site-ul tău este pe o ramură veche, verifică în panoul de actualizări dacă versiunea ramurii tale este deja disponibilă sau, după ce faci o copie de siguranță și un test, treci la 7.1.4.
Ce faci astăzi: lista de verificare
- Verifică-ți versiunea. În panoul de administrare, intră la Panou de control → Actualizări. Dacă nu este 7.1.4 (sau corecția ramurii tale), actualizează.
- Fă o copie de siguranță înainte de actualizare, fără să amâni actualizarea din această cauză. Dacă nu ai un sistem bine pus la punct, aici explicăm regula 3-2-1 a copiilor de siguranță.
- Nu presupune că actualizarea automată s-a încheiat cu bine. WordPress.org indică faptul că, pe site-urile cu actualizări în fundal, procesul pornește singur. Verifică în panou că versiunea este cea corectă și că nu există un aviz de actualizare eșuată.
- Întreabă furnizorul de hosting. Unii furnizori de WordPress gestionat actualizează în locul tău. Cere-i să îți confirme în scris versiunea și data.
- Caută activitate neobișnuită dacă site-ul tău a făcut o actualizare a nucleului în ultimele săptămâni: utilizatori administratori pe care nu îi recunoști, fișiere noi sau modificate în rădăcină și în
wp-content, modificări înwp-config.phpsau în.htaccess. Potrivit SOC Prime, cererile observate vizau căi temporare ale instalatorului (precumsetup-config.php), așa că poți căuta aceste căi și în jurnalele de acces ale serverului tău. - Schimbă credențialele dacă ai îndoieli (administratori, baza de date, SFTP) și verifică pluginurile instalate: elimină-le pe cele pe care nu le folosești.
- Notează data și acțiunile întreprinse. Dacă au fost afectate date cu caracter personal, cronologia aceasta te va ajuta să evaluezi împreună cu consultantul tău dacă trebuie notificată AEPD (Agenția Spaniolă pentru Protecția Datelor).
Două nuanțe oneste: fișa CISA indică faptul că nu se știe dacă vulnerabilitatea este folosită în campanii de ransomware și că impune un triaj criminalistic conform directivei sale BOD 26-04, adresată agențiilor federale din SUA. Pentru un IMM, traducerea practică este: dacă site-ul tău și-a actualizat nucleul în ultimele săptămâni cu o versiune vulnerabilă, merită o verificare, nu doar un patch.
Dacă crezi că site-ul tău este deja compromis
Semne precum redirecționări ciudate, pagini pe care nu le-ai creat, utilizatori noi, avertizări de la Google sau un furnizor de hosting care îți suspendă contul sunt motive să acționezi organizat. Am pregătit un ghid pas cu pas: site-ul meu WordPress a fost hackuit: ce faci, semne, curățare și prevenire. Pentru o verificare profesionistă, auditul nostru de securitate web controlează versiunile, utilizatorii, fișierele și configurația serverului.
De ce se repetă asta și cum reduci riscul
Se adaugă altor alerte grave WordPress despre care am scris în această toamnă: vulnerabilitatea CVE-2026-87902 din 7.1.2, familia wp2shell și pluginurile exploatate în octombrie. WordPress susține o parte uriașă din internet, așa că este ținta cea mai profitabilă. Asta nu înseamnă că nu ar trebui folosit; înseamnă că nu poate fi lăsat fără mentenanță.
- Ține un calendar de actualizări pentru nucleu, pluginuri și temă, plus un termen maxim pentru patch-urile critice.
- Folosește un mediu de testare (staging) pentru a repeta actualizările importante înainte de a le aplica în producție.
- Pune un firewall pentru aplicații web (WAF): reduce tentativele, dar nu înlocuiește actualizarea, pentru că vulnerabilitatea este în chiar WordPress. Dacă vrei să înțelegi prima linie de apărare, citește ce este un firewall și de ce are nevoie un IMM.
- Activează verificarea în doi pași și parole unice pentru toți administratorii.
- Deleagă mentenanța dacă nu este treaba ta: găsești detaliat ce include în mentenanță website: ce include și cât costă.
Întrebări rapide
Mă afectează dacă WordPress-ul meu este pe WordPress.com?
Avizele pe care le-am consultat vorbesc despre instalări WordPress care își actualizează singure nucleul. Dacă site-ul tău este pe o platformă gestionată, întreabă-ți furnizorul dacă a aplicat deja corecția; nu am găsit o declarație specifică a WordPress.com în această privință.
Ajută dacă dezactivez pluginurile?
Nu pentru această vulnerabilitate: se află în nucleu, nu într-un plugin. Măsura eficientă este actualizarea la versiunea corectată.
Trebuie să-mi fac griji dacă am actualizat deja?
Dacă site-ul tău și-a actualizat nucleul înainte de 28 octombrie, acea actualizare a fost făcută de o versiune vulnerabilă; riscul concret depinde de dacă cineva a atacat exact atunci. Merită o verificare rapidă a utilizatorilor și a fișierelor. Dacă ai actualizat după, verifică doar că versiunea este cea corectă.
Cum te ajutăm la Mitza
Actualizăm și verificăm WordPress în cadrul serviciului nostru de mentenanță website, cu copii de siguranță, teste prealabile și anunț dacă ceva nu merge. Dacă preferi să începi prin a afla în ce stare se află site-ul tău, spune-ne cazul tău din pagina de contact.
Citește și: zero-day-ul Ivanti Connect Secure și mentenanța IT pentru IMM-uri.