Il dettaglio che cambia tutto è un altro: la versione installata era aggiornata. E la vulnerabilità — la CVE-2026-57807, divulgata da Patchstack il 9 luglio 2026 — colpisce tutte le versioni fino alla 38.5.8 inclusa. CVSS 9.8, autenticazione rotta, sfruttabile da chiunque senza credenziali e senza alcuna interazione. E al momento della divulgazione non esisteva una patch ufficiale del fornitore: solo un virtual patch di Patchstack e una raccomandazione secca, disattivate e rimuovete il plugin dai siti esposti a internet.

Ho passato quella settimana a gestire il caso a mano, un'ora alla volta, e mi sono reso conto che il metodo che abbiamo seguito potrebbe servire a molti. Perché il vero tema qui non è questo specifico plugin: è cosa fare quando un componente critico del tuo sito WordPress diventa vulnerabile e nessuno ti consegna la correzione. È una situazione che sto vedendo sempre più spesso nel lavoro di assistenza WordPress, e merita un playbook.

Cosa succede davvero con CVE-2026-57807

Partiamo dalla tecnica, perché le decisioni che seguono dipendono da questo. La vulnerabilità è classificata come Broken Authentication: il flusso di recupero password del plugin apre un percorso di autenticazione alternativo che non applica i controlli previsti. In gergo tecnico parliamo di CWE-288, autenticazione bypassata tramite un canale alternativo, e del pattern CAPEC-50, lo sfruttamento del meccanismo di recupero credenziali.

Tradotto: un attaccante remoto, senza account e senza dover ingannare nessuno, può autenticarsi come qualsiasi utenza del sito. Compresi gli amministratori. Complessità di exploit bassa, nessuna interazione utente, il tutto da qualunque punto di internet. Quando Patchstack classifica un caso come priorità alta e prevede campagne di exploit massivo, non sta facendo allarmeismo: sta descrivendo la meccanica del problema.

E qui arriva il punto dolente per chi usa un plugin SSO: la funzione per cui l'hai installato è esattamente il canale d'attacco. Il Single Sign-On che collegava il tuo WordPress ad Azure, Okta o Google diventa una porta secondaria che salta i controlli del login tradizionale. Non è un bug marginale in una funzione che non usi: è il cuore del componente.

Il problema vero: un plugin critico senza patch

Un plugin vulnerabile con un fix disponibile è una scocciatura: aggiorni e sei a posto. Un plugin vulnerabile senza patch è un problema di gestione del rischio: devi decidere, e deciderlo bene.

Chiarisco la differenza tra le due cose che in questi giorni sento confondere. La patch è la correzione del codice, rilasciata dal fornitore, che elimina la vulnerabilità. Il virtual patch è una regola di difesa — tipicamente sul firewall applicativo — che blocca i tentativi di sfruttamento noti, senza toccare il codice. Patchstack ha rilasciato il virtual patch per CVE-2026-57807, e finora il fornitore non ha pubblicato la correzione ufficiale.

Il virtual patch è utile, ma ha due limiti onesti da conoscere. Primo: protegge solo dagli exploit che la regola riconosce; una variante del payload può passare. Secondo: non risolve la radice; il giorno in cui togli il WAF, il buco è ancora lì. Nel nostro caso il virtual patch ha comprato tempo per decidere con calma, non sicurezza.

E non è un caso isolato. Tra fine agosto e inizio settembre 2026 Wordfence e Patchstack hanno divulgato cinque vulnerabilità critiche, con punteggi tra 9.8 e 10.0, su WPMU DEV Dashboard, tema Avada, TranslatePress, Pods e GiveWP: bypass di autenticazione, takeover di account, esecuzione di codice remoto. È lo stesso spettacolo che avevamo visto con la SQLi su All-in-One WP Migration, il plugin vulnerabile che ha esposto 3,25 milioni di siti. Il 1° settembre WordPress.org ha aggiornato le linee guida del proprio Vulnerability Disclosure Program, spingendo i ricercatori verso i difetti con impatto reale. Il messaggio di fondo è chiaro: il flusso di divulgazione funziona meglio che mai, e il flusso di correzione non sempre sta dietro.

