Breșa din actualizarea WordPress: ce faci înainte de update

Pe 3 noiembrie 2026, CISA (agenția americană de securitate cibernetică) a trecut breșa CVE-2026-119977 din WordPress pe lista vulnerabilităților exploatate activ. Altfel spus, atacatorii o folosesc deja, nu doar o pot folosi în teorie. Problema stă chiar în actualizarea WordPress: în cele câteva secunde în care site-ul își instalează versiunea nouă, un atacator care nimerește momentul poate rula cod pe server, fără cont și fără parolă.

„O slăbiciune în procesul de actualizare a WordPress, care poate duce la execuție de cod de la distanță în timpul ferestrei de actualizare.”
Echipa WordPress, anunțul versiunii 7.1.4, 28 octombrie 2026

Sunt afectate toate versiunile de la 4.7 la 7.1.3, adică orice site WordPress care nu a primit actualizarea din 28 octombrie. Wordfence, care a atribuit numărul CVE, i-a dat un scor de 8,1 din 10. Alerta vine la două săptămâni după PHP2Shell, breșa din PHP care a făcut guverne să-și oprească site-urile, iar în aceeași săptămână a mai apărut una, în kernelul Linux, cu scor de 9,8, care privește serverele pe care stau aceste site-uri.

Ce s-a întâmplat

28 octombrie. WordPress lansează versiunea 7.1.4, cu o duzină de reparații de securitate. Printre ele e și cea din procesul de actualizare, raportată de cercetătorul Umut Bayram. Reparațiile au fost duse și pe ramurile mai vechi, până la 4.7.
În primele ore. Wordfence și presa de specialitate raportează mii de încercări de atac pe calea vulnerabilă.
3 noiembrie. CISA adaugă vulnerabilitatea în catalogul KEV (Known Exploited Vulnerabilities, lista breșelor despre care se știe că sunt folosite în atacuri reale).

Tiparul se vede și în logurile serverelor din România. Pe un server de hosting cu câteva zeci de site-uri WordPress, o singură adresă IP a cerut pe 30 octombrie fișierele vizate de atac de 239 de ori, pe 64 de site-uri, în 16 ore diferite ale zilei. Nu căuta o breșă deja deschisă, ci aștepta să se deschidă una.

Ce este breșa din actualizarea WordPress

Când WordPress face o actualizare completă, descarcă pachetul cu versiunea nouă și îl despachetează temporar într-un folder de lucru de pe site, wp-content/upgrade. Numele folderului se poate ghici, iar fișierele din el se pot deschide din browser. În pachet se află și instalatorul WordPress, pagina pe care o folosești o singură dată, când pui site-ul pe picioare și îi spui la ce bază de date să se conecteze.

Situația seamănă cu o mutare: cât timp mobila nouă stă pe hol, ușa apartamentului rămâne deschisă. Hoțul nu are nevoie de cheie. Îi ajunge să știe adresa și să treacă exact în minutul acela. La WordPress, „minutul” durează câteva secunde, iar atacatorii trimit cereri automat, iar și iar, până nimeresc.

De aceea, versiunea pe care o ai contează altfel decât de obicei. Un site rămas pe o versiune veche nu e atacabil tot timpul, ci exact când se actualizează. Iar actualizarea de la 7.1.3 la 7.1.4 o face tot codul vechi, cel vulnerabil.

De ce contează eticheta „exploatat activ”

Scorul CVSS (nota de la 0 la 10 care arată cât de gravă e o vulnerabilitate) spune ce s-ar putea întâmpla. Catalogul KEV spune ce se întâmplă deja. O breșă cu 8,1 pe care atacatorii o folosesc azi e mai urgentă decât una cu 9,8 pentru care nu se cunosc încă atacuri reale.

Breșa din kernel, de mai jos, e exact în a doua categorie: are scorul mai mare, dar la data scrierii nu era în catalogul CISA. Asta nu înseamnă că poate aștepta, ci doar că WordPress-ul vine primul.

