Perché l'antivirus del mio hosting non la rileva?

Perché il codice usa solo funzioni legittime di WordPress. Non c'è offuscamento, non c'è eval, non c'è una stringa codificata: sono cinque righe che qualsiasi plugin di autenticazione potrebbe contenere. È il motivo per cui questa classe si trova con l'analisi dell'integrità dei file, non con le firme.

Come faccio a sapere se qualcuno l'ha usata?

Nei log di accesso del server cerca richieste che arrivano direttamente su pagine di amministrazione senza essere state precedute da una richiesta a wp-login.php. Non tutti gli hosting conservano log abbastanza a lungo: se ci sono, vanno messi al sicuro prima di ogni altra operazione.

CriticoBackdoor

Backdoor a cookie magico: login da amministratore senza password

Una backdoor a cookie magico è codice che, su una richiesta non autenticata, legge un valore da $_COOKIE o $_GET e chiama wp_set_current_user insieme a wp_set_auth_cookie per un utente amministratore: chi conosce il valore entra nella dashboard senza password e senza lasciare un utente nuovo nell'elenco. In un intervento del 2026 WPsec.it ha trovato una backdoor di questa classe solo al secondo passaggio, dopo che il primo ciclo di pulizia era stato dichiarato completo.

Famiglia: Magic-cookie admin auth bypass · Anche noto come: auto-login backdoor, magic cookie backdoor · Aggiornato il 30 agosto 2026

Le stringhe esatte

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

$_COOKIE['_auth']
beary_smol
wp_set_auth_cookie
function lasc()

Dove si trova

In fondo al functions.php del tema attivo, appeso dopo il codice legittimo
In un file dentro wp-content/mu-plugins/, che WordPress carica sempre e non mostra fra i plugin disattivabili
Dentro un plugin dal nome plausibile, in una funzione richiamata su un hook di avvio come init

Cosa fa

Si aggancia a un hook eseguito su ogni richiesta, tipicamente init, quindi non serve visitare una pagina particolare.
Confronta un cookie o un parametro con un valore fisso scelto dall'attaccante e, se coincide, autentica la richiesta come amministratore.
Non crea utenti e non modifica password: l'elenco utenti resta identico, ed è il motivo per cui questa classe sfugge ai controlli superficiali.

Come verificare

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

Cerca chiamate di autenticazione fuori dal core

grep -rn --include='*.php' -E 'wp_set_auth_cookie|wp_set_current_user' wp-content/ | grep -v '/wp-includes/'

Cerca l'uso di cookie o parametri come chiave di accesso

grep -rn --include='*.php' -E '\$_(COOKIE|GET|REQUEST)\[[^]]+\]\s*===?\s*[\x27"]' wp-content/themes/ wp-content/mu-plugins/

Elenca i must-use plugin, che non compaiono nella lista plugin
```
ls -la wp-content/mu-plugins/ 2>/dev/null
```
Confronta i file del tema con quelli del repository ufficiale
```
wp plugin verify-checksums --all
```

Cosa non basta fare

Cambiare tutte le password. Il codice non usa password: ricrea la sessione da zero.
Rimuovere gli utenti amministratori sospetti. Questa backdoor non ne crea nessuno.
Attivare l'autenticazione a due fattori. Il codice chiama direttamente la funzione che imposta il cookie di sessione, saltando la schermata di login.

Cosa fare

Cerca ogni chiamata a wp_set_auth_cookie fuori da wp-includes: nel codice sano di un sito non ce n'è quasi mai motivo.
Controlla mu-plugins per primo: è la posizione che più spesso sfugge, perché la dashboard non la mostra.
Dopo la rimozione invalida tutte le sessioni attive, altrimenti chi è già entrato resta dentro.
Verifica il tema con i checksum ufficiali: la riga appesa in fondo a functions.php è invisibile a occhio su un file lungo.