In breve: un aggiornamento di WordPress non aiuta contro la vulnerabilità PHP2Shell, perché l'errore non sta in WordPress, ma in PHP, il software sul server che esegue WordPress. Secondo Dr. Web, per questo WordPress.org non prevede nemmeno un proprio aggiornamento. Può proteggere solo un aggiornamento di PHP sul server con riavvio di tutti i processi PHP. Di norma lo installa il Suo hoster o gestore del server.
Il punto di partenza: «Ma abbiamo aggiornato tutto»
Dopo i primi titoli su PHP2Shell molti gestori hanno fatto l'ovvio: aprire la dashboard di WordPress, cliccare su «Aggiorna ora», plugin e temi compresi. Poi tutto è verde, e la sensazione dice: fatto.
Con questa vulnerabilità la sensazione inganna. Non dipende da WordPress, ma da dove sta l'errore. Anche Cloudflare, nella sua segnalazione, osserva che un aggiornamento del codice applicativo o dei plugin non elimina le vulnerabilità.
Aggiornamento WordPress e vulnerabilità PHP: il modello a livelli
Un sito WordPress è composto da più livelli, che si costruiscono l'uno sull'altro. Ogni livello ha propri aggiornamenti e spesso propri responsabili:
| Livello | Esempio | Chi aggiorna tipicamente | Interessato da PHP2Shell? |
|---|---|---|---|
| Sistema operativo | Debian, Ubuntu, AlmaLinux | hoster o amministratore del server | no, ma fornisce spesso il pacchetto PHP |
| Server web | Apache, Nginx, LiteSpeed | hoster o amministratore del server | la modalità di esecuzione influisce sul rischio |
| Runtime PHP | PHP-FPM, mod_php | hoster o amministratore del server | sì, qui sta la vulnerabilità |
| Core di WordPress | WordPress | gestore o agenzia | no |
| Plugin e temi | WooCommerce, page builder | gestore o agenzia | no |
Il pulsante di aggiornamento nella dashboard raggiunge solo le due righe inferiori. Il runtime PHP sta sotto ed è invisibile a WordPress. Come altri sistemi si basano su PHP lo descrive l'articolo CMS e shop su PHP.
Perché WordPress non può chiudere la vulnerabilità
Si potrebbe pensare che WordPress possa «programmare attorno». Con PHP2Shell non funziona, per due ragioni.
Primo, entrambi gli errori stanno nel modo in cui PHP elabora le richieste e poi riordina. Ciò avviene indipendentemente dal programma che gira in PHP. Secondo, il team PHP ha dimostrato per Apache con mod_php un exploit che agisce prima ancora che venga eseguito del codice applicativo. WordPress, i suoi plugin e qualsiasi plugin di sicurezza non entrano allora nemmeno in gioco.
Per lo stesso motivo non aiuta neanche un «plugin di hardening» che modifichi le impostazioni con ini_set(). php.net sconsiglia espressamente di applicare le misure transitorie in questo modo.
E con il WordPress gestito?
Nelle offerte di WordPress gestito il fornitore si occupa spesso non solo degli aggiornamenti di WordPress, ma anche del server sottostante. Per PHP2Shell è un vantaggio, ma non un automatismo. Chieda in concreto se l'aggiornamento di PHP è stato installato e tutti i processi PHP sono stati riavviati. L'affermazione «Teniamo aggiornato il Suo WordPress» non risponde a questa domanda.
Molti siti, un'unica installazione PHP
Agenzie e aziende con più siti web dovrebbero conoscere una particolarità: su un server molte installazioni WordPress condividono spesso la stessa versione di PHP. Se questa non è aggiornata, sono tutte interessate, a prescindere da quanto sia curato ogni singolo sito. Viceversa, un aggiornamento di PHP protegge tutte le installazioni in una volta, a condizione che poi vengano riavviati tutti i relativi processi PHP. Chi gestisce più versioni di PHP in parallelo deve aggiornarle una per una.
Una dashboard di WordPress tutta verde non dice nulla su PHP2Shell. Decisivi sono lo stato della patch di PHP sul server e il riavvio di tutti i processi PHP.
Leggere correttamente la versione di PHP in WordPress
WordPress mostra la versione di PHP: nella dashboard sotto Strumenti, Salute del sito, nella sezione Info alla voce Server. È un buon primo indizio, ma non una prova.
Se compare un ramo come 8.1 o precedente, è un chiaro segnale d'allarme, perché per questi non esistono più aggiornamenti ufficiali. Se compare 8.2.35, 8.3.36, 8.4.27 o 8.5.12, è installato lo stato corretto. Se compare un numero più vecchio di un ramo supportato, può comunque essere stato installato un backport. Distribuzioni e hoster spesso non modificano il numero. Fa chiarezza solo la conferma dell'hoster o uno sguardo al changelog del pacchetto. Come si fa è spiegato in Verificare versione e stato della patch di PHP.
Cosa dovrebbero fare invece i gestori WordPress
- Chiedere all'hoster o al gestore del server: PHP è aggiornato, quando, e sono stati riavviati tutti i processi PHP? Risposta per iscritto.
- Verificare il ramo PHP: se il sito gira su 8.1 o precedente, pianificare il passaggio a un ramo supportato. Quale versione supporti la Sua versione di WordPress è indicato nei requisiti di sistema su wordpress.org. Il cambio nel menu clienti è descritto in Cambiare la versione di PHP nell'area clienti dell'hosting.
- Cercare tracce: nuovi file PHP in
wp-content/uploads, account amministratore sconosciuti, voci estranee inmu-plugins. I nascondigli tipici sono descritti nella pagina WordPress e PHP2Shell. - Tenere comunque aggiornato WordPress: core, plugin e temi chiudono altre vulnerabilità. Resta un dovere, solo che è un altro.
- Chiarire la responsabilità: se un'agenzia cura il sito, stabilire se è responsabile anche di PHP o solo di WordPress.
Proprio l'ultimo punto crea spesso lacune. L'agenzia cura WordPress, l'hoster il server, e ciascuno crede che l'altro abbia PHP2Shell sotto controllo.
Come aiuta concretamente PHP SOS?
- Chiarire i livelli: accertiamo chi, per il Suo sito WordPress, è responsabile di quale livello.
- Aggiornare PHP: su server propri o gestiti installiamo l'aggiornamento di PHP e riavviamo tutti i processi.
- Verificare WordPress: cerchiamo tracce di un attacco in file, database e account.
- Prova: riceve lo stato della patch per iscritto, anche da inoltrare ad agenzia o clienti.
Lo svolgimento è descritto nel servizio patch PHP.
Conclusione
L'aggiornamento di WordPress è buona manutenzione, ma contro PHP2Shell è il livello sbagliato. La vulnerabilità sta un piano più sotto, in PHP sul server. Chi lo capisce pone la domanda giusta al posto giusto: PHP è aggiornato, riavviato e documentato?
Domande frequenti
WordPress rilascia un aggiornamento di sicurezza contro PHP2Shell?
Secondo Dr. Web, WordPress.org non prevede alcun aggiornamento contro PHP2Shell, perché la vulnerabilità si trova nell'interprete PHP sul server. Il rimedio è solo un aggiornamento di PHP da parte dell'hoster o del gestore del server.
Dove vedo in WordPress la versione di PHP?
Nella dashboard sotto Strumenti, Salute del sito, nella sezione Info alla voce Server. Il numero visualizzato non dice però con certezza se la patch è stata installata, perché gli hoster inseriscono spesso le correzioni come backport senza un nuovo numero di versione.
Un plugin di sicurezza protegge da PHP2Shell?
Solo in modo molto limitato. Un plugin gira esso stesso in PHP e diventa attivo solo quando WordPress è caricato. Con Apache e mod_php, secondo il team PHP, è stato dimostrato un exploit prima ancora che giri del codice applicativo. Lì un plugin non può intervenire.
Devo comunque aggiornare WordPress?
Sì. Le versioni attuali di WordPress, temi e plugin chiudono altre vulnerabilità e fanno parte di una buona manutenzione. Semplicemente non risolvono il problema PHP2Shell.