Breșa din kernelul Linux (CVE-2026-98432)

Kernelul e miezul sistemului de operare Linux, partea care lucrează direct cu hardware-ul și care se ocupă de conexiunile de rețea. Pe Linux rulează majoritatea serverelor web, inclusiv cele pe care stau site-urile WordPress.

Vulnerabilitatea CVE-2026-98432 e în codul care stabilește conexiunile TCP (felul în care două calculatoare își „dau mâna” înainte să schimbe date). Există din Linux 4.4, a fost raportată de Xinyang Ge, cercetător la Anthropic, și a primit scorul 9,8. Pe 27 octombrie, Anthropic a descris un exploit (un program care folosește breșa) scris de un model AI de cercetare. Exploitul rulează comenzi ca root, adică cu drepturi depline, pe servere Linux care au activat MPTCP, o variantă de TCP care folosește mai multe conexiuni în paralel. Codul lui nu a fost publicat.

Partea liniștitoare: pe multe distribuții de servere, MPTCP e oprit din fabrică. Partea mai puțin liniștitoare: defectul nu ține de MPTCP, ci de TCP-ul obișnuit, așa că toate serverele au nevoie de kernelul reparat. Și, spre deosebire de o actualizare de WordPress, un kernel nou intră în funcțiune abia după repornirea serverului.

Dacă nu ai un site

Pentru breșa din WordPress, telefonul și calculatorul tău nu au nimic de făcut: problema e pe servere. Dacă ai un site făcut de altcineva, trimite-i un mesaj scurt celui care îl administrează și întreabă-l două lucruri: dacă site-ul e pe versiunea 7.1.4 sau mai nouă și dacă serverul a fost repornit pe kernelul reparat.

Atenție la e-mailurile care te anunță „urgent” că site-ul trebuie actualizat și îți dau un link. Zilele în care o breșă ajunge în presă sunt și cele preferate de cei care trimit phishing (mesaje false care imită un anunț oficial ca să-ți ia datele). Actualizarea se face din panoul site-ului, nu dintr-un link primit pe e-mail.

Pe scurt

WordPress: CVE-2026-119977, versiunile 4.7–7.1.3, scor 8,1, exploatată activ (CISA, 3 noiembrie 2026).

Când e atacabil un site: în secundele în care face o actualizare completă a WordPress.

Ce rezolvă: WordPress 7.1.4 sau versiunea de securitate a ramurii tale, plus blocarea folderului wp-content/upgrade.

Ordinea corectă: întâi blochezi folderul, apoi actualizezi.

Kernel Linux: CVE-2026-98432, scor 9,8, reparat în kernelurile apărute la sfârșitul lui octombrie și începutul lui noiembrie. Cere repornirea serverului.

Ce ai de făcut dacă ai un site WordPress

Cum afli ce versiune ai

În panoul WordPress, mergi la Panou → Actualizări: pagina îți arată versiunea curentă și dacă există una nouă. Dacă ai acces la linia de comandă, rulează wp core version în folderul site-ului.

De ce întâi blochezi, apoi actualizezi

Actualizarea la 7.1.4 deschide ea însăși fereastra pe care o pândesc atacatorii, pentru că o face codul vechi. Dacă site-ul are actualizările automate pornite (setarea implicită pentru versiunile de securitate), probabil s-a actualizat deja singur. Dacă nu, blochează întâi accesul din browser la folderele de lucru. Actualizarea nu are nevoie de acest acces, pentru că WordPress scrie fișierele direct pe disc.

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

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/(upgrade|upgrade-temp-backup)/ - [F,L]
</IfModule>

Pe nginx, în blocul server al site-ului:

location ~* ^/wp-content/(upgrade|upgrade-temp-backup)/ {
    deny all;
}

Dacă administrezi tu serverul și ai multe site-uri, regula se pune o singură dată, pentru toate, în configurația globală Apache:

