WordPress 7.1.4: lansare de securitate cu 22 de vulnerabilități rezolvate

Pe 28 octombrie 2026 a fost lansată versiunea WordPress 7.1.4. E o lansare de securitate, iar echipa WordPress recomandă actualizarea imediată a tuturor site-urilor.

Nu e o actualizare oarecare. Anunțul oficial grupează problemele în 12 puncte, iar analizele independente numără 22 de vulnerabilități distincte. Pentru comparație, versiunea anterioară, 7.1.3, rezolva șapte. Printre ele se află o problemă în procesul de actualizare a WordPress care, în anumite condiții, putea duce la executarea de cod la distanță, fără cont pe site.

Mai jos găsești, pe înțelesul tuturor, ce s-a reparat, cât de grave sunt problemele, ce site-uri sunt cele mai expuse și ce ai de făcut. Pentru cei care administrează servere, la final găsești și o măsură suplimentară recomandată.

Pe scurt

• Ce e: o lansare de securitate pentru WordPress 7.1.
• Când: 28 octombrie 2026.
• Ce rezolvă: 22 de vulnerabilități, majoritatea de tip XSS stocat, plus o problemă în procesul de actualizare și două de acces la informații.
• Cât de urgent: actualizează cât mai curând. Site-urile cu actualizări automate activate se vor actualiza singure.
• Versiunile mai vechi: corecțiile au fost aduse și pe ramurile mai vechi, până la 4.7. De exemplu: 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 și 4.7.39.
• Ce altceva conține: o actualizare a certificatelor rădăcină incluse în WordPress, după revocarea certificatelor unei autorități de certificare. E singura modificare care nu ține de securitate.

Problema cea mai gravă: procesul de actualizare

Cea mai serioasă vulnerabilitate nu se află într-un plugin sau într-o temă, ci chiar în mecanismul prin care WordPress se actualizează.

Cum funcționa, pe scurt. Când WordPress se actualizează, descarcă noua versiune și o dezarhivează temporar într-un folder de lucru, wp-content/upgrade/. Cercetătorul care a raportat problema a arătat că, în timpul acestei operațiuni, folderul temporar avea un nume previzibil și, în anumite momente, nu mai era protejat corespunzător. Un atacator care reușea să acceseze din browser instalatorul dezarhivat, exact în acele secunde, putea porni procesul de instalare cu o bază de date controlată de el. De acolo, putea ajunge la executarea de cod pe server.

Cât de ușor era de exploatat. Greu. Atacatorul trebuia să nimerească o fereastră de câteva secunde, exact în timpul unei actualizări, iar folderul wp-content/upgrade/ trebuia să fie accesibil din internet. Analiștii independenți au considerat exploatarea dificilă în practică. Dar nu era nevoie de niciun cont pe site, ceea ce face problema serioasă din principiu.

Ce s-a schimbat. Folderele temporare primesc acum nume aleatorii, protecția prin fișierul index.php e restabilită, iar fișierul de configurare wp-config.php nu mai este copiat în folderul de lucru.

Ironia situației e evidentă: problema apărea chiar în timpul actualizării. Dar exact de aceea e important să ajungi pe 7.1.4. După această versiune, actualizările viitoare se fac prin mecanismul corectat.

Celelalte probleme, pe categorii

XSS stocat: majoritatea vulnerabilităților

Cele mai multe probleme rezolvate sunt de tip XSS stocat (cross-site scripting). Pe înțelesul tuturor: un utilizator cu cont pe site salvează în conținut un cod ascuns. Codul nu face nimic până când un administrator sau un editor deschide pagina respectivă. În acel moment rulează în browserul lui, cu drepturile lui. Un astfel de cod poate, de exemplu, crea un cont nou de administrator fără ca victima să observe.

Locurile afectate:

• Interactivity API, componenta folosită de blocurile interactive moderne. Aici au fost găsite cele mai multe probleme, de către mai mulți cercetători independenți și de echipa de securitate WordPress. Una dintre ele putea bloca fila browserului vizitatorului.
• Blocuri create cu marcaj modificat intenționat, de exemplu cu spații neobișnuite în delimitatorii blocurilor.
• Blocul Categorii, prin eticheta lui.
• Blocurile de paginare a comentariilor și de navigare între articole, prin etichetele lor.
• Blocurile Imagine și Playlist, unde s-au făcut întăriri ale procesării.
• Customizer, prin funcția de reîmprospătare parțială a previzualizării.
• Cererile de ștergere a datelor personale, din instrumentele GDPR ale WordPress.
• Nume de utilizator construite intenționat.

