Pe scurt: Găsiți cel mai repede o backdoor WordPress comparând nucleul și pluginurile, prin WP-CLI, cu sumele de control oficiale și verificând apoi țintit mu-plugins, încărcările, wp-config.php, conturile de admin și baza de date. Important după PHP2Shell: o actualizare WordPress nu închide vulnerabilitatea PHP și nu elimină nicio ușă din spate existentă.
De ce ar trebui operatorii WordPress să se uite acum mai atent
Cu PHP2Shell au devenit cunoscute în octombrie 2026 două vulnerabilități critice în PHP însuși, CVE-2026-109618 și CVE-2026-109619. Ele permit executarea de cod malițios fără autentificare, indiferent cât de bine este întreținută instalarea dumneavoastră WordPress. Patchurile există din 21.10.2026, dar, potrivit rapoartelor din presă, o primă tentativă de atac a fost observată deja la 17.10.
Cine a fost vulnerabil în acest interval ar trebui să caute urme. WordPress este aici o țintă tipică, deoarece multe instalări sunt construite asemănător, iar atacatorii cunosc ascunzătorile. Ce trebuie să facă operatorii în general în privința PHP2Shell găsiți pe pagina WordPress și PHP2Shell.
Efectuați verificările următoare, pe cât posibil, pe o copie sau după o salvare. Comenzile doar citesc și nu modifică nimic.
Cum observați în viața de zi cu zi o backdoor
O ușă din spate este concepută să rămână discretă. Totuși există semne care se observă și fără cunoștințe tehnice. Printre ele se numără redirecționările către site-uri străine care apar doar la vizitatorii veniți din căutarea Google sau doar pe dispozitive mobile. La fel de suspecte sunt paginile noi cu reclame pentru medicamente, jocuri de noroc sau copii ale unor produse de marcă, care apar în indexul de căutare, dar nu în backend-ul WordPress.
Alte indicii sunt avertismentele de la Google sau de la browser, plângerile clienților despre e-mailuri spam de pe domeniul dumneavoastră, un consum brusc crescut de timp de calcul la furnizorul de hosting sau administratori pe care nu îi cunoaște nimeni din echipă. Niciunul dintre aceste semne nu dovedește singur o backdoor. Dacă apar mai multe împreună, nu amânați verificările următoare.
Invers: dacă nu observați nimic din toate acestea, nu înseamnă că instalarea este curată. Tocmai ușile din spate create doar pentru un acces ulterior nu au adesea niciun efect vizibil din exterior.
Backdoor WordPress: verificarea nucleului și a pluginurilor
WP-CLI poate compara fișierele nucleului WordPress și ale pluginurilor din directorul oficial cu sumele de control publicate. Fiecare abatere este o sarcină concretă de verificare.
cd /var/www/meine-seite
# Fișierele nucleului, comparate cu sumele de control oficiale
wp core verify-checksums
# Pluginuri din directorul oficial
wp plugin verify-checksums --all
# Versiuni instalate și stare
wp plugin list
wp theme list
Pluginurile și temele comerciale nu pot fi verificate astfel. Pentru ele ajută doar comparația cu un pachet original descărcat proaspăt de la furnizor. Pluginurile necunoscute, pe care nu le-a instalat nimeni din echipă, sunt întotdeauna suspecte, chiar dacă par dezactivate.
Ascunzători tipice în sistemul de fișiere
Câteva locuri apar mereu la instalările WordPress compromise:
wp-content/mu-plugins/: se încarcă automat și nu apare în lista obișnuită de pluginuri.wp-content/uploads/: acolo își au locul imaginile și documentele, nu fișierele PHP.wp-config.php: linii suplimentareincludesaurequirela început sau la sfârșit..htaccessși.user.iniîn directorul web și în subdosare: redirecționări neașteptate sau fișiere preîncărcate automat.- Fișiere din directorul principal ale căror nume amintesc de fișierele de bază WordPress, dar nu le aparțin.
# Fișiere PHP în dosarul de încărcări
find wp-content/uploads -type f -name "*.php*"
# Conținutul pluginurilor must-use
ls -la wp-content/mu-plugins/
# Toate fișierele .htaccess și .user.ini, cu data modificării
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Fișiere PHP modificate recent
find . -type f -name "*.php" -newermt "2026-10-17" -ls
Tipare generale de căutare pentru cod ofuscat descrie ghidul Cum recunoașteți și eliminați un webshell.
Verificarea utilizatorilor, a bazei de date și a sarcinilor programate
Multe uși din spate nu se află deloc în sistemul de fișiere. Un cont suplimentar de administrator este adesea suficient atacatorilor pentru a reveni mai târziu.
# Toți administratorii, cu data înregistrării
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Sarcini programate în WordPress
wp cron event list
# Adresa site-ului (manipulările duc la redirecționări)
wp option get siteurl
wp option get home
# Articole cu scripturi încorporate
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
Verificați și opțiunile cu conținut neobișnuit de mare și widgeturile cu cod străin. Rezultatele nu înseamnă automat un atac, deoarece și codurile de urmărire sau hărțile încorporate folosesc scripturi. Decisiv este dacă cineva din echipă cunoaște conținutul.
După o descoperire, schimbați toate parolele și cheile de securitate din wp-config.php. Altfel, autentificările existente ale atacatorilor rămân valabile.
Închiderea ușilor din spate și prevenirea revenirii
Dacă ați găsit o backdoor, o reinstalare este de obicei mai sigură decât repararea fișierelor individuale. Această ordine s-a dovedit eficientă:
- Salvați urmele: depuneți logurile, fișierele suspecte și un export al bazei de date, cu dată.
- Aduceți PHP la o versiune corectată și reporniți toate procesele PHP.
- Instalați nucleul WordPress, pluginurile și temele proaspăt, din surse originale.
- Preluați încărcările și baza de date după verificare, ștergeți conturile străine, schimbați toate accesurile.
- Împiedicați execuția PHP în dosarul de încărcări, la nivel de server.
Pentru Nginx este suficient un bloc în configurația serverului:
location ~* ^/wp-content/uploads/.*\.php$ {
deny all;
}
Pe Apache obțineți același lucru cu o regulă în configurația serverului pentru dosarul de încărcări. Un .htaccess chiar în dosarul de încărcări este mai slab, deoarece un atacator cu drepturi de scriere îl poate modifica din nou.
După curățare, planificați câteva săptămâni de observare mai atentă. Administratorii noi, fișierele PHP noi și modificările din wp-config.php ar trebui să fie observate imediat în acest timp, de exemplu printr-o verificare regulată cu WP-CLI sau printr-o monitorizare a fișierelor pe server.
Cum setați apoi drepturile fișierelor astfel încât WordPress să poată scrie doar acolo unde este necesar arată ghidul Drepturile fișierelor pe serverul web.
Cum ajută PHP SOS concret?
- Salvăm starea instalării înainte de a modifica ceva.
- Verificăm nucleul, pluginurile, temele, baza de date, conturile și configurarea serverului pentru uși din spate.
- Reinstalăm WordPress din surse curate și preluăm doar conținut verificat.
- Securizăm serverul și instalarea și documentăm ce a fost găsit și remediat.
Procesul unei curățări îl descrie serviciul Eliminarea malware-ului și a webshell-urilor.
Întrebări frecvente
Închide o actualizare WordPress vulnerabilitatea PHP2Shell?
Nu. PHP2Shell se află în interpretorul PHP, nu în WordPress. O actualizare a WordPress, a temelor sau a pluginurilor nu schimbă nimic aici; decisive sunt versiunea PHP a serverului și repornirea tuturor proceselor PHP.
Găsește un plugin de securitate toate backdoor-urile?
Nu în mod fiabil. Un plugin rulează în interiorul instalării compromise și poate fi el însuși manipulat. Completați-l cu verificări din exterior, de exemplu sume de control WP-CLI și o comparație cu fișierele originale curate.
Ce sunt mu-plugins și de ce sunt suspecte?
Pluginurile must-use din dosarul wp-content/mu-plugins se încarcă automat și nu apar în lista obișnuită de pluginuri. Atacatorii folosesc des acest lucru, pentru că operatorii se uită rar în acest dosar.
Poate o backdoor să se afle și în baza de date?
Da. Codul malițios sau redirecționările sunt adesea depuse în opțiuni, articole sau widgeturi. În plus, atacatorii creează adesea conturi proprii de administrator, pe care le găsiți în tabela de utilizatori.