<DirectoryMatch "/wp-content/(upgrade|upgrade-temp-backup)(/|$)">
    Require all denied
</DirectoryMatch>

Verifică rezultatul: curl -I https://site-ul-tau.ro/wp-content/upgrade/index.php trebuie să răspundă cu 403. Abia după asta actualizează. Blocarea nu înlocuiește actualizarea: versiunea 7.1.4 repară și alte probleme de securitate, fără legătură cu folderul de lucru.

Ce faci în funcție de versiune

Versiunea ta	Situația	Ce faci
7.1.4 sau mai nouă	✅ reparat	Pune totuși blocarea și verifică dacă ai fost atacat la actualizarea anterioară.
Versiunea de securitate a ramurii tale, apărută după 28 octombrie	✅ reparat	La fel: blocare și verificare.
4.7–7.1.3	🔴 atacabil la următoarea actualizare	Întâi blocarea, apoi actualizarea.
Sub 4.7	⚠️ neafectat de breșa asta, dar fără reparații de securitate de ani de zile	Planifică mutarea pe o versiune actuală.

Atenție la salturile mari de versiune: un site rămas pe 6.x, cu o temă veche, poate să nu mai arate la fel pe 7.1. Fă un backup înainte și, dacă poți, încearcă actualizarea întâi pe o copie.

Cum verifici dacă ai fost atacat

Fereastra a existat la fiecare actualizare completă făcută înainte de 7.1.4. Dacă site-ul s-a actualizat în ultimele săptămâni, merită cinci minute de verificare:

Logurile de acces. Caută cereri către fișiere din wp-content/upgrade care au primit răspunsul 200: grep -E '"(GET|POST)[^"]*/wp-content/upgrade[^"]*" 200' access.log. Răspunsurile 404 și 403 sunt încercări eșuate.
Fișiere PHP rămase în folderele de lucru. find wp-content/upgrade wp-content/upgrade-temp-backup -name '*.php'. Un index.php de câteva zeci de octeți, cu textul Silence is golden, e normal. Orice altceva nu e.
Administratori noi. wp user list --role=administrator sau, în panou, Utilizatori → Toți utilizatorii, filtrat pe Administrator.
Fișierele nucleului. wp core verify-checksums compară fiecare fișier WordPress cu originalul.
PHP în folderul de imagini. În wp-content/uploads nu ar trebui să existe fișiere PHP: find wp-content/uploads -name '*.php' -newermt 2026-10-01. Excepție: unele pluginuri pun acolo un index.php gol, de protecție.

Dacă găsești ceva, tratează site-ul ca fiind compromis. Restaurează-l dintr-un backup făcut înainte de prima cerere suspectă, schimbă parolele (administratori, bază de date, FTP) și cheile de securitate din wp-config.php, apoi actualizează. Simpla ștergere a fișierului găsit nu ajunge, pentru că atacatorul a avut timp să lase și altele.

Ce ai de făcut pentru kernel

Kernelul care rulează acum îl vezi cu uname -r. Ce faci mai departe depinde de distribuție:

AlmaLinux și RHEL. sudo dnf upgrade, apoi repornire. Pe AlmaLinux, primele kerneluri reparate sunt 4.18.0-553.182.1.el8_10 (versiunea 8), 5.14.0-687.64.1.el9_8 (9) și 6.12.0-211.72.1.el10_2 (10).
Debian. Actualizările sunt publicate (DSA-6568-1 pentru Debian 13, DLA-4841-1 pentru Debian 12): sudo apt update && sudo apt full-upgrade, apoi repornire.
Ubuntu. La 2 noiembrie, kernelul reparat nu fusese încă publicat. Urmărește pagina CVE-ului pe ubuntu.com/security.
VPS pe container (OpenVZ, LXC). Kernelul e al furnizorului, nu al tău. Întreabă-l când repornește serverele fizice.

