Vulnerabilitate în actualizarea WordPress, exploatată activ: aproape 63.000 de tentative în 24 de ore

Atacatorii nu au pierdut timpul. La doar două zile după lansarea WordPress 7.1.4, pe 28 octombrie 2026, tentativele de exploatare a vulnerabilității de severitate ridicată corectate de această versiune ajunseseră deja la zeci de mii pe zi. Problema permite executarea de cod de la distanță, fără autentificare, pe site-urile care rulează WordPress Core de la versiunea 4.7 până la 7.1.3 și are un scor CVSS de 8,1. La momentul publicării nu i-a fost atribuit un identificator CVE.

Ce s-a întâmplat

Slăbiciunea se află într-un loc banal: modul în care WordPress despachetează o actualizare completă a nucleului. Când un site instalează o versiune completă (nu o actualizare parțială), fișierele noi sunt extrase într-un director temporar de pregătire, sub wp-content/upgrade, înainte de a fi mutate la locul lor. Două detalii transformă acest pas de rutină într-o suprafață de atac:

• calea directorului temporar este previzibilă, iar pe multe configurații de găzduire este accesibilă din web și execută PHP;
• copia pregătită include și programul de instalare WordPress, inclusiv setup-config.php.

Un atacator neautentificat care solicită instalatorul exact în momentul potrivit îl poate folosi împotriva copiei pe jumătate instalate și poate ajunge la execuție de cod PHP pe server. Este o condiție de cursă (race condition): în laborator fereastra durează doar câteva secunde și se închide când WordPress termină actualizarea și șterge fișierele temporare.

Pentru ca atacul să reușească trebuie îndeplinite simultan toate condițiile de mai jos:

1. se aplică o actualizare completă care conține fișierele de instalare;
2. directorul temporar este accesibil public din web și PHP rulează din el;
3. atacatorul cunoaște sau ghicește calea directorului;
4. atacatorul finalizează secvența înainte de curățarea fișierelor.

De ce contează

O fereastră de câteva secunde pare imposibil de exploatat. Traficul spune altceva. Telemetria colectată de firewall-urile pentru WordPress a înregistrat aproape 63.000 de cereri blocate care vizau această vulnerabilitate într-un singur interval de 24 de ore. Două dintre cele mai mari surse au bombardat grupuri mici de site-uri timp de aproximativ paisprezece ore și jumătate fiecare, interogând repetat calea instalatorului în speranța de a prinde o actualizare în desfășurare. Altele au încercat numeroase variante de directoare temporare și de nume de versiune pentru a o găsi pe cea corectă.

Nu fiecare cerere a atins exact calea vulnerabilă, însă interogarea susținută și sondele adaptate structurii de fișiere arată că atacatorii au înțeles rapid condiția de cursă și și-au construit unelte pentru ea. Pentru că declanșatorul este chiar procesul de actualizare al site-ului, cele mai expuse sunt tocmai site-urile care fac ce trebuie: se actualizează. Site-urile de pe găzduire partajată, unde directorul de upgrade este adesea accesibil din web, sunt ținta cea mai naturală.

Ce este de făcut

• Actualizați acum la WordPress 7.1.4. Toate versiunile de la 4.7 până la 7.1.3 sunt afectate. Verificați versiunea pe fiecare site, nu doar pe cele de care vă amintiți.
• Verificați jurnalele serverului web pentru cereri către fișiere PHP de sub wp-content/upgrade, în special accesări repetate ale setup-config.php sau ale subdirectoarelor cu nume de versiune. Interogarea repetată a acestei căi dintr-o singură sursă este un semnal puternic.
• Căutați urme de persistență. Revizuiți conturile de administrator, plugin-urile instalate și cele de tip must-use și căutați fișiere PHP pe care nu le-ați pus acolo, mai ales în directoarele de uploads și de teme.
• Întăriți directorul temporar. Acolo unde găzduirea permite, blocați accesul web la wp-content/upgrade sau dezactivați execuția PHP în interiorul lui. Asta reduce și impactul unor viitoare variante ale aceleiași idei.
• Continuați să aplicați actualizările. Vulnerabilitatea este expusă doar cât timp rulează o actualizare, așa că soluția este să fiți pe o versiune în care pasul de pregătire este sigur, nu să opriți actualizările.

Astfel de vulnerabilități sunt ușor de ratat tocmai pentru că elementul vulnerabil nu este un plugin sau o temă, ci câteva secunde dintr-un proces de rutină. Un inventar exact al versiunii WordPress de pe fiecare site și o alertă în ziua în care o versiune rămâne în urmă sunt exact genul de problemă pentru care este construit serviciul nostru de scanare de vulnerabilități: semnalează versiunile de nucleu învechite din întreaga infrastructură, astfel încât o întârziere de două zile să nu devină una de două luni.