Ultimele două au fost raportate de Anthropic, compania care dezvoltă asistentul AI Claude. E încă un semn că cercetarea de securitate asistată de AI a ajuns să contribuie concret la proiectele mari open-source.

Acces la informații

• Modificările nepublicate din Customizer puteau fi descoperite de vizitatori fără cont. Dacă lucrai la o modificare de design sau de conținut prin Customizer și n-o publicaseși încă, cineva putea s-o vadă înainte de vreme.
• Notițele atașate articolelor puteau fi citite de utilizatori cu anumite drepturi de moderare, chiar dacă nu aveau dreptul să editeze articolul respectiv. Situația apare mai ales pe site-urile cu roluri personalizate.

Ce site-uri sunt cele mai expuse

Aproape toate vulnerabilitățile, cu excepția a două, cer un cont pe site, cel puțin de nivel Contributor. Asta schimbă mult calculul de risc:

• Site-uri cu un singur administrator și fără alți utilizatori: riscul practic e mai redus, dar actualizarea rămâne obligatorie, mai ales pentru problema din procesul de actualizare, care nu cere cont.
• Bloguri și reviste cu mai mulți autori și colaboratori: risc crescut. Un cont de colaborator compromis sau un colaborator rău intenționat ar putea folosi aceste vulnerabilități pentru a ajunge la contul unui administrator.
• Site-uri cu înregistrare deschisă, unde utilizatorii noi primesc automat un rol care poate scrie conținut: risc ridicat. Verifică de urgență ce rol primesc utilizatorii noi.
• Site-uri cu roluri personalizate, create cu pluginuri de gestionare a rolurilor: verifică și problema notițelor.
• Agenții și firme care administrează multe site-uri: fiecare site cu conturi de clienți sau de colaboratori intră în categoria de mai sus.

Ce ai de făcut

1. Actualizează

Din panoul de administrare: Panou → Actualizări → Actualizează acum. Site-urile cu actualizările automate de securitate activate (setarea implicită în WordPress) se vor actualiza singure în următoarele ore. Verifică totuși, în colțul din dreapta jos al panoului sau la Panou → Actualizări, că versiunea instalată e într-adevăr 7.1.4.

Dacă site-ul rulează încă pe o ramură mai veche, de exemplu 6.9, versiunea corectată pentru ramura ta (6.9.11) ar trebui să se instaleze automat. Pe termen lung, recomandarea rămâne trecerea la ultima versiune, singura susținută activ. Site-urile pe WordPress 4.6 sau mai vechi nu primesc nicio corecție.

Înainte de orice actualizare, ca de fiecare dată: un backup recent, verificat. Lansările de securitate sunt, de regulă, foarte sigure, pentru că nu aduc funcții noi, dar backup-ul e plasa ta de siguranță pentru orice situație neprevăzută. Despre cum faci actualizările fără griji am scris în acest ghid.

2. Verifică utilizatorii

Pentru că majoritatea problemelor pornesc de la conturi de Contributor sau mai sus, acum e momentul potrivit pentru o curățenie:

• la Utilizatori, verifică cine are rol de Contributor, Autor, Editor sau Administrator;
• șterge sau retrogradează conturile care nu mai sunt folosite: foști colaboratori, conturi de test, agenții cu care nu mai lucrezi;
• la Setări → Generale, verifică rolul implicit al utilizatorilor noi. Pentru majoritatea site-urilor ar trebui să fie Abonat;
• activează autentificarea în doi pași pentru toate conturile care pot publica sau edita conținut.

3. Uită-te după conturi de administrator necunoscute

Nu există, la momentul scrierii, informații publice despre exploatarea acestor vulnerabilități în practică. Dar dacă pe site-ul tău au existat colaboratori necunoscuți sau înregistrare deschisă, o verificare rapidă nu strică. Caută conturi de administrator pe care nu le recunoști și modificări recente pe care nu le-ai făcut tu. Dacă găsești ceva suspect, citește articolul nostru despre semnele unui site spart.

4. Pentru administratorii de server: blochează accesul la wp-content/upgrade/

Folderul wp-content/upgrade/ e folosit de WordPress doar intern, în timpul actualizărilor. Nu are niciun motiv să fie accesibil din browser. Blocarea lui la nivel de server web închide definitiv singura problemă care nu cerea cont pe site. Între actualizări, folderul ar trebui să conțină doar un fișier index.php.

Un detaliu important: un firewall instalat ca plugin WordPress nu poate bloca această problemă. Instalatorul dezarhivat rulează din propriile fișiere și nu trece prin pluginurile site-ului. Blocarea trebuie făcută de serverul web.

Atenție: comenzile de mai jos modifică configurația serverului. Fă o copie a fișierului înainte și testează site-ul după.

Pe Apache sau LiteSpeed, în fișierul .htaccess din rădăcina site-ului, deasupra blocului WordPress:

# Blochează accesul web la folderul temporar de actualizare
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

Pe Nginx, în blocul server al site-ului, apoi reîncarci configurația:

# Blochează accesul web la folderul temporar de actualizare
location ^~ /wp-content/upgrade/ {
    deny all;
}

Blocarea nu afectează actualizările. WordPress lucrează cu acest folder direct pe disc, nu prin browser.

Verificare: deschide în browser https://site-ul-tau.ro/wp-content/upgrade/. Ar trebui să primești o eroare 403 (acces interzis), nu o listă de fișiere și nici pagina site-ului.

Ce urmează

Următoarea versiune majoră, WordPress 7.2, e programată pentru 8 decembrie 2026. Versiunea de test 7.2 Beta 3, lansată în aceeași zi, conține deja toate corecțiile din 7.1.4. Nu amâna însă actualizarea la 7.1.4 așteptând 7.2. Corecțiile de securitate se aplică acum, iar versiunea majoră poate aștepta testele obișnuite.

Întrebări frecvente

Site-ul meu se actualizează singur?

Dacă nu ai dezactivat actualizările automate, da. Actualizările de securitate pentru versiunile minore sunt activate implicit în WordPress. Verifică totuși versiunea instalată în următoarele zile.

Actualizarea îmi poate strica site-ul?

Riscul e redus, pentru că lansările de securitate nu aduc funcții noi. Unele corecții pot schimba însă modul în care se afișează conținut cu marcaj neobișnuit, mai ales la blocurile interactive. Dacă folosești blocuri personalizate sau un constructor de pagini complex, aruncă o privire peste paginile importante după actualizare.

Sunt pe WordPress 6.x. Trebuie să trec acum la 7.1?

Nu neapărat azi. Ramura ta primește versiunea corectată automat. Dar ramurile vechi primesc doar corecții de securitate, nu și îmbunătățiri, iar suportul complet se acordă doar ultimei versiuni. Planifică trecerea la 7.1, cu backup și test pe o copie a site-ului.

Am un singur cont de administrator. Sunt în siguranță?

Ești mult mai puțin expus la problemele care cer cont de Contributor. Problema din procesul de actualizare și cea din Customizer nu cer însă niciun cont. Actualizează oricum.

Cum știu dacă am fost atacat?

Verifică lista utilizatorilor, mai ales administratorii, ultimele modificări de conținut și fișierele modificate recent pe server. Dacă ai un plugin de securitate cu jurnal de activitate, uită-te acolo. La orice îndoială, cere o verificare specializată.

Concluzia, pe scurt

WordPress 7.1.4 e una dintre cele mai consistente lansări de securitate din ultima vreme: 22 de vulnerabilități rezolvate, inclusiv una în mecanismul de actualizare. Majoritatea cer un cont pe site, așa că cele mai expuse sunt site-urile cu mai mulți autori sau cu înregistrare deschisă.

Pașii sunt simpli: actualizează, verifică versiunea, fă curățenie în lista de utilizatori, activează 2FA. Iar dacă administrezi servere, blochează accesul web la wp-content/upgrade/.

Pentru site-urile din pachetele de mentenanță WebFixer, actualizarea și verificările de mai sus le facem noi. Dacă vrei să nu mai urmărești singur fiecare lansare de securitate, găsești detalii pe webfixer.ro.