WordPress CVE-2026-87902: versiune, temă și loguri
WordPress a publicat pe 22 septembrie 2026 versiunea 7.1.2 și actualizări pentru ramurile mai vechi, care corectează CVE-2026-87902. Vulnerabilitatea din rezolvarea șabloanelor de pagină permite unui atacator neautentificat să facă WordPress să includă un fișier .php local ales de el, din afara directoarelor temei. În anumite condiții, rezultatul este executare de cod de la distanță. Avizul proiectului o evaluează la CVSS 9,2. Actualizare 27 septembrie: CISA a adăugat CVE-2026-87902 în catalogul KEV pe 25 septembrie, cu termen 28 septembrie pentru agențiile federale americane.
Patchstack a observat încercări de exploatare chiar din ziua publicării, iar DNSC a emis pe 24 septembrie o alertă pentru WordPress Core. Pentru echipele care administrează mai multe site-uri, contează două lucruri: dacă fiecare instalare a ajuns efectiv la o versiune corectată și dacă tema și serverul îndeplinesc condițiile care transformă includerea de fișier în executare de cod.
Ce este confirmat
Avizul GHSA-7hp8-65ch-5whp al WordPress descrie o traversare de cale în funcția get_page_template(). Sunt afectate versiunile 4.7.0–7.1.1. Corecția este în 7.1.2, 7.0.6, 6.9.9 și 6.8.10, iar proiectul a portat-o pe toate ramurile până la 4.7 (de exemplu 4.7.37).
Executarea de cod nu rezultă automat din versiunea vulnerabilă. Avizul enumeră două precondiții: tema activă (părinte sau copil) are în rădăcină un director al cărui nume începe cu „page-”, de exemplu page-templates, și pe server există un fișier .php pe care contul serverului web îl poate citi și care poate fi abuzat. Exemplul folosit este pearcmd.php din PEAR, utilizabil când register_argc_argv este activ. Help Net Security mai notează că cererea trebuie să ajungă la o pagină publicată și accesibilă fără autentificare.
Avizul numește ca afectate temele Twenty Twelve și Twenty Fourteen, precum și teme terțe populare ca Neve, Hestia și Sydney. Tot acolo se precizează că imaginea oficială Docker pentru PHP și configurația implicită cPanel cu PHP anterior 8.5 îndeplinesc condiția de pe partea de server.
Ce s-a observat în exploatare și ce nu știm
Patchstack raportează primele cereri de exploatare pe 22 septembrie la 11:49 UTC și un volum de peste zece ori mai mare a doua zi, după apariția unor șabloane Nuclei publice. Firma descrie trei etape: verificarea includerii cu fișiere inofensive din nucleul WordPress, verificarea existenței pearcmd.php și apoi scrierea de fișiere PHP în /tmp sau /var/tmp. The Hacker News, citând și telemetria Previdian, confirmă independent că încercările au început în câteva ore.
Nu există, în sursele consultate, un număr al site-urilor compromise. Încercările înregistrate de honeypoturi arată scanare și exploatare activă, nu câte instalări îndeplineau precondițiile. Nu tratați vulnerabilitatea ca zero-day: informațiile publice nu arată exploatare înainte de corecție.
Verifică versiunea efectivă a fiecărei instalări
- ▸Inventariază toate instalările WordPress: site-uri de marketing, microsite-uri de campanie, staging, instanțe uitate pe subdomenii și site-uri administrate de agenții.
- ▸Citește versiunea de pe server, de exemplu cu wp core version sau din wp-includes/version.php. Actualizarea automată începe singură doar unde este permisă; configurațiile cu actualizări dezactivate, deployment-urile din Git sau imaginile de container reconstruite din surse vechi pot rămâne vulnerabile.
- ▸Pentru containere, verifică imaginea care rulează efectiv în producție, nu doar Dockerfile-ul. O actualizare făcută în container dispare la următorul redeploy dacă imaginea de bază nu a fost schimbată.
- ▸Dacă folosești o ramură veche, instalează versiunea corectată a acelei ramuri, dar planifică migrarea: WordPress precizează că doar cea mai recentă versiune este suportată activ.
Stabilește dacă precondițiile sunt îndeplinite
Pe durata remedierii, prioritizează site-urile unde ambele condiții sunt prezente. Verifică dacă tema activă sau tema părinte are un director page-* în rădăcină și dacă pearcmd.php există în căile uzuale ale PHP. Verifică valoarea register_argc_argv în configurația PHP folosită de serverul web, nu în cea din linia de comandă.
Patchstack indică două măsuri temporare dacă actualizarea întârzie: respingerea parametrilor pagename care conțin secvențe de traversare și dezactivarea register_argc_argv. Acestea reduc riscul lanțului observat, dar nu înlocuiesc actualizarea, pentru că includerea altor fișiere locale rămâne posibilă.
Caută urme în loguri și pe disc
O potrivire în logurile de acces arată o încercare; nu dovedește compromiterea. Un fișier PHP necunoscut pe disc, în schimb, justifică tratarea site-ului ca incident: păstrează artefactele, rotește credențialele bazei de date și ale administratorilor și verifică utilizatorii și pluginurile adăugate recent.
- ▸Cereri în care parametrul pagename conține %2e%2e sau %252e%252e, mai ales când apare împreună cu page_id pe rădăcina site-ului.
- ▸Șiruri precum pearcmd, +config-show sau +config-create în URL-uri ori în corpul cererilor POST.
- ▸Pagini obișnuite care au returnat conținut OPML sau RSS: Patchstack notează că acesta este un semn de includere reușită.
- ▸Fișiere .php noi sau neașteptate în /tmp și /var/tmp, precum și fișiere PHP recente în directoarele web.
Închide expunerea cu dovezi
Awarely Monitor urmărește CVE-ul, prioritatea și dovezile deciziei pentru fiecare activ. Verificarea versiunii, a configurației PHP și a logurilor se face pe servere și în platforma de hosting; un status „rezolvat” fără aceste verificări nu spune dacă site-ul a fost expus.
- ▸Pentru fiecare site: versiunea inițială, versiunea după actualizare și cum a fost verificată pe server.
- ▸Rezultatul verificării precondițiilor: tema activă, prezența pearcmd.php și valoarea register_argc_argv.
- ▸Perioada de loguri analizată, indiciile găsite și limitele analizei.
- ▸Un responsabil și un termen pentru orice excepție, cum ar fi un site care nu poate fi actualizat imediat.
Verifică fiecare site, nu doar portofoliul
Urmărește CVE-ul, responsabilul, versiunea verificată și dovezile analizei pentru fiecare instalare WordPress în Awarely Monitor. Actualizarea și analiza logurilor rămân pe servere și în platforma de hosting.