Bypass OTP WordPress: la stringa 'true' che apre l'admin

Il 2 maggio 2026 il National Vulnerability Database e Wordfence hanno pubblicato CVE-2026-7458: una vulnerabilità di authentication bypass con punteggio CVSS 9.8 (Critical) nel plugin User Verification by PickPlugins, oltre 5.000 installazioni WordPress attive. Il bug è tanto critico quanto didattico: una singola scelta fra == e === in PHP trasformava un OTP a 6 cifre in una porta sempre aperta. Bastava inviare la parola true come codice OTP per autenticarsi come qualsiasi utente con email verificata, amministratori inclusi.

La patch è arrivata silenziosamente due giorni prima della CVE, il 30 aprile, come versione 2.0.47. Se hai il plugin installato e non sei già aggiornato, l'urgenza è oggi.

Cosa è successo

Il 30 aprile 2026 PickPlugins ha rilasciato la versione 2.0.47 di User Verification. Il changelog dice una riga sola: "fix - Unauthenticated Authentication Bypass via OTP Verification REST API Endpoint issue fixed".

Il 2 maggio Wordfence e il NVD hanno pubblicato la CVE assegnata:

• Identificativo: CVE-2026-7458
• CVSS v3.1: 9.8 (Critical) - vettore AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Classificazione: CWE-288 (Authentication Bypass Using an Alternate Path or Channel)
• Versioni vulnerabili: tutte le versioni fino alla 2.0.46 compresa (la OTP login è stata reintrodotta come feature ufficiale nella 2.0.38 di agosto 2025)
• Versione patchata: 2.0.47
• Funzione incriminata: user_verification_form_wrap_process_otpLogin

Il vettore è di rete, senza autenticazione, senza interazione utente. Tutto quello che serve è una richiesta HTTP a un endpoint REST pubblico del plugin. Gli scanner di massa pre-CVE hanno tipicamente 24-72 ore per individuare bug di questa categoria, e siamo a 9 giorni dalla disclosure pubblica.

Perché un == ti svuota il sito

La funzione vulnerabile riceve l'OTP a 6 caratteri inviato dall'utente e lo confronta con quello atteso lato server. Il problema non è nel come l'OTP viene generato o memorizzato. È nell'operatore di confronto: == invece di ===.

In PHP, == esegue type juggling prima di valutare l'uguaglianza. In pratica:

var_dump(true == "qualsiasi_stringa_non_vuota"); // bool(true)
var_dump(true == "483921");                      // bool(true)
var_dump(true == "0");                           // bool(false) - eccezione storica
var_dump("true" == 0);                           // bool(true) su PHP 7

Il primo confronto è quello che brucia il sito. Lato server l'OTP atteso è una stringa di 6 caratteri (per esempio "483921"). L'attaccante, invece di provare un milione di combinazioni in brute force, invia come OTP il valore booleano true (o un payload JSON che il framework di-serializza in true). Il confronto debole true == "483921" restituisce true, e l'autenticazione passa.

Il prerequisito è conoscere o indovinare l'email di un utente verificato sul sito. Per un sito aziendale, gli indirizzi prevedibili (info@, admin@, redazione@, direzione@) sono spesso letteralmente sul piè di pagina o nella pagina contatti. Se l'account corrispondente è un amministratore, l'attaccante diventa amministratore: può installare plugin malevoli, creare nuovi admin, esfiltrare i dati dei clienti, defacciare il sito.

=== avrebbe forzato il controllo di tipo: true === "483921" è false in qualsiasi versione di PHP. Tre caratteri di differenza in una riga di codice. È esattamente il pattern che OWASP documenta da oltre dieci anni alla voce PHP Type Juggling, ed era ancora in produzione su circa 5.000 siti il mese scorso.

Il problema non è uno solo: lo storico OTP di questo plugin

Una vulnerabilità isolata si patcha e si va avanti. Un pattern è un segnale d'allarme. Scorrendo il changelog ufficiale di User Verification by PickPlugins, l'OTP login è già passato per altri due round di patching nell'ultimo anno:

Tre interventi sullo stesso modulo in nove mesi, e i primi due senza CVE pubblici associati. Significa due cose: il codice della OTP login ha debito tecnico di sicurezza accumulato, e il vendor corregge in modo reattivo (riceve la segnalazione, patcha, va avanti) invece che proattivo (audit strutturato del modulo, fuzzing, code review esterno). Per un plugin che si presenta esplicitamente come "Complete WordPress User Authentication & Security Plugin", è un problema di posizionamento.

Non è un attacco al vendor: è esattamente il tipo di pattern che dovresti riconoscere prima di installare qualsiasi plugin che si frapponga fra l'utente e il login del tuo sito. Per inciso, lo stesso plugin alla data del 2 maggio 2026 risolveva 0 su 2 ticket sul forum di supporto degli ultimi due mesi.

Cosa fare oggi sul tuo sito

Tre azioni in ordine di priorità.

1. Aggiorna a 2.0.47

Bacheca WordPress → Plugin → Aggiornamenti. Se hai gli aggiornamenti automatici attivi probabilmente sei già coperto, ma vale comunque la pena verificare la versione installata. Da WP-CLI:

wp plugin get user-verification --field=version
# atteso: 2.0.47 (o superiore)

Se ricevi 2.0.46 o inferiore, fai partire l'aggiornamento subito:

wp plugin update user-verification

2. Audita gli accessi degli ultimi 12 giorni

La CVE è pubblica dal 2 maggio, ma una vulnerabilità di questo tipo è il tipo di bug che gli scanner di massa identificano e armano in poche ore. Concretamente:

# elenca gli amministratori
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# elenca i plugin attivi (cerca quelli che non hai installato tu)
wp option get active_plugins

# cerca account creati di recente in tutti i ruoli privilegiati
wp user list --role__in=administrator,editor,shop_manager \
  --fields=ID,user_login,user_email,user_registered,roles \
  --orderby=user_registered --order=DESC

Confronta gli amministratori e gli editor con il tuo elenco autorizzato. Sui log Apache/Nginx, cerca richieste POST a endpoint che contengono otp o user_verification:

grep -E "POST.*(user.verification|otp.login|wp-json.*user-verification)" \
  /var/log/apache2/access.log* | less

Se trovi qualcosa che non quadra (admin che non hai creato, plugin che non hai installato, file modificati che non riconosci come wp-config.php, wp-admin/index.php, file in wp-content/uploads/ con estensione .php), il sito va trattato come compromesso: backup forense, reinstallazione pulita di core e plugin, ripristino dei contenuti dopo verifica.

3. Forza il reset password degli account privilegiati

Anche in assenza di tracce di abuso, è una pratica sana. Gli amministratori, gli editor e gli shop manager (su WooCommerce) dovrebbero rigenerare la password e fare logout globale dalle sessioni attive:

wp user reset-password $(wp user list --role=administrator --field=ID) --skip-email
# poi notifica via canale fuori banda

Se non riesci ad aggiornare il plugin subito (per esempio per un blocco di compatibility check su un'installazione molto datata), disattiva la funzione OTP login dalle impostazioni del plugin o disinstalla il plugin temporaneamente. La login standard di WordPress, anche senza OTP, è oggi più sicura del modulo OTP di User Verification 2.0.46.

Come si sceglie (e si audita) un plugin di autenticazione

CVE-2026-7458 è uno di quei bug "una riga di codice, 5.000 siti compromessi" che vale la pena usare come momento didattico. Quattro check rapidi prima di installare un plugin che gestisce il login:

1. Leggi il changelog completo, non solo l'ultimo entry. Cerca le voci che contengono security, auth, bypass, CVE, vulnerability. Tre fix di sicurezza sullo stesso modulo in un anno è un pattern, non un'eccezione.
2. Verifica il numero di installazioni attive vs il numero di contributori. User Verification ha 5.000+ installazioni e un solo contributore. Plugin di autenticazione mantenuti da una sola persona, anche se popolari, hanno meno occhi sul codice.
3. Controlla "Issues resolved in last two months" e la qualità delle risposte al supporto. Se è 0 out of 2, vuol dire che il vendor risponde poco o niente. Quando esce una CVE, vuoi un vendor reattivo.
4. Preferisci primitive standard, non plugin che reinventano l'autenticazione. Se ti serve l'OTP, scegli soluzioni che usano librerie crittografiche provate (TOTP/RFC 6238) invece di OTP custom in PHP confrontato con ==. Two-Factor (mantenuto dal team di WordPress.org con contributor core del progetto, 100.000+ installazioni attive) e Wordfence Security (5 milioni di installazioni, con le funzioni Login Security ora integrate nel plugin principale a partire da luglio 2026) partono da una base molto più robusta.

Se il tuo sito è ospitato sui nostri piani di hosting condiviso, il modulo di scansione integrato monitora gli identificativi CVE noti contro le installazioni dei plugin più diffusi e segnala automaticamente i casi critici aperti. Se hai dubbi sullo stato del tuo sito, scrivici dall'Area Riservata e diamo un'occhiata insieme.

In breve

CVE-2026-7458 è il classico bug "tutorial PHP del 2008" finito in produzione: == invece di === in un confronto critico, e l'autenticazione cede. Patch uscita il 30 aprile 2026 come versione 2.0.47 di User Verification by PickPlugins, CVE pubblica dal 2 maggio. Se hai il plugin installato e usavi la OTP login, aggiorna oggi, audita gli accessi degli ultimi 12 giorni, ruota le credenziali admin. Più in generale, è un buon momento per ricordare che ogni plugin che ti gestisce il login è una superficie d'attacco al cuore del sito, e va scelto come si sceglie un fornitore critico: con il changelog aperto e i pattern di patching sotto gli occhi.

Per il contesto sulla stessa categoria di rischio nella supply chain dell'hosting, vale la pena rileggere il pezzo sulla lezione dei due mesi di silenzio di cPanel.