In breve: la vulnerabilità PHP di WordPress di cui si parla in questi giorni non si trova in WordPress, ma in PHP sul server sottostante. Un aggiornamento di WordPress quindi non chiude PHP2Shell. Contano lo stato delle patch di PHP, il riavvio di tutti i processi PHP e un controllo dei nascondigli tipici come wp-content/uploads e mu-plugins.
Perché un aggiornamento di WordPress non risolve PHP2Shell
WordPress è un'applicazione scritta in PHP. Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 si trovano un livello più in basso, nell'interprete PHP stesso. Secondo il team PHP consentono di eseguire codice dannoso da remoto senza autenticazione. Con Apache e mod_php è stato dimostrato un exploit prima ancora che giri il codice di WordPress.
Un sito con core aggiornato, plugin aggiornati e password robuste può quindi essere comunque attaccabile, se il PHP sottostante è vecchio. Viceversa, un PHP aggiornato non prova che prima non sia successo nulla. Le informazioni di contesto si trovano in Che cos'è PHP2Shell?.
| Livello | Chi aggiorna | Chiude PHP2Shell? |
|---|---|---|
| Core di WordPress | Lei o la Sua agenzia | No |
| Plugin e temi | Lei o la Sua agenzia | No |
| PHP sul server | Hoster o amministratore del server | Sì, insieme al riavvio di tutti i processi PHP |
Vulnerabilità PHP di WordPress: verificare la versione di PHP
Nella dashboard, sotto Strumenti > Salute del sito > Info, nella sezione «Server» trova la versione di PHP con cui il Suo sito gira davvero. È più attendibile di php -v sulla riga di comando, perché la riga di comando spesso usa un'installazione di PHP diversa da quella del web server.
Il solo numero visualizzato non basta comunque. Le versioni upstream corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Molti hoster però applicano le correzioni come backport; in quel caso resta un numero più vecchio, anche se la patch c'è. Come stabilire lo stato reale è spiegato in Verificare correttamente versione e stato delle patch di PHP. Quali versioni di PHP supporta la Sua versione di WordPress, lo verifica nei requisiti di sistema su wordpress.org.
Dove si nasconde volentieri il codice dannoso in WordPress
Dopo un attacco riuscito, gli autori di solito lasciano una backdoor per poter tornare anche dopo la patch. WordPress ha dei luoghi noti per questo:
- wp-content/uploads/: pensata per immagini e PDF, non per file PHP.
- wp-content/mu-plugins/: i plugin «must-use» si caricano automaticamente e non si possono disattivare dalla dashboard.
- wp-config.php: contiene i dati di accesso al database e le chiavi di sicurezza; una riga aggiunta qui passa quasi inosservata.
- .htaccess nella directory principale e nelle sottocartelle: reindirizzamenti solo per i motori di ricerca o l'esecuzione di estensioni di file insolite.
- Temi, soprattutto
functions.php, nonché plugin disattivati e dimenticati. - Database: nuovi amministratori in
wp_users, JavaScript estraneo inwp_optionso negli articoli.
Primi controlli non invasivi con WP-CLI e strumenti di base:
# Confrontare i file del core con i checksum ufficiali
wp core verify-checksums
# Verificare i plugin della directory su wordpress.org
wp plugin verify-checksums --all
# Elencare i file PHP nella cartella degli upload
find wp-content/uploads -type f -name "*.php"
# Mostrare tutti gli amministratori
wp user list --role=administrator
Un riscontro è un motivo per esaminare con attenzione, non ancora una prova. I plugin commerciali non si possono controllare in questo modo. Per approfondire c'è la guida Trovare le backdoor in WordPress.
Non elimini in fretta i file sospetti. Metta prima al sicuro file, database e log del server a partire dal 20/10/2026. Senza queste tracce non si potrà chiarire in seguito se siano usciti dei dati.
Plugin, temi e accessi admin come rischio aggiuntivo
PHP2Shell non ha bisogno di una vulnerabilità in un plugin. Nella pratica quotidiana, però, plugin e temi restano il punto d'ingresso più frequente nei siti WordPress. Ogni plugin porta con sé codice proprio, funzioni di upload proprie e cicli di aggiornamento propri. I plugin inutilizzati dovrebbe eliminarli anziché solo disattivarli, perché i file disattivati restano sul server.
Per wp-login.php e wp-admin vale: pochi amministratori, account personali anziché accessi condivisi e un'autenticazione a due fattori. Se non Le serve XML-RPC, può essere bloccato. In caso di sospetto andrebbero rinnovate tutte le password e le chiavi di sicurezza in wp-config.php. L'editor di file nella dashboard si disattiva sempre lì:
define( 'DISALLOW_FILE_EDIT', true );
Che cosa dovrebbe fare ora come gestore WordPress
- Si faccia confermare per iscritto dall'hoster lo stato delle patch di PHP e il riavvio di tutti i processi PHP.
- Faccia conservare i log del server a partire dal 20/10/2026.
- Esegua o faccia eseguire i controlli descritti sopra.
- Aggiorni WordPress, plugin e temi. È giusto, ma non sostituisce il passo 1.
- In caso di anomalie non continui semplicemente a gestire il sito, ma lo faccia bonificare.
Un aggiornamento della piattaforma può chiudere vulnerabilità note in WordPress e nei plugin. Non può riparare PHP né rimuovere file introdotti che non fanno parte del core.
In che modo PHP SOS aiuta concretamente?
- Chiariamo con Lei o con il Suo hoster lo stato effettivo di PHP del Suo sito WordPress, compresi backport e riavvio.
- Mettiamo al sicuro log, file e database prima che venga modificato qualcosa.
- Controlliamo core, plugin, uploads, mu-plugins,
.htaccesse account utente alla ricerca di backdoor. - In caso di riscontri, la nostra rimozione del malware si occupa della bonifica fino alla chiusura e alla documentazione dell'incidente; in assenza di riscontri rafforziamo l'installazione nell'ambito dell'assistenza immediata PHP2Shell.
Domande frequenti
Devo aggiornare WordPress a causa di PHP2Shell?
Un WordPress aggiornato è sempre opportuno, ma non chiude PHP2Shell. La vulnerabilità è nell'interprete PHP del server. Servono un aggiornamento di PHP o un backport confermato dal Suo hoster, e il riavvio di tutti i processi PHP.
Un plugin di sicurezza mi protegge da PHP2Shell?
Solo in misura molto limitata. Un plugin è a sua volta codice PHP che gira dentro WordPress. Con mod_php è stato dimostrato un exploit prima ancora che parta il codice dell'applicazione; un plugin potrebbe quindi non accorgersi affatto dell'attacco.
Perché WordPress mostra ancora una vecchia versione di PHP, anche se l'hoster ha applicato la patch?
Molti hoster e distribuzioni Linux inseriscono le correzioni come backport nella versione esistente. Il numero di versione resta allora lo stesso. Si faccia confermare lo stato delle patch dall'hoster per iscritto.
In wp-content/uploads può esserci un file PHP?
Di norma no. La cartella degli upload è pensata per i contenuti multimediali. Un file PHP lì dentro è un chiaro segnale d'allarme e va messo al sicuro e fatto esaminare da un tecnico prima di essere eliminato.