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.
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.
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: righeincludeorequireaggiuntive all'inizio o alla fine..htaccesse.user.ininella 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.
# 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.
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.
# 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.
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:
- Mettere al sicuro le tracce: archiviare log, file sospetti e un'esportazione del database con data.
- Portare PHP a uno stato corretto e riavviare tutti i processi PHP.
- Installare di nuovo core, plugin e temi di WordPress dalle fonti originali.
- Riprendere upload e database dopo verifica, eliminare gli account estranei, cambiare tutti gli accessi.
- 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:
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.
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.
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.