WordPress a fost exploatat în aceeași zi cu patch-ul oficial

Pe 22 septembrie 2026, la ora 11:49 UTC, primele cereri de exploatare au lovit site-uri WordPress, la doar câteva ore de la publicarea patch-ului. O vulnerabilitate WordPress, CVE-2026-87902, a trecut de la anunț la atac live în mai puțin de o zi. Pentru cine administrează un site WordPress, fereastra dintre patch și primul sondaj s-a redus la câteva ore. Iar modul în care s-a replicat atacul merită înțeles, pentru că scena se repetă la fiecare patch de securitate publicat.

Vulnerabilitatea WordPress devine armă în aceeași zi

Pe 22 septembrie 2026, WordPress a publicat versiunea 7.1.2. Advisory-ul oficial, GHSA-7hp8-65ch-5whp, descrie o vulnerabilitate WordPress critică, CVE-2026-87902, cu scor CVSS 9.2. Un atacator fără cont poate forța rezoluția template-ului de pagină să includă un fișier PHP local ales în afara directoarelor temei. Pe serverul potrivit, includerea ajunge până la execuție de cod la distanță. Versiunile afectate pornesc de la 4.7.0, iar fix-ul a fost backportat pe toate ramurile, până la 4.7.37.

Atacatorii au fost totuși mai rapizi decât fixul publicat. Conform companiei de securitate Patchstack, prima cerere a sosit la 11:49 UTC, în ziua publicării. Cine a construit-o lucra direct din diff-ul patch-ului. A doua zi, un template Nuclei era deja public și volumul a urcat de peste zece ori. Honeypot-urile Previdian au înregistrat 68 de tentative începând cu 23 septembrie, din patru țări. Un site cu o vulnerabilitate WordPress neactualizată a fost, în aceeași săptămână, ținta a sute de scanere distincte.

Cum se replică un atac de acest tip

Patchstack a documentat trei etape în traficul observat. În prima, atacatorul sondează fișiere inofensive din core, precum wp-links-opml.php, și citește răspunsul ca pe o confirmare de vulnerabilitate. În a doua, cererile trec prin pearcmd.php, un script standard PEAR prezent pe multe distribuții PHP. Răspunsul confirmă dacă setarea register_argc_argv e activă, adică dacă lanțul spre execuție de cod e deschis. În a treia, același mecanism scrie fișiere PHP cu conținut controlat de atacator în directoare temporare, ținte favorite precum /tmp și /var/tmp. Numele observate includ wp-pear-rce-flag.php și poc87902.php.

Din poziția de apărare, fiecare etapă a atacului lasă urme clare în logurile web serverului. Iar asta transformă un incident de vulnerabilitate WordPress într-un caz de detecție gestionabil. Un log de 30 de zile îți permite retrospectivă la orice fereastră expusă, inclusiv la fereastra de dinaintea patch-ului aplicat. Semnalele cu valoare maximă, listate de cercetători în write-up-ul complet, arată așa:

• Pagename cu traversare codată — secvențele %2e%2e sau %252e%252e apar în parametrul pagename, în query sau în body-ul POST. Un slug real nu conține niciodată traversare, deci orice potrivire merită investigată.
• Perechea page_id și pagename — cele două parametri vin împreună pe rădăcina site-ului sau pe /index.php. Combinația e aproape inexistentă în traficul normal, deci e un semnal curat.
• Mențiuni de pearcmd — orice cerere cu pearcmd sau cu secvențele +config-show ori +config-create indică trecerea la etapa de execuție de cod.
• Fișiere PHP în directoare temporare — un .php nou în /tmp sau /var/tmp înseamnă că etapa finală a reușit. Gazda se tratează ca compromisă, nu doar scanată.
• User-agent de scanner — cve-2026-87902-poc/1.0 și nuclei-cve-2026-87902/1.0 semnează traficul automatizat. Restul cererilor folosesc user-agent falsificat, deci lista nu te salvează singură.

Precondițiile care separă scanarea de compromitere

Exploatarea completă a vulnerabilității WordPress nu lovește orice instalare, iar advisory-ul cere două condiții precise. Întâi, tema activă sau părinte trebuie să aibă un director superior al cărui nume începe cu page-, ca page-templates. Lista oficială include temele implicite Twenty Twelve și Twenty Fourteen, dar și teme populare ca Neve, Hestia sau Sydney. Apoi, serverul trebuie să expună un fișier PHP local, lizibil de contul web server, precum pearcmd.php.