Il playbook delle 3 decisioni

Ecco il metodo che abbiamo seguito, in ordine. Tre decisioni, ognuna con un criterio di uscita chiaro. Se ti trovi davanti a un plugin critico senza patch, questo è l'ordine con cui le affronterei.

Decisione 1: disattivare subito, senza aspettare

La prima decisione è quasi sempre la più difficile perché sembra la più costosa: spegnere il plugin. Il nostro istinto dice che disattivare un componente di login significa bloccare decine di persone al lavoro. Nella pratica è il contrario: chi si autentica come amministratore tramite una porta bucata può bloccare l'intera azienda.

Dal momento dell'advisory al plugin disattivato sul portale del mio cliente sono passati circa quaranta minuti, di cui trenta per leggere l'advisory con calma e dieci per l'operazione vera e propria. Il comando è una riga:

# comando WordPress
wp plugin deactivate miniorange-login-with-eve-online-google-facebook --allow-root

Cosa si perde: il flusso SSO. Cosa resta: il login classico di WordPress, che abbiamo subito rinforzato con l'autenticazione a due fattori e con una revisione delle utenze. I quaranta utenti commerciali hanno accettato il cambio senza drammi, con una comunicazione di tre righe che spiegava il perché. Il criterio di uscita da questa fase è semplice: la porta vulnerabile è chiusa, e hai una prova (il log di disattivazione e la data).

Se il plugin disattivato rompe qualcosa di critico — un flusso di pagamento, un'integrazione indispensabile — la valutazione cambia: serve un piano con l'hosting o con un supporto WordPress gestito che metta in campo protezioni a livello server mentre riorganizzi il flusso. Ma "rompe il flusso" va dimostrato, non assunto.

Decisione 2: virtual patch e WAF, cosa proteggono davvero

La seconda decisione è difensiva: mentre valuti, il sito resta esposto a tentativi automatici. Qui entrano il virtual patch di Patchstack e le regole WAF del tuo hosting o del tuo firewall applicativo. Nel caso del mio cliente abbiamo lavorato su tre livelli: la regola del virtual patch, una restrizione degli endpoint di login e recupero password con allowlist IP per gli accessi amministrativi, e un monitoraggio dei log puntato sui path coinvolti.

La regola che mi porto a casa: il virtual patch protegge dagli exploit noti, non dalle varianti. È un recinto attorno a un fosso, non la riparazione del fosso. Trattalo come una misura che comprare tempo — ore o giorni, non mesi — mentre procedi con le decisioni vere. E documenta quando è attivo: il giorno in cui cambierai fornitore di WAF, quel dettaglio varrà oro.

Decisione 3: sostituire il plugin, o eliminare il bisogno

La terza decisione è quella che chiude il caso. Ci sono due strade, e vanno valutate in questa dimensione: quanto ti serve davvero quella funzione.

Prima strada: eliminare il bisogno. Nel nostro caso la domanda esplicita che ho fatto al cliente è stata: "Perché quaranta persone usano l'SSO?" La risposta onesta era "perché due anni fa sembrava comodo", non "perché un contratto enterprise lo impone". Abbiamo risolto con login classico, 2FA obbligatoria e password manager aziendale: funzionalità equivalente per il caso d'uso reale, zero componenti critici in più.

Seconda strada: sostituire il componente con un'alternativa mantenuta meglio. Se l'SSO è un requisito contrattuale, la scelta va fatta sui criteri giusti: attività di manutenzione negli ultimi mesi, storia di risposte rapide alle segnalazioni di sicurezza, trasparenza del changelog. Un plugin che ha già attraversato una vulnerabilità critica rispondendo in giorni vale più di uno che non ha mai avuto problemi solo perché non è mai stato guardato. E prima di installare qualunque sostituto, leggi la lista dei componenti da tenere d'occhio: alcuni plugin di login e sicurezza compaiono regolarmente nell'analisi dei plugin WordPress da evitare proprio per il peso che portano addosso.

La lista di controllo in 10 minuti

Se hai un plugin SSO o di autenticazione installato e vuoi verificare la tua posizione, questa è la sequenza che seguirei oggi, in dieci minuti di lavoro effettivo:

