Vulnerabilitati critice in WordPress: ce trebuie sa verifici imediat

Ce s-a intamplat si cine este afectat

Cloudflare a anuntat reguli WAF noi pentru doua vulnerabilitati severe din WordPress: una de tip SQL injection si una de tip remote code execution fara autentificare. Conform informatiilor publicate, problema SQL afecteaza versiunile de la 6.8 in sus, iar problema de executie de cod afecteaza versiunile de la 6.9 in sus, in anumite conditii. WordPress a lansat corectii in 7.0.2, respectiv backporturi in 6.9.5 si 6.8.6. Daca site-ul tau ruleaza prin Cloudflare, WAF-ul poate reduce expunerea pana aplici update-ul, dar nu repara codul vulnerabil.

Pentru clientii MioriticHost care administreaza site-uri in cPanel, Plesk sau WordPress Manager, mesajul practic este simplu: nu te baza doar pe WAF. Verifica imediat versiunea de WordPress, confirma daca actualizarea automata a rulat si pregateste o verificare rapida dupa patch.

Checklist scurt pentru administratori

• Verifica in panoul WordPress daca site-ul ruleaza 7.0.2, 6.9.5 sau 6.8.6, in functie de ramura folosita.
• Confirma data ultimei actualizari si vezi daca update-ul automat de nucleu a fost aplicat cu succes.
• Fa imediat un backup de fisiere si baza de date inainte de orice interventie manuala.
• Daca folosesti Cloudflare, verifica daca traficul este proxied si daca regulile WAF nu au fost schimbate din Block in Log prin override.
• Testeaza dupa update autentificarea in wp-admin, formularul de contact, cautarea, checkout-ul si endpoint-urile REST folosite de pluginuri.
• Verifica logurile web si error log pentru cereri neobisnuite catre REST API, mai ales daca observi crestere de trafic sau erori 403 si 500.

Ce recomandam operational pe hosting

Daca site-ul nu s-a actualizat automat, intra in WordPress Admin si aplica update-ul manual intr-o fereastra cu trafic redus. Inainte, salveaza un backup complet si noteaza versiunea curenta de PHP, pluginurile de cache si eventualele reguli custom din .htaccess sau Nginx. O recomandare practica este sa golesti cache-ul de aplicatie si cache-ul de la nivel CDN dupa update, altfel poti testa pagini vechi si poti rata erori reale.

A doua recomandare concreta este sa verifici daca folosesti cache persistent de obiecte si cum este configurat. Vulnerabilitatea critica descrisa public mentioneaza explicit absenta unui astfel de cache in anumite scenarii, deci merita sa stii clar daca ai Redis sau Memcached activ, cine il administreaza si daca pluginul de integrare functioneaza corect. In plus, verifica uptime-ul dupa actualizare, trimite un email de test din formularele site-ului si confirma ca backupul programat din hosting ruleaza normal in noaptea urmatoare.