Toate articolele

Noutăți30 octombrie 20265 min de citit

WordPress: race condition cu RCE, primele tentative de atac

O race condition în actualizările nucleului WordPress permite RCE fără autentificare și este deja vizată de atacatori. Ce trebuie să faci acum.

O mătură care mătură o foaie plină de cifre binare

📌 Evoluții ulterioare: WordPress, CVE-2026-119977: CISA confirmă exploatarea activă (3 noiembrie 2026)

Pe 28 octombrie 2026, WordPress a publicat versiunea 7.1.4, care, printre alte corecții, închide o race condition în procesul de actualizare a nucleului, exploatabilă fără autentificare pentru a executa cod de la distanță. Potrivit Defiant, compania care dezvoltă Wordfence, primele tentative de exploatare au apărut la câteva ore după lansarea patch-urilor. Știrea este relatată de SecurityWeek, heise Security și The Hacker News; detaliile tehnice care urmează provin din articolul SecurityWeek, care citează analiza Defiant și este singurul text complet pe care l-am putut analiza.

Ce s-a întâmplat

În timpul unei actualizări, WordPress dezarhivează fișierele noii versiuni într-un director temporar de pregătire (staging) înainte de a le instala. Potrivit Defiant, calea acestui director este previzibilă și, pe multe servere, accesibilă de pe web. Timp de câteva secunde, până când WordPress șterge fișierele temporare, un atacator care cunoaște sau ghicește calea poate ajunge la fișierele abia dezarhivate, inclusiv la cele ale programului de instalare.

La data publicării surselor nu fusese încă atribuit un CVE. Defiant încadrează defectul la severitate ridicată, dar cu o complexitate de atac ridicată.

Detalii tehnice

  • Produs: nucleul WordPress, procesul de actualizare.
  • Versiune corectată: 7.1.4; potrivit SecurityWeek, corecția a fost portată și pe ramurile mai vechi, până la 4.7.
  • Tip: race condition cu execuție de cod de la distanță (RCE), fără să fie nevoie de un cont pe site.
  • Condiții, potrivit Defiant: o actualizare cu pachetul complet, care conține și fișierele programului de instalare; acces public prin web și execuție PHP în directorul de staging; o cale de staging previzibilă sau descoperită; și timp suficient pentru a finaliza atacul înainte ca WordPress să șteargă fișierele temporare.
  • Corecție: versiunea 7.1.4 face aleatoriu numele directorului de staging, adaugă un fișier index de protecție și împiedică promovarea nesigură a datelor de configurare din copia de staging.
  • MITRE ATT&CK: T1190 (Exploit Public-Facing Application).

Așadar, fereastra de exploatare se deschide doar în timp ce site-ul se actualizează cu un pachet complet. De aceea, potrivit Defiant, atacatorii interoghează continuu căile vulnerabile, în speranța de a nimeri exact acele câteva secunde. Cererile observate vizează setup-config.php, scriptul cu care WordPress creează configurația inițială, din copia de staging. Sursele disponibile nu descriu lanțul complet de la fișierul accesat până la execuția de cod.

În total, versiunea 7.1.4 corectează 22 de defecte de securitate, printre care mai multe XSS, probleme în Interactivity API, o divulgare de informații fără autentificare și o slăbiciune de autorizare. De asemenea, actualizează certificatele rădăcină incluse, după recenta revocare eMudhra.

Tentative de exploatare: ce spun sursele

Potrivit Defiant, prima cerere interceptată de noua regulă a firewall-ului Wordfence a sosit la nouă minute după activarea ei; în primele 21 de ore, telemetria a înregistrat peste 18.500 de cereri către căile setup-config.php din copia de staging. The Hacker News titrează în schimb aproape 63.000 de tentative în 24 de ore: textul articolului nu a fost disponibil și nu știm ce cereri au fost numărate, așa că cele două cifre nu sunt direct comparabile. Și heise Security relatează tentative de exploatare observate.

Wordfence nu a raportat compromiteri reușite.

Impactul pentru companiile europene și italiene

WordPress stă la baza multor site-uri de companie, portaluri de servicii și magazine online, adesea administrate de agenții sau furnizori de hosting. Complexitatea ridicată reduce șansele de reușită ale fiecărei tentative, dar scanarea este automată și continuă: fiecare actualizare completă rulată pe un server unde directorul de staging este accesibil de pe web devine o oportunitate. Un atac reușit duce la execuție de cod pe server, cu acces la pagini, la baza de date și la datele trimise prin formulare.

Pentru entitățile care intră sub incidența NIS2, compromiterea unui site expus este un eveniment de evaluat pentru notificarea către CSIRT-ul național (în Italia, CSIRT Italia din cadrul ACN); dacă baza de date conține date personale, trebuie luată în calcul și notificarea autorității de protecție a datelor în 72 de ore, prevăzută de GDPR. Unitățile sanitare și administrațiile publice care folosesc WordPress pentru programări sau formulare online ar trebui să înceapă cu aceste site-uri.

Ce trebuie să faci acum

  1. Inventar: fă o listă cu toate instalările WordPress ale companiei, inclusiv cele de test și cele administrate de agenții sau furnizori externi, și cere-le acestora o confirmare scrisă a actualizării.
  2. Actualizează la 7.1.4 sau la versiunea corectată a ramurii tale, dacă folosești o versiune mai veche. Verifică versiunea din panoul de administrare sau cu wp core version.
  3. Blochează accesul web la directorul de staging (bună practică generală, nu indicată de surse). În WordPress, actualizările folosesc de regulă wp-content/upgrade/: dacă refuzi din serverul web accesul HTTP și execuția PHP în acest director, elimini condiția accesului public, inclusiv în timpul actualizării. Sursele nu spun dacă actualizarea la 7.1.4, rulată dintr-o versiune vulnerabilă, deschide ea însăși fereastra: din prudență, aplică blocarea înainte de actualizare.
  4. Verifică WAF-ul: dacă în fața site-urilor ai un web application firewall, asigură-te că regulile pentru WordPress sunt la zi.
  5. Caută urme în logurile serverului web: cereri către setup-config.php în afara căii obișnuite, mai ales sub wp-content/upgrade/, și în special răspunsuri cu cod 200 în minutele unei actualizări.
  6. Verifică integritatea: wp core verify-checksums, modificări recente în wp-config.php, utilizatori administratori noi, fișiere PHP neașteptate în wp-content/. Dacă găsești urme, izolează site-ul, păstrează logurile, restaurează dintr-o copie curată, schimbă parolele, credențialele bazei de date și cheile secrete, apoi evaluează obligațiile de notificare.

Cum te ajută ARXDOME

ARX Expose arată ce servicii expune compania ta pe Internet și ce produse sunt recunoscute pe ele, inclusiv site-urile WordPress uitate. Cu ARX Scout Assessment, la cerere și cu autorizarea ta, o evaluare a vulnerabilităților neinvazivă semnalează software învechit și panouri de administrare expuse. ARX Sentry colectează loguri și evenimente de pe serverele monitorizate, utile pentru a căuta cererile către căile programului de instalare.

Ultima actualizare:

Ai întrebări?

Hai să vorbim despre nevoile companiei tale, fără obligații.

Contactează-ne

Articole similare