• Cerca il plugin tra gli attivi e annota la versione esatta.
• Verifica sull'advisory se la tua versione rientra nel range colpito.
• Se rientra e non c'è patch: disattiva, non sospendere, disattiva.
• Reinforza il login classico: 2FA, revisione degli amministratori, limitazione degli accessi.
• Attiva o verifica le regole WAF sugli endpoint di login e recupero password.
• Controlla i log dei tentativi di accesso nelle ultime due settimane: accessi da IP insoliti, orari strani, tentativi sul canale alternativo.
• Scrivi in un documento le decisioni prese e la data: il registro è la tua prova.

I comandi WP-CLI che ho usato, in ordine:

wp plugin list --status=active --field=name --allow-root
wp plugin get miniorange-login-with-eve-online-google-facebook --field=version --allow-root
wp plugin deactivate miniorange-login-with-eve-online-google-facebook --allow-root
wp user list --role=administrator --fields=ID,user_login,user_email --allow-root

Se il vocabolario di questi comandi ti è ostile, la guida completa a WP-CLI del nostro sito parte proprio da lì. E se il sito ha subito accessi sospetti, non fermarti alla disattivazione: segui la procedura di ripristino per un WordPress hackerato, perché l'autenticazione compromessa è la prima ipotesi da escludere.

Perché succede ancora

La domanda che mi sono posto chiudendo il caso è l'altra metà del lavoro. Perché un plugin critico può restare senza patch, e perché migliaia di siti continuano a esporlo?

La prima risposta è la catena di fornitura. Un plugin di autenticazione è un pezzo di infrastruttura: quando si rompe, rompe a valle in decine di migliaia di installazioni. Non è un difetto del modello WordPress — lo stesso accade in ogni stack software — ma nel nostro ecosistema la percezione di sicurezza è distorta dalla popolarità: "l'ha installato chi mi ha fatto il sito", "ha migliaia di recensioni", "esiste da dieci anni". Nessuna di queste frasi dice nulla sul processo di risposta alle vulnerabilità.

La seconda risposta è la lentezza organizzativa. Ho visto più volte la stessa dinamica: l'advisory esce, chi gestisce il sito non lo sa, chi ha scelto il plugin non gestisce più il sito, e nel frattempo gli scanner automatici cercano la versione vulnerabile. La cura non è leggere tutte le advisory a mano: è avere una routine. La manutenzione mensile che applichiamo sui siti che seguiamo prevede esattamente questo: controllo delle advisory sul software installato, aggiornamenti programmati con backup verificati, e un registro delle decisioni. Le procedure per aggiornare senza rompere il sito sono la parte visibile; la parte che salva è il monitoraggio quotidiano delle fonti di sicurezza — il tipo di lavoro che trova posto naturale nel servizio di assistenza WordPress quando la sicurezza non può restare un pensiero occasionale.

Illesson learned: cosa mi porta a casa

Chiudo con il bilancio personale del caso, perché è lì che si impara. Errore mio: per tre anni ho considerato quel plugin "risolto" perché non dava problemi. Un componente di autenticazione non va mai classificato come risolto: va classificato come osservato. Correzione che ho applicato su tutti i siti che seguo: ogni trimestre, i cinque componenti più critici per ruolo — autenticazione, pagamenti, form, backup, SEO — vengono riconfrontati con la loro storia di sicurezza, non solo con la versione installata.

E una conferma: la velocità batte la perfezione. Quaranta minuti dalla lettura dell'advisory alla porta chiusa hanno reso le decisioni successive tranquille. Se quella sera avessimo aspettato "il momento giusto per organizzare il cambio SSO", avremmo deciso sotto pressione, con gli attaccanti che nel frattempo scandivano i tempi.

Riferimenti utili

• L'advisory Patchstack su CVE-2026-57807
• The Hacker News: cinque vulnerabilità critiche in plugin e temi WordPress
• WordPress.org: aggiornamenti al Vulnerability Disclosure Program
• Plugin WordPress vulnerabile: 3,25 milioni di siti esposti
• WordPress hackerato: guida al ripristino e alla sicurezza