
Se il tuo sito WordPress usa il plugin AnyWhere Elementor di WPVibes in versione 1.3.0 o precedente, aggiorna alla 1.3.1. La vulnerabilità CVE-2026-114189 è una SQL injection cieca con punteggio CVSS 8.5: un utente con un semplice account da sottoscrittore può interrogare il database e leggere dati che non dovrebbe vedere, incluse le tabelle degli utenti. Qui trovi cosa controllare, come aggiornare e cosa fare se pensi di essere già stato colpito.
Cosa è successo: la vulnerabilità CVE-2026-114189 in AnyWhere Elementor
AnyWhere Elementor è un plugin WordPress che permette di inserire template di Elementor in qualunque punto del sito tramite shortcode. Il plugin non neutralizza correttamente alcuni parametri prima di usarli in una query SQL. È la classe di difetto che OWASP chiama Injection (A3) e che qui si manifesta come Blind SQL Injection: l'attaccante non vede direttamente il risultato della query, ma lo deduce dal comportamento del sito, per esempio dai tempi di risposta o da differenze nella pagina restituita. Richiede più richieste, ma il risultato è lo stesso: lettura di dati dal database.
La segnalazione è arrivata a Patchstack il 24 settembre 2026 ed è stata pubblicata il 6 novembre 2026. Lo stesso difetto è stato catalogato anche come CVE-2026-103914 da un'altra autorità: è un duplicato, l'aggiornamento risolve entrambi gli identificativi.
Chi è colpito: versioni vulnerabili di AnyWhere Elementor
- Plugin: AnyWhere Elementor (slug anywhere-elementor), sviluppatore WPVibes.
- Versioni vulnerabili: tutte fino alla 1.3.0 inclusa.
- Versione corretta: 1.3.1.
Sei esposto se il plugin è installato e attivo in una versione vulnerabile. Il rischio aumenta se il sito consente la registrazione libera degli utenti o ha account con ruolo basso (sottoscrittori, clienti di un negozio, iscritti a una community), perché il privilegio richiesto per sfruttare la falla è proprio quello di sottoscrittore.
Quanto è grave: punteggio CVSS e sfruttamento attivo
Il vettore è CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:L, gravità alta (8.5). In pratica:
- AV:N, AC:L: attacco via rete, senza condizioni particolari.
- PR:L: serve un account autenticato, ma basta il ruolo più basso.
- UI:N: nessuna interazione da parte di un amministratore.
- S:C: l'impatto esce dal perimetro del plugin e tocca l'intero database WordPress.
- C:H: riservatezza compromessa in modo alto: hash delle password, email degli utenti, dati di ordini e form, chiavi salvate nelle opzioni.
- I:N, A:L: l'integrità non è indicata come compromessa, la disponibilità può risentirne (le query time-based rallentano il sito).
Al momento la vulnerabilità non risulta nel catalogo CISA KEV, quindi non c'è conferma di sfruttamento attivo. Patchstack però la classifica a priorità alta e la considera candidata a campagne di sfruttamento di massa, come avviene di norma per i plugin WordPress diffusi: gli attaccanti scansionano migliaia di siti a prescindere dal traffico o dalla notorietà.
Come capire se sei esposto: verifica versione, esposizione e log
Versione installata
- Da pannello: Plugin > Plugin installati, cerca AnyWhere Elementor e leggi la versione sotto il nome.
- Con WP-CLI: wp plugin get anywhere-elementor --field=version
- Via SSH o FTP: apri wp-content/plugins/anywhere-elementor/anywhere-elementor.php e leggi la riga Version: nell'intestazione.
Esposizione
- Controlla in Impostazioni > Generali se è attiva l'opzione Chiunque può registrarsi.
- Verifica se WooCommerce, un plugin di membership o un form permettono la creazione autonoma di account.
- Conta gli utenti con ruolo sottoscrittore in Utenti > Tutti gli utenti e guarda la data di registrazione: account recenti con email generiche sono un indicatore da approfondire.
Log e indicatori di compromissione
- Nei log di accesso del web server cerca sequenze lunghe di richieste dallo stesso IP verso endpoint del plugin con parametri che contengono apici, parole chiave SQL, funzioni come SLEEP( o BENCHMARK(. Una SQL injection cieca produce centinaia di richieste simili in pochi minuti.
- Guarda i tempi di risposta: picchi regolari di lentezza su pagine specifiche sono tipici degli attacchi time-based.
- Verifica lo slow query log di MySQL o MariaDB, se attivo.
- Controlla se compaiono nuovi amministratori, modifiche a file di tema e plugin o accessi da IP insoliti al pannello.
Come risolvere la vulnerabilità: patch, aggiornamento e rimedio
La patch è disponibile: aggiorna AnyWhere Elementor alla versione 1.3.1 o successiva.
- Fai un backup di file e database prima di procedere.
- Da pannello: Bacheca > Aggiornamenti, seleziona il plugin e aggiorna. Oppure da Plugin > Plugin installati con il link Aggiorna ora.
- Con WP-CLI: wp plugin update anywhere-elementor
- Verifica di nuovo la versione e controlla che i template inseriti con il plugin si vedano correttamente.
Se non puoi aggiornare subito, disattiva il plugin finché non lo fai. Patchstack ha pubblicato una regola di mitigazione che blocca i tentativi di attacco nell'attesa dell'aggiornamento: è una misura ponte, non sostituisce la patch. Se il sito è gestito da un fornitore o da un hosting, chiedi a loro di intervenire e fatti confermare la versione installata.
Cosa fare subito: mitigazioni e hardening
- Aggiorna o disattiva il plugin. È l'unica azione che chiude la falla.
- Limita la registrazione. Se non serve, disattiva Chiunque può registrarsi. Se serve, valuta la conferma via email e un controllo antispam sui form.
- Ripulisci gli account. Elimina gli utenti sottoscrittori che non riconosci.
- Metti un WAF davanti al sito con regole contro la SQL injection, a livello di hosting, CDN o plugin.
- Ruota le credenziali se c'è il sospetto di accessi anomali: password degli amministratori, password del database in wp-config.php, chiavi e salt, chiavi API salvate nelle opzioni. Un attaccante che legge il database ottiene gli hash delle password e può tentare di romperli offline.
- Aggiorna anche il resto. Core, tema e altri plugin: un sito con un plugin fermo alla 1.3.0 spesso ne ha altri indietro. Per il core vedi anche CVE-2026-119977 in WordPress Core.
Per chi non ha tempo di seguire gli aggiornamenti, un servizio di manutenzione del sito copre proprio questo: controllo periodico delle versioni, aggiornamenti con backup e verifica dopo l'intervento.
Se sospetti una compromissione: incident response e analisi forense
Se nei log trovi i pattern descritti sopra, tratta il sito come compromesso finché non dimostri il contrario.
- Non cancellare nulla e non reinstallare da zero prima di aver conservato le prove: log del web server, log di PHP e del database, un dump del database e una copia dei file con i timestamp originali.
- Non spegnere il server se è un VPS o un dedicato su cui hai controllo: la memoria e le connessioni attive possono contenere informazioni utili.
- Fai una copia forense prima di qualunque bonifica, così da poter ricostruire cosa è stato letto e da quando. Questo conta anche per capire se i dati personali sono stati esposti.
- Valuta la notifica. Se il database contiene dati personali di clienti o iscritti, il GDPR prevede la notifica al Garante entro 72 ore dalla scoperta della violazione quando il rischio per gli interessati non è trascurabile. Serve una valutazione documentata, non un'ipotesi.
- Bonifica e ripristino solo dopo: aggiornamento, rotazione delle credenziali, ripristino da backup pulito se i file risultano alterati.
Per questo tipo di interventi lo studio offre incident response con preventivo a prezzo fisso, indicativamente da 1.500 a 6.000 €, e verifiche di sicurezza complete da 2.000 a 8.000 € in base al perimetro. Le urgenze hanno un sovrapprezzo del 50%.
Fonti ufficiali
Se non sai quale versione del plugin è installata, se il sito è gestito da un fornitore che non risponde, o se hai trovato qualcosa di strano nei log, scrivimi: richiedi un preventivo gratuito e ti rispondo entro 24 ore, oppure passa dalla pagina contatti per una chiamata rapida anche su WhatsApp.


