Una falla CSRF in Elementor può trasformare un clic dell’amministratore nel pieno controllo di WordPress

Una vulnerabilità di cross-site request forgery in Elementor Website Builder permette a un aggressore non autenticato di indurre un amministratore WordPress con una sessione attiva a eseguire azioni privilegiate tramite REST API. Nelle installazioni predefinite, l’aggressore può sfruttare la falla per creare un nuovo account amministratore sotto il proprio controllo.

Il problema riguarda le versioni 4.3.0 e 4.3.1 di Elementor. È stato risolto nella versione 4.3.2, che i gestori dei siti dovrebbero installare subito.

Patchstack ha pubblicato i dettagli il 25 settembre 2026. Ha riferito che Elementor era stata informata il 22 settembre, dopo la segnalazione della vulnerabilità da parte del bug hunter “Saggre”. La versione correttiva è stata rilasciata due giorni dopo la segnalazione.

Il controllo del percorso disattiva una protezione fondamentale di WordPress

La vulnerabilità ha origine nel modulo Editor Events di Elementor. Il modulo esamina l’URI grezzo della richiesta e cerca il percorso:

elementor/v1/events/

Quando trova questa stringa, il modulo salta la convalida dei nonce REST di WordPress. I nonce REST aiutano WordPress a verificare che una richiesta autenticata sia stata avviata intenzionalmente dall’utente connesso e non imposta da una parte esterna.

La falla dipende dal modo in cui Elementor identifica il percorso. Anziché determinare in modo sicuro quale endpoint REST venga chiamato, il modulo cerca la stringa attesa nell’intero URI, che può essere influenzato dall’aggressore.

L’URI grezzo comprende anche i parametri della query. L’aggressore può quindi inviare una richiesta a un endpoint REST diverso e aggiungere elementor/v1/events/ nella stringa di query. Elementor riconosce il percorso, che sembra attendibile, e disattiva la verifica del nonce, anche se la richiesta effettiva è diretta a un altro endpoint.

Il browser della vittima include comunque la sessione WordPress autenticata della vittima. Di conseguenza, la richiesta REST viene eseguita con i permessi già in possesso della vittima.

Non si tratta di un bypass dell’autenticazione che consente all’aggressore di accedere direttamente come amministratore. È un attacco CSRF che induce il browser di un amministratore già autenticato a eseguire un’azione per conto dell’aggressore. Nei fatti, tuttavia, il risultato può equivalere alla compromissione dell’account.

Basta un link malevolo per creare un account amministratore persistente

Per sfruttare la falla, un amministratore WordPress deve essere connesso e aprire un URL appositamente creato dall’aggressore. Il link può arrivare via e-mail o chat, oppure essere inserito in un commento sul sito preso di mira.

L’attacco richiede pochissimi passaggi per essere recapitato. Non servono:

• l’esecuzione di JavaScript;
• una pagina web controllata dall’aggressore;
• un modulo HTML nascosto o da inviare;
• un’autenticazione preliminare al sito WordPress preso di mira.

Se l’amministratore ha una sessione attiva, basta un clic.

In un’installazione WordPress predefinita, la richiesta REST contraffatta può creare un altro account amministratore. L’aggressore ottiene così un accesso persistente, indipendente dalla sessione della vittima. Anche se il link malevolo non viene più aperto, il nuovo account resta disponibile finché i difensori non lo individuano e lo rimuovono.

Un account amministratore controllato dall’aggressore può esporre contenuti, configurazioni e dati degli utenti del sito. Può inoltre consentire di gestire plugin e temi, a seconda della configurazione del sito e delle eventuali misure di sicurezza aggiuntive. Non sono note le azioni successive alla compromissione osservate in attacchi reali.

A questa vulnerabilità non è stato assegnato un punteggio di gravità pubblico né un identificativo CVE. Non sono state divulgate informazioni su eventuali sfruttamenti attivi in the wild. Non risultano segnalazioni nel catalogo Known Exploited Vulnerabilities della CISA né scadenze federali per la correzione.

Fino a due milioni di siti potrebbero usare versioni vulnerabili

Elementor Website Builder è attivo su circa 10 milioni di siti web. Le statistiche di adozione di WordPress.org indicano che fino a 2 milioni di siti potrebbero utilizzare versioni vulnerabili.

L’intervallo di versioni interessate è ristretto, ma significativo:

Versione di Elementor	Stato
4.3.0	Vulnerabile
4.3.1	Vulnerabile
4.3.2	Corretto
Precedente alla 4.3.0	Non interessata da questa specifica falla di Editor Events

Le versioni precedenti alla 4.3.0 non includono il proxy Editor Events vulnerabile. Restare a una versione precedente, però, non è una soluzione sicura: quelle release contengono altre falle di sicurezza, alcune delle quali sono già sfruttate attivamente.

La soluzione corretta è quindi aggiornare alla 4.3.2, non effettuare il downgrade.

L’ampia diffusione di Elementor aumenta la probabilità di scansioni opportunistiche e campagne di esche distribuite su larga scala. Gli aggressori non devono necessariamente sapere se un determinato amministratore è connesso in quel momento: possono diffondere link a tappeto e aspettare che uno raggiunga un utente con una sessione privilegiata attiva.

La versione 4.3.2 risolve il bypass tramite stringa di query

Elementor 4.3.2 impedisce agli aggressori di sfruttare la stringa di query per far sembrare che una richiesta REST non correlata sia diretta al percorso Editor Events. Gli amministratori dovrebbero verificare la versione installata, senza affidarsi soltanto all’ipotesi che gli aggiornamenti automatici siano attivi.

Passaggi immediati per correggere il problema:

1. Aggiornare Elementor Website Builder alla versione 4.3.2.
2. Verificare che le versioni 4.3.0 e 4.3.1 non siano più attive in nessuna installazione, comprese quelle di staging o le installazioni WordPress secondarie.
3. Controllare gli account amministratore e individuare quelli che non sono stati creati intenzionalmente.
4. Esaminare le attività recenti di gestione degli account e le richieste REST, se sono disponibili log adeguati.
5. Terminare le sessioni amministrative attive e reimpostare le credenziali se vengono rilevate attività privilegiate non autorizzate.

L’unico elemento concreto della richiesta descritto per questa vulnerabilità è la stringa:

elementor/v1/events/

I difensori possono cercare nei log del server web, del reverse proxy, del web application firewall e dell’applicazione eventuali occorrenze inattese di questo percorso nelle stringhe di query o in richieste dirette a endpoint REST non correlati. La sua presenza, da sola, non prova che il sito sia stato compromesso: anche il traffico legittimo di Elementor può usare lo stesso percorso. È importante valutare il contesto, esaminando insieme l’endpoint effettivo, la posizione nella query, il codice di risposta e le attività associate agli account.

È inoltre opportuno controllare se sono stati aggiunti di recente account amministratore, prestando particolare attenzione a nomi, indirizzi e-mail o date di creazione insoliti. Le informazioni disponibili non indicano nomi utente, indirizzi IP o altri indicatori specifici della campagna.

Il rischio più ampio è la compromissione tramite l’intervento dell’amministratore

Questa vulnerabilità rientra in una categoria di attacchi che sfrutta il browser di un amministratore fidato come meccanismo di esecuzione. L’aggressore non viola la password dell’amministratore né ruba direttamente un cookie di sessione. Una convalida debole delle richieste permette invece a un link creato ad hoc di trasformare la sessione già attiva dell’amministratore in un’azione privilegiata.

In questo scenario sono importanti le normali misure di difesa contro il phishing, ma la prudenza degli utenti non sostituisce l’aggiornamento. I link possono essere camuffati, accorciati o inseriti in contesti in cui gli amministratori fanno clic di frequente. Inoltre, non servono né JavaScript né un sito malevolo dedicato, riducendo così l’infrastruttura che l’aggressore deve gestire.

Di recente WordPress ha dovuto affrontare un’altra falla che richiedeva l’interazione di un amministratore: una visita poteva essere sfruttata per forzare l’installazione di un tema e potenzialmente avviare una catena di compromissione più ampia. Il problema è stato descritto come Click2Shell, un attacco che trasforma la visita di un amministratore nell’installazione forzata di un tema.

Per chi usa Elementor, la soluzione è semplice: installare la 4.3.2. La falla potrebbe non avere ancora un CVE o un punteggio di gravità, ma il suo impatto nelle installazioni predefinite — la creazione di un account amministratore controllato dall’aggressore — è un motivo sufficiente per considerare urgente l’aggiornamento.