# Vulnerabilità PHP in WordPress (PHP2Shell): cosa devono fare i gestori

> PHP2Shell colpisce WordPress tramite PHP, non il core. Verifichi versione PHP, uploads, mu-plugins e amministratori e metta in sicurezza il Suo sito.

Fonte: https://phpsos.de/it/plattformen/wordpress/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**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?](https://phpsos.de/it/php2shell/was-ist-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](https://phpsos.de/it/php2shell/php-version-pruefen/). 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 in `wp_options` o negli articoli.

Primi controlli non invasivi con WP-CLI e strumenti di base:

```bash
# 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](https://phpsos.de/it/ratgeber/backdoor-wordpress-finden/).

> **Importante:**
> 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ì:

```php
define( 'DISALLOW_FILE_EDIT', true );
```

## Che cosa dovrebbe fare ora come gestore WordPress

1. Si faccia confermare per iscritto dall'hoster lo stato delle patch di PHP e il riavvio di tutti i processi PHP.
2. Faccia conservare i log del server a partire dal 20/10/2026.
3. Esegua o faccia eseguire i controlli descritti sopra.
4. Aggiorni WordPress, plugin e temi. È giusto, ma non sostituisce il passo 1.
5. 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, `.htaccess` e account utente alla ricerca di backdoor.
- In caso di riscontri, la nostra [rimozione del malware](https://phpsos.de/it/leistungen/malware-entfernung/) 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](https://phpsos.de/it/leistungen/php2shell-soforthilfe/).


## 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.

## Fonti

- [php.net: bollettini di sicurezza](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [WordPress.org](https://wordpress.org/)
- [BSI (Ufficio federale tedesco per la sicurezza informatica)](https://www.bsi.bund.de/)
