Pe scurt: O actualizare WordPress nu ajută împotriva vulnerabilității PHP2Shell, deoarece eroarea nu se află în WordPress, ci în PHP, software-ul de pe server care execută WordPress. Potrivit Dr. Web, WordPress.org nu planifică de aceea nici o actualizare proprie. Poate proteja doar o actualizare PHP pe server, cu repornirea tuturor proceselor PHP. Aceasta o instalează, de regulă, furnizorul dumneavoastră de hosting sau operatorul serverului.
Punctul de plecare: „Dar am actualizat totul”
După primele titluri despre PHP2Shell, mulți operatori au făcut ce era la îndemână: au deschis dashboardul WordPress, au dat clic pe „Actualizează acum”, au actualizat și pluginurile și temele. După aceea totul este verde, iar senzația spune: gata.
La această vulnerabilitate, senzația înșală. Nu din cauza WordPress, ci din cauza locului unde se află eroarea. Și Cloudflare atrage atenția în anunțul său că o actualizare a codului aplicației sau a pluginurilor nu remediază vulnerabilitățile.
Actualizarea WordPress și vulnerabilitatea PHP: modelul pe straturi
Un site WordPress constă din mai multe straturi care se sprijină unul pe altul. Fiecare strat are actualizări proprii și adesea responsabili proprii:
| Strat | Exemplu | Cine actualizează de obicei | Afectat de PHP2Shell? |
|---|---|---|---|
| Sistem de operare | Debian, Ubuntu, AlmaLinux | furnizorul de hosting sau administratorul serverului | nu, dar livrează adesea pachetul PHP |
| Server web | Apache, Nginx, LiteSpeed | furnizorul de hosting sau administratorul serverului | modul de operare influențează riscul |
| Mediu de execuție PHP | PHP-FPM, mod_php | furnizorul de hosting sau administratorul serverului | da, aici se află vulnerabilitatea |
| Nucleul WordPress | WordPress | operatorul sau agenția | nu |
| Pluginuri și teme | WooCommerce, page builder | operatorul sau agenția | nu |
Butonul de actualizare din dashboard atinge doar ultimele două rânduri. Mediul de execuție PHP se află dedesubt și este invizibil pentru WordPress. Cum se bazează alte sisteme pe PHP descrie articolul CMS-uri și magazine pe PHP.
De ce nu poate WordPress să închidă vulnerabilitatea
Am putea crede că WordPress poate „programa în jur”. La PHP2Shell, acest lucru nu funcționează din două motive.
Mai întâi, ambele erori se află în felul în care PHP prelucrează cererile și apoi face curat. Aceasta se întâmplă independent de programul care rulează în PHP. În al doilea rând, echipa PHP a demonstrat pentru Apache cu mod_php un exploit care acționează înainte ca vreun cod al aplicației să fie executat. WordPress, pluginurile sale și orice plugin de securitate nici nu ajung atunci la rând.
Din același motiv, nu ajută nici un „plugin de securizare” care modifică setări prin ini_set(). php.net descurajează explicit setarea măsurilor provizorii pe această cale.
Și la WordPress gestionat?
La ofertele de WordPress gestionat, furnizorul se ocupă adesea nu doar de actualizările WordPress, ci și de serverul de dedesubt. Pentru PHP2Shell este un avantaj, dar nu un automatism. Întrebați concret dacă actualizarea PHP a fost instalată și dacă toate procesele PHP au fost repornite. Afirmația „Vă menținem WordPress-ul la zi” nu răspunde la această întrebare.
Multe site-uri, o singură instalare PHP
Agențiile și companiile cu mai multe site-uri ar trebui să cunoască o particularitate: pe un server, multe instalări WordPress împart adesea aceeași versiune PHP. Dacă aceasta nu este actualizată, toate sunt afectate, indiferent cât de bine este întreținut fiecare site în parte. Invers, o actualizare PHP le protejează pe toate odată, dacă după aceea toate procesele PHP aferente sunt repornite. Cine operează în paralel mai multe versiuni PHP trebuie să le actualizeze pe fiecare în parte.
Un dashboard WordPress verde nu spune nimic despre PHP2Shell. Decisiv este nivelul de patch al PHP pe server și repornirea tuturor proceselor PHP.
Citirea corectă a versiunii PHP în WordPress
WordPress afișează versiunea PHP: în dashboard, la Instrumente, Starea site-ului, în zona Raport, la secțiunea Server. Este un bun prim indiciu, dar nu o dovadă.
Dacă acolo apare o ramură precum 8.1 sau mai veche, este un semnal clar de avertizare, deoarece pentru ea nu mai există actualizări oficiale. Dacă acolo apare 8.2.35, 8.3.36, 8.4.27 sau 8.5.12, este instalată versiunea corectată. Dacă apare un număr mai vechi al unei ramuri suportate, poate fi totuși instalat un backport. Distribuțiile și furnizorii de hosting nu schimbă adesea numărul. Claritate aduce doar confirmarea furnizorului de hosting sau o privire în changelog-ul pachetului. Cum se face aceasta se află la Verificarea versiunii PHP și a nivelului de patch.
Ce ar trebui să facă în schimb operatorii WordPress
- Întrebați furnizorul de hosting sau operatorul serverului: Este PHP actualizat, când, și au fost repornite toate procesele PHP? Răspuns în scris.
- Verificați ramura PHP: Dacă site-ul rulează pe 8.1 sau mai veche, planificați trecerea la o ramură suportată. Ce versiune suportă versiunea dumneavoastră WordPress se află în cerințele de sistem de pe wordpress.org. Schimbarea în meniul clientului o descrie Schimbarea versiunii PHP în zona clientului de hosting.
- Căutați urme: fișiere PHP noi în
wp-content/uploads, conturi de administrator necunoscute, intrări străine înmu-plugins. Ascunzătorile tipice le descrie pagina WordPress și PHP2Shell. - Mențineți totuși WordPress la zi: Nucleul, pluginurile și temele închid alte vulnerabilități. Rămâne o obligație, doar că una diferită.
- Clarificați responsabilitatea: Dacă o agenție administrează site-ul, consemnați dacă este responsabilă și pentru PHP sau doar pentru WordPress.
Tocmai ultimul punct creează adesea goluri. Agenția întreține WordPress, furnizorul de hosting serverul, iar fiecare crede că celălalt are PHP2Shell în vedere.
Cum ajută PHP SOS concret?
- Clarificarea straturilor: Stabilim cine este responsabil pentru ce strat la site-ul dumneavoastră WordPress.
- Actualizarea PHP: Pe servere proprii sau administrate, instalăm actualizarea PHP și repornim toate procesele.
- Verificarea WordPress: Căutăm urme ale unui atac în fișiere, baza de date și conturi.
- Dovadă: Primiți nivelul de patch în scris, inclusiv pentru a-l transmite agenției sau clienților.
Desfășurarea o descrie serviciul de patch PHP.
Concluzie
Actualizarea WordPress este o bună întreținere, dar pentru PHP2Shell este stratul greșit. Vulnerabilitatea se află un etaj mai jos, în PHP pe server. Cine înțelege acest lucru pune întrebarea corectă la locul potrivit: Este PHP actualizat, repornit și dovedit?
Întrebări frecvente
Aduce WordPress o actualizare de securitate împotriva PHP2Shell?
Potrivit Dr. Web, WordPress.org nu planifică nicio actualizare împotriva PHP2Shell, deoarece vulnerabilitatea se află în interpretorul PHP de pe server. Remediul îl aduce doar o actualizare PHP efectuată de furnizorul de hosting sau de operatorul serverului.
Unde văd în WordPress versiunea PHP?
În dashboard, la Instrumente, Starea site-ului, în zona Raport, la secțiunea Server. Numărul afișat nu spune însă sigur dacă patchul este instalat, deoarece furnizorii de hosting încorporează adesea corecții ca backport, fără un număr de versiune nou.
Protejează un plugin de securitate împotriva PHP2Shell?
Doar foarte limitat. Un plugin rulează el însuși în PHP și devine activ abia după ce WordPress este încărcat. La Apache cu mod_php, potrivit echipei PHP, a fost demonstrat un exploit înainte ca vreun cod al aplicației să ruleze. Acolo un plugin nu poate interveni.
Ar trebui totuși să actualizez WordPress?
Da. Versiunile actuale de WordPress, teme și pluginuri închid alte vulnerabilități și fac parte dintr-o bună întreținere. Ele doar nu rezolvă problema PHP2Shell.