Una falla CSRF in Elementor consente agli attaccanti di creare account amministratore

Elementor, il page builder per WordPress più utilizzato al mondo con oltre dieci milioni di installazioni attive, ha corretto una vulnerabilità cross-site request forgery (CSRF) che consentiva a un singolo link di eseguire qualsiasi azione REST API che l'utente connesso è autorizzato a compiere. Scoperta dal ricercatore Saggre e segnalata a Patchstack, la falla riguarda solo le versioni 4.3.0 e 4.3.1 del plugin Elementor Website Builder. Su un'installazione WordPress standard, un amministratore che clicca un link appositamente creato mentre è connesso può creare inconsapevolmente un secondo account amministratore per un attaccante, senza JavaScript, senza form e senza alcuna pagina sotto il controllo dell'attaccante. Patchstack ha pubblicato regole di mitigazione per proteggersi dallo sfruttamento.

Nelle versioni interessate, Elementor disattiva l'unica protezione CSRF del core di WordPress per le richieste REST API autenticate tramite cookie ogni volta che la stringa letterale elementor/v1/events/ compare in qualsiasi punto dell'URI della richiesta. Poiché l'URI della richiesta include la query string, e la query string è scritta da chi compone il link, qualsiasi richiesta REST può autoescludersi da quella protezione aggiungendo un parametro dall'aspetto innocuo. Il codice vulnerabile si trova nel modulo Editor Events, che fa da proxy alla telemetria dell'editor di Elementor. Il modulo è nascosto dalla schermata Experiments del sito, ma è attivo per impostazione predefinita su ogni sito la cui prima installazione di Elementor era la versione 3.32.0 o successiva, quindi un'installazione predefinita di 4.3.0 o 4.3.1 è interessata. Il costruttore del modulo registra il filtro incondizionatamente, il che significa che nessuna impostazione di telemetria sul sito lo impedisce. Le versioni precedenti alla 4.3.0 non includono questo proxy e non sono vulnerabili.

Il problema principale è la tempistica. Il proxy degli eventi registra due route REST e vuole che le proprie richieste siano esentate dal controllo del nonce REST. Per ottenere ciò, aggancia rest_authentication_errors alla priorità 0, prima che WordPress abbia associato qualsiasi route. La callback verifica se l'URI grezzo della richiesta contiene la stringa elementor/v1/events/, usando una ricerca di sottostringa non ancorata. Poiché la query string è interamente controllata dall'attaccante, è possibile creare un nome e un valore di parametro che soddisfino questo controllo mentre la richiesta viene indirizzata a un endpoint completamente diverso. Una volta superato il controllo, la callback restituisce true, il che comunica a ogni gestore di autenticazione successivo, inclusa la verifica del nonce del core di WordPress, che l'autenticazione è già avvenuta con successo. Il permission_callback della route viene comunque eseguito, quindi sono i permessi della vittima a decidere cosa può fare l'attaccante. L'autorizzazione rimane intatta; è solo la prova dell'intenzione che viene a mancare.

L'attacco entra interamente in un URL perché il core di WordPress accetta un parametro di query _method che sovrascrive il verbo HTTP. Una normale navigazione GET può quindi eseguire scritture. I ricercatori di Patchstack hanno dimostrato un URL che crea un nuovo utente con il ruolo di amministratore: la richiesta punta a /wp-json/wp/v2/users e aggiunge _method=POST, più i parametri per username, email, password e roles. Il parametro finale, x=elementor/v1/events/, è l'unica parte che conta. Senza di esso, WordPress restituisce HTTP 401 con rest_cannot_create_user. Con esso, il server restituisce HTTP 201 e un oggetto utente il cui array roles è ["administrator"]. Il ricercatore ha anche confermato che un marcatore più corto di un carattere rispetto al namespace reale, elementor/v1/event/, viene rifiutato, escludendo qualsiasi altra spiegazione per la differenza. Poiché è sufficiente un singolo tag anchor, il payload può essere consegnato ovunque possa arrivare un link: un'email, un messaggio in chat, un post su un forum o un commento su un sito non correlato. La vittima vede un link normale e una risposta JSON.

L'impatto è più ampio degli endpoint di Elementor stesso. Il bypass viene eseguito prima che WordPress instradi la richiesta, quindi si applica all'intera superficie REST API del sito: le route del core di WordPress e le route di ogni altro plugin installato insieme ad esso. Creare un amministratore tramite /wp/v2/users è la dimostrazione più chiara, ma il report di Patchstack ha anche mostrato che GET /wp-json/wp/v2/settings passa da HTTP 401 a HTTP 200 con le impostazioni del sito nel corpo della risposta. Qualsiasi azione che l'account della vittima può compiere via REST rientra nell'ambito, inclusi gli endpoint appartenenti a plugin che non hanno fatto nulla di sbagliato.

Elementor ha corretto la vulnerabilità nella versione 4.3.2. Il controllo sostitutivo legge $wp->query_vars['rest_route'], che è la route che WordPress ha effettivamente risolto dopo la riscrittura, con la query string già separata. Nessun testo composto dall'attaccante rimane nel valore testato. Anche il confronto è cambiato da una ricerca di sottostringa permissiva a un controllo ancorato che verifica che la route inizi con /elementor/v1/events/. Una guardia is_string chiude la porta all'invio di rest_route come array. Contano sia la fonte dell'input sia il confronto ancorato; correggere solo uno dei due avrebbe lasciato una versione più piccola dello stesso bug.

La causa principale è un disallineamento tra una domanda e i dati disponibili per rispondervi. Il codice voleva sapere se una richiesta fosse destinata alla propria route, ma lo chiedeva in un punto del ciclo di vita della richiesta in cui WordPress non aveva ancora deciso questo, e si accontentava di una ricerca di sottostringa su una stringa controllata dal client. Due lezioni sono generalizzabili oltre Elementor. Primo, $_SERVER['REQUEST_URI'] è input controllato dall'attaccante, non metadati di routing; qualsiasi decisione di sicurezza basata su di esso deve rimuovere la query string e ancorare il confronto. Secondo, rest_authentication_errors è un canale condiviso, e restituire un valore truthy su di esso non è un'opzione di esclusione locale; dichiara il successo a ogni gestore a valle, inclusa la verifica del nonce del core di WordPress. Un filtro che ha solo bisogno di dire 'nessuna opinione' dovrebbe restituire il risultato originale invariato. Patchstack ha ricevuto il report il 2026-09-22, Elementor ha rilasciato la versione 4.3.2 il 2026-09-24, e l'avviso pubblico è stato pubblicato il 2026-09-25. La raccomandazione è aggiornare Elementor alla versione 4.3.2 o superiore immediatamente.

Per i proprietari di siti web, questa vulnerabilità è un promemoria del fatto che i plugin ampiamente utilizzati sono obiettivi attraenti e che un singolo plugin non aggiornato può mettere a rischio un intero sito. I servizi di hosting WordPress gestito come AEU Hosting, che fornisce hosting WordPress gestito end-to-end sicuro, possono essere una parte utile di una routine di sicurezza che include aggiornamenti tempestivi dei plugin e monitoraggio.