După repornire, uname -r trebuie să arate versiunea nouă. Pe AlmaLinux sau RHEL, needs-restarting -r îți spune dacă mai e nevoie de o repornire.

Măsura temporară pentru kernel

Dacă nu poți reporni serverul imediat, AlmaLinux și Red Hat au publicat o regulă de firewall care aruncă pachetele TCP IPv4 cu opțiuni IP, de care atacul are nevoie. Traficul obișnuit al unui site nu le folosește.

sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength > 5 counter drop
    }
}
EOF

Limitele, spuse de AlmaLinux:

Regula nu e o reparație, doar reduce riscul până la repornire.
Dispare la repornire, deci se pune din nou dacă repornirea nu e și cea pe kernelul nou.
Traficul dintre containere de pe același server o poate ocoli.
Aruncă și pachetele cu opțiuni IP pe care serverul le rutează mai departe și strică rețelele care folosesc etichete CIPSO.

Verifică și dacă MPTCP e oprit: sysctl net.mptcp.enabled trebuie să răspundă cu 0. După ce serverul rulează kernelul reparat, regula se scoate cu sudo nft delete table ip cve_2026_98432.

Nu uita de instalările pe care nu le mai vezi

Breșa din WordPress lovește orice instalare de pe server, nu doar site-ul principal: copia de test de pe un subdomeniu, „site-ul vechi” lăsat într-un folder old, un site de prezentare uitat de ani de zile. Pe acestea nu le actualizează nimeni, așa că rămân primele în urmă. Le găsești cu find /home -path '*/wp-includes/version.php', iar apoi fie le actualizezi, fie le ștergi. Regula globală din Apache le acoperă și pe ele.

Dacă ai un site WordPress, fă azi trei lucruri, în ordinea asta: pune blocarea pentru wp-content/upgrade, verifică dacă site-ul e pe 7.1.4 și caută în loguri cereri reușite către acel folder. Dacă administrezi și serverul, programează în săptămâna asta repornirea pe kernelul reparat, iar până atunci pune regula de firewall.

Breșa din actualizarea WordPress și cea din kernelul Linux: ce faci înainte de update

Ce s-a întâmplat

Ce este breșa din actualizarea WordPress

De ce contează eticheta „exploatat activ”

Breșa din kernelul Linux (CVE-2026-98432)

Dacă nu ai un site

Pe scurt

Ce ai de făcut dacă ai un site WordPress

Cum afli ce versiune ai

De ce întâi blochezi, apoi actualizezi

Ce faci în funcție de versiune

Cum verifici dacă ai fost atacat

Ce ai de făcut pentru kernel

Măsura temporară pentru kernel

Nu uita de instalările pe care nu le mai vezi

Surse

Breșa PHP2Shell: guverne și-au oprit site-urile. 70% din web e expus

Vulnerabilitatea MongoBleed și procedura de patching pentru MongoDB

Cybersecurity pentru IMM-uri: 3 Pași Simpli ca să Previ Incidente Costisitoare

Ce s-a întâmplat

Ce este breșa din actualizarea WordPress

De ce contează eticheta „exploatat activ”

Breșa din kernelul Linux (CVE-2026-98432)

Dacă nu ai un site

Pe scurt

Ce ai de făcut dacă ai un site WordPress

Cum afli ce versiune ai

De ce întâi blochezi, apoi actualizezi

Ce faci în funcție de versiune

Cum verifici dacă ai fost atacat

Ce ai de făcut pentru kernel

Măsura temporară pentru kernel

Nu uita de instalările pe care nu le mai vezi

Surse

Related Posts

Breșa PHP2Shell: guverne și-au oprit site-urile. 70% din web e expus

Vulnerabilitatea MongoBleed și procedura de patching pentru MongoDB

Cybersecurity pentru IMM-uri: 3 Pași Simpli ca să Previ Incidente Costisitoare