# Trovare backdoor in WordPress: individuarle in modo sistematico

> Trovare backdoor in WordPress: verificare core e plugin con WP-CLI, controllare account admin, mu-plugins, upload e database e chiudere le backdoor.

Fonte: https://phpsos.de/it/ratgeber/backdoor-wordpress-finden/  
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:** per trovare una backdoor in WordPress il modo più rapido è confrontare core e plugin con i checksum ufficiali tramite WP-CLI e poi controllare in modo mirato mu-plugins, upload, `wp-config.php`, account admin e database. Importante dopo PHP2Shell: un aggiornamento di WordPress non chiude la vulnerabilità PHP e non rimuove una backdoor esistente.

## Perché i gestori WordPress dovrebbero guardare con più attenzione adesso

Con PHP2Shell, a ottobre 2026 sono diventate note due vulnerabilità critiche in PHP stesso, CVE-2026-109618 e CVE-2026-109619. Consentono l'esecuzione di codice dannoso senza autenticazione, a prescindere da quanto sia curata la Sua installazione WordPress. Le patch esistono dal 21/10/2026, ma secondo i media un primo tentativo di attacco era già stato osservato il 17/10.

Chi in questo periodo era vulnerabile dovrebbe cercare tracce. WordPress è un bersaglio tipico, perché molte installazioni hanno una struttura simile e gli aggressori ne conoscono i nascondigli. Che cosa devono fare in generale i gestori riguardo a PHP2Shell è spiegato nella pagina [WordPress e PHP2Shell](https://phpsos.de/it/plattformen/wordpress/).

Esegua i controlli seguenti possibilmente su una copia o dopo un backup. I comandi sono in sola lettura e non modificano nulla.

## Come accorgersi di una backdoor nella pratica quotidiana

Una backdoor è progettata per restare discreta. Esistono tuttavia segnali che saltano all'occhio anche senza conoscenze tecniche. Tra questi i reindirizzamenti verso siti esterni che compaiono solo per i visitatori provenienti dalla ricerca Google o solo sui dispositivi mobili. Sono sospette anche le nuove pagine con pubblicità di farmaci, gioco d'azzardo o copie di prodotti di marca, che compaiono nell'indice di ricerca ma non nel backend di WordPress.

Altri indizi sono avvisi di Google o del browser, lamentele dei clienti per e-mail di spam dal Suo dominio, un consumo improvvisamente molto più alto di tempo di calcolo presso l'hoster o amministratori che nessuno nel team conosce. Nessuno di questi segnali dimostra da solo una backdoor. Se se ne presentano diversi insieme, non rinvii i controlli seguenti.

Vale anche il contrario: se non si nota nulla di tutto ciò, non significa che l'installazione sia pulita. Proprio le backdoor create solo per un accesso successivo spesso non mostrano all'esterno alcun effetto.

## Trovare backdoor in WordPress: controllare core e plugin

WP-CLI può confrontare i file del core di WordPress e dei plugin della directory ufficiale con i checksum pubblicati. Ogni differenza è un incarico di verifica concreto.

```bash
cd /var/www/meine-seite
# File del core rispetto ai checksum ufficiali
wp core verify-checksums
# Plugin della directory ufficiale
wp plugin verify-checksums --all
# Versioni installate e stato
wp plugin list
wp theme list
```

I plugin e i temi commerciali non si possono verificare in questo modo. Per loro serve solo il confronto con un pacchetto originale del fornitore appena scaricato. I plugin sconosciuti che nessuno nel team ha installato sono sempre sospetti, anche se risultano disattivati.

## Nascondigli tipici nel file system

Alcuni luoghi ricorrono continuamente nelle installazioni WordPress compromesse:

- `wp-content/mu-plugins/`: viene caricato automaticamente e non compare nell'elenco normale dei plugin.
- `wp-content/uploads/`: qui vanno immagini e documenti, non file PHP.
- `wp-config.php`: righe `include` o `require` aggiuntive all'inizio o alla fine.
- `.htaccess` e `.user.ini` nella directory web e nelle sottocartelle: reindirizzamenti inattesi o file caricati automaticamente in anticipo.
- File nella directory principale i cui nomi ricordano i file del core di WordPress, ma che non ne fanno parte.

```bash
# File PHP nella cartella di upload
find wp-content/uploads -type f -name "*.php*"
# Contenuto dei must-use plugin
ls -la wp-content/mu-plugins/
# Tutti i file .htaccess e .user.ini con data di modifica
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# File PHP modificati di recente
find . -type f -name "*.php" -newermt "2026-10-17" -ls
```

Schemi di ricerca generali per il codice offuscato sono descritti nella guida [Riconoscere e rimuovere le webshell](https://phpsos.de/it/ratgeber/webshell-erkennen/).

## Controllare utenti, database e attività pianificate

Molte backdoor non si trovano affatto nel file system. Un account amministratore aggiuntivo spesso basta agli aggressori per tornare in seguito.

```bash
# Tutti gli amministratori con data di registrazione
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Attività pianificate in WordPress
wp cron event list
# Indirizzo del sito (le manipolazioni portano a reindirizzamenti)
wp option get siteurl
wp option get home
# Articoli con script incorporati
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
```

Controlli anche le opzioni con contenuti insolitamente grandi e i widget con codice estraneo. I riscontri non significano automaticamente un attacco, perché anche i codici di tracciamento o le mappe incorporate usano script. È decisivo se qualcuno nel team conosce il contenuto.

> **Importante:**
> Dopo un ritrovamento cambi tutte le password e le chiavi di sicurezza in `wp-config.php`. Altrimenti gli accessi esistenti degli aggressori restano validi.

## Chiudere le backdoor e impedire che tornino

Se ha trovato una backdoor, una reinstallazione è di solito più sicura che riparare singoli file. Questo ordine si è dimostrato valido:

1. Mettere al sicuro le tracce: archiviare log, file sospetti e un'esportazione del database con data.
2. Portare PHP a uno stato corretto e riavviare tutti i processi PHP.
3. Installare di nuovo core, plugin e temi di WordPress dalle fonti originali.
4. Riprendere upload e database dopo verifica, eliminare gli account estranei, cambiare tutti gli accessi.
5. Impedire a livello di server l'esecuzione di PHP nella cartella di upload.

Per Nginx basta a tal fine un blocco nella configurazione del server:

```nginx
location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
}
```

Con Apache si ottiene lo stesso con una regola nella configurazione del server per la cartella di upload. Un `.htaccess` nella cartella di upload stessa è più debole, perché un aggressore con permessi di scrittura può modificarlo di nuovo.

Dopo la bonifica pianifichi alcune settimane di osservazione più stretta. Nuovi amministratori, nuovi file PHP e modifiche a `wp-config.php` dovrebbero in questo periodo saltare subito all'occhio, ad esempio con un controllo regolare tramite WP-CLI o un monitoraggio dei file sul server.

Come impostare in seguito i permessi dei file in modo che WordPress possa scrivere solo dove serve lo mostra la guida [Permessi dei file sul server web](https://phpsos.de/it/ratgeber/dateirechte-webserver/).

## Come aiuta concretamente PHP SOS?

- Mettiamo al sicuro lo stato dell'installazione prima di modificare qualsiasi cosa.
- Controlliamo core, plugin, temi, database, account e configurazione del server alla ricerca di backdoor.
- Reinstalliamo WordPress da fonti pulite e riprendiamo solo contenuti verificati.
- Rafforziamo server e installazione e documentiamo che cosa è stato trovato e risolto.

Il procedimento di una bonifica è descritto nel servizio [Far rimuovere malware e webshell](https://phpsos.de/it/leistungen/malware-entfernung/).


## Domande frequenti

**Un aggiornamento di WordPress chiude la vulnerabilità PHP2Shell?**  
No. PHP2Shell si trova nell'interprete PHP, non in WordPress. Un aggiornamento di WordPress, dei temi o dei plugin non cambia nulla; è decisivo lo stato di PHP sul server e il riavvio di tutti i processi PHP.

**Un plugin di sicurezza trova tutte le backdoor?**  
Non in modo affidabile. Un plugin gira all'interno dell'installazione compromessa e può essere a sua volta manipolato. Lo integri con verifiche dall'esterno, ad esempio con i checksum di WP-CLI e un confronto con i file originali puliti.

**Che cosa sono i mu-plugins e perché sono sospetti?**  
I must-use plugin nella cartella wp-content/mu-plugins vengono caricati automaticamente e non compaiono nell'elenco normale dei plugin. Gli aggressori ne approfittano volentieri, perché i gestori guardano raramente questa cartella.

**Una backdoor può trovarsi anche nel database?**  
Sì. Codice dannoso o reindirizzamenti vengono spesso inseriti in opzioni, articoli o widget. Inoltre gli aggressori creano spesso propri account amministratore, che si trovano nella tabella degli utenti.

## Fonti

- [WordPress.org](https://wordpress.org/)
- [php.net: bollettini di sicurezza](https://www.php.net/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)