Il file segnalato è dentro un plugin famoso. Il plugin è vulnerabile?

Non per forza. Un file iniettato dice che qualcuno con accesso in scrittura ha modificato quel plugin, non che il plugin sia stata la porta di ingresso. La vulnerabilità sfruttata può essere in un altro componente. La verifica delle somme di controllo dice quali file sono stati toccati; i log di accesso dicono da dove è entrato l'attaccante.

Posso semplicemente reinstallare il plugin dalla dashboard?

È un buon primo passo, perché sostituisce tutti i file con gli originali. Non è sufficiente da solo: il componente che ha fatto l'iniezione resta, e la mediana di reinfezione che vediamo dopo una reinstallazione senza bonifica si misura in giorni.

Perché il prefisso è SMW-INJ e non SMW-SA?

Perché il fornitore distingue il codice iniettato in un file esistente dal file autonomo malevolo. Nel corpus i rilevamenti INJ con identificativo numerico stanno per il 52% dentro WordPress e hanno un nome predicibile nel 30% dei casi: sono file veri modificati. La pagina sui prefissi spiega la lettura completa.

CriticoFamiglia antivirus

php.bkdr.wp: la backdoor iniettata in un file legittimo di WordPress

php.bkdr.wp è la firma di una backdoor specifica per WordPress, e nel corpus di misura di WPsec.it dell'agosto 2026 ha un profilo netto: 10 domini, tutti WordPress, su 5 server; il 97% dei file sta dentro l'installazione e il 78% dentro wp-content/plugins, con un nome di senso compiuto e il prefisso SMW-INJ nel 78% dei casi. La lettura più coerente è che non si tratti di file aggiunti ma di file legittimi di plugin in cui è stato iniettato codice: la cartella è quella di un plugin vero, il file è quello vero, il contenuto no.

Famiglia: Backdoor iniettata in file di WordPress · Anche noto come: bkdr.wp, backdoor.wp · Aggiornato il 1 settembre 2026

Le stringhe esatte

Se hai trovato una di queste stringhe sul tuo sito, sei nella pagina giusta.

php.bkdr.wp
SMW-INJ-CLOUDAV-php.bkdr.wp
php.backdoor.wp
SMW-INJ-14643-php.bkdr.wp

Dove si trova

Dentro wp-content/plugins nel 78% dei casi, nella cartella di un plugin che hai davvero installato
Nella radice del sito nell'11%: wp-config.php, index.php, wp-settings.php o un file aggiunto accanto a loro
Con il nome del file originale: la firma scatta sul contenuto, non sul nome

Cosa fa

Esegue codice ricevuto da una richiesta, usando come veicolo un plugin che WordPress carica a ogni pagina.
Sopravvive alle pulizie basate sul nome del file, perché il nome è quello giusto.
Viene spesso sovrascritta da un aggiornamento del plugin, e poi reiniettata dal componente che l'ha messa: se ricompare dopo un aggiornamento, c'è un dropper.

Come verificare

Comandi di sola lettura: non modificano nulla. Sostituisci ESEMPIO.it con il tuo dominio ed esegui dalla radice del sito.

Confronta i plugin del repository con gli originali, file per file
```
wp plugin verify-checksums --all --format=table
```
Confronta il core con l'originale
```
wp core verify-checksums
```

Cerca codice aggiunto in testa o in coda ai file di plugin

grep -rln --include='*.php' -E '^<\?php\s*(eval|@?\$[a-zA-Z_]+\s*=\s*["\x27][^"\x27]{40,})' wp-content/plugins/ | head -20

Cosa non basta fare

Cancellare il file segnalato: è un file del plugin, e senza di lui il plugin si rompe. Va sostituito con l'originale.
Aggiornare il plugin e basta: l'aggiornamento ripristina il file ma non rimuove chi lo ha modificato.
Affidarsi al confronto delle date di modifica: chi inietta codice spesso ripristina la data originale del file.

Cosa fare

Sostituisci il plugin con una copia pulita scaricata dal repository o dal fornitore, non con il backup del sito.
Esegui la verifica delle somme di controllo su tutti i plugin e sul core: dove c'è un file modificato ce ne sono quasi sempre altri.
Cerca il componente che ha fatto l'iniezione: un dropper o una shell nella stessa finestra temporale, spesso fuori da wp-content.
Dopo la sostituzione ripeti la verifica a distanza di giorni: se il file cambia di nuovo, la porta è ancora aperta.