A doua condiție depinde de configurarea PHP: lanțul prin pearcmd funcționează doar când register_argc_argv e On. Configurația asta e prezentă în imaginea oficială Docker php și în setările implicite cPanel cu PHP anterior versiunii 8.5. Aprecierea lui Ryan Dewhurst, fondatorul Previdian: tentative în masă, dar relativ puține compromiteri reale. WordPress vine, însă, cu actualizări automate activate implicit. O vulnerabilitate WordPress fără update rămâne deschisă exact acolo unde patch-ul o închidea. Responsabilitatea cade, deci, integral pe cine administrează site-ul.

Rutina noastră: update-ul intră în produs în ziua publicării

Regula pe care o aplicăm la clienții noștri e fixă. Patch-ul de securitate se aplică în ziua publicării, nu în următorul ciclu de mentenanță. Ordinea contează la fel de mult ca viteza, pentru că un update aplicat pe live fără backup poate cădea mai rău decât vulnerabilitatea originală. Rutina care închide o vulnerabilitate WordPress are șase pași, pornind de la anunțurile oficiale, nu de la așteptarea unui plan lunar:

1. Monitorizarea anunțurilor — urmărim zilnic anunțurile de securitate WordPress, plus feed-urile de vulnerabilități exploatate. Vedem problema în dimineața publicării, nu în săptămâna următoare.
2. Backup complet înainte de orice — copie a bazei de date plus snapshot al fișierelor. Dacă pasul următor merge prost, revenim în câteva minute, nu în câteva ore.
3. Staging înaintea producției — update-ul intră întâi pe staging, cu test scurt de login, checkout și formulare.
4. Aplicare în produs în aceeași zi — din dashboard, la Actualizări. Dacă testul de staging trece, update-ul intră pe live în ziua publicării, fără așteptarea weekend-ului.
5. Verificare post-aplicare — versiunea WordPress se vede direct în dashboard. Dacă site-ul funcționează normal după update, treci imediat la pasul următor.
6. Căutarea semnelor de compromitere — logurile se scanează pentru traversare codată, perechea page_id plus pagename și mențiuni de pearcmd. Un fișier .php apărut în /tmp sau /var/tmp înseamnă compromitere confirmată.

Rutina nu e spectaculoasă, dar exact ea separă site-urile care trec nestingher de cele care descoperă shell-urile sau skimmer-urile de carduri după săptămâni. Când datele de card și încrederea clientului sunt în joc, un patch aplicat la timp bate orice analiză retroactivă. Rutina presupune, însă, o echipă cu acces la staging și la loguri. Mulți proprietari nu le au intern, iar atunci greșelile care urmează devin testul real, nu o teorie de bibliotecă.

Greșelile care te țin în grupa de risc

Aceleași capcane revin la fiecare incident de securitate. Nu țin de tehnic, ci de decizie, de aceea se repetă și la site-uri cu buget și cu echipă. Fiecare transformă o vulnerabilitate WordPress cu fix disponibil într-un incident cu costuri. Le-am întâlnit în audit-uri exact în forma de mai jos, ca variante ale aceluiași eșec de patching. Fiecare are, în același timp, un leac de o singură propoziție:

• Amânarea pe ciclul lunar — un hotfix activ exploatat nu așteaptă săptămâna de mentenanță. Îl aplici separat și imediat, în afara programului regulat.
• Update aplicat direct pe live, fără test — un patch fără trecere pe staging poate rupe formulare sau checkout. De aceea intră întâi pe staging, cu test scurt.
• Fără verificare post-aplicare — statusul fixului se confirmă cu instrumentele platformei. Altfel nu știi dacă patch-ul a intrat pe toate mediile.
• Fără rotație de credențiale — o cheie de criptare expusă invalidează fix-ul. O rotești la sursă, împreună cu toate token-urile asociate, exact cum cer anunțurile oficiale.

Răspunsul final e direct, fără ambalaj. O vulnerabilitate WordPress devine armă în câteva ore, iar pentru site-ul tău, rutina de update rămâne singura apărare durabilă. Verifică azi versiunea pe fiecare site. Aplică ce lipsește pe staging, apoi în produs, și rotește credențialele ori de câte ori anunțul cere. Dacă îți lipsește echipa, o cerere pe pagina de contact a Incognito Concept pornește exact procesul descris mai sus.