--- title: "Bypass OTP WordPress: la stringa 'true' che apre l'admin" description: "Il plugin User Verification by PickPlugins (5.000+ installazioni) validava l'OTP con == invece di ===. Inviando true ci si autentica come qualsiasi utente, admin inclusi. Patch 2.0.47, audit immediato consigliato." canonical_url: "https://spaziorc.com/blog/wordpress-otp-bypass-pickplugins" --- > Index of every page on this site: [llms.txt](https://spaziorc.com/llms.txt) 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: ```php 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:
Versione Data Voce nel changelog
2.0.37 5 luglio 2025 "fix - OTP login feature down for security issue"
2.0.45 19 gennaio 2026 "fix - OTP login security issue fixed"
2.0.47 30 aprile 2026 la patch di CVE-2026-7458
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: ```bash 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: ```bash 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: ```bash # 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`: ```bash 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: ```bash 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](https://spaziorc.com/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](https://my.spaziorc.com/) 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](https://spaziorc.com/blog/cpanel-zero-day-supply-chain). ## Sitemap See the full [sitemap](https://spaziorc.com/sitemap.md) for all pages.