WordPress sotto attacco: oltre 440.000 tentativi contro Super Forms ed Elementor Pro

Due vulnerabilità critiche nei plugin WordPress Super Forms – Drag & Drop Form Builder ed Elementor Pro vengono sfruttate attivamente per caricare file PHP ed eseguire codice sui server.

Wordfence ha bloccato complessivamente più di 440.000 tentativi di exploit: oltre 250.000 contro CVE-2026-14894 in Super Forms e più di 190.000 contro CVE-2026-32475 in Elementor Pro.

In entrambi i casi gli attacchi possono essere condotti senza autenticazione. Se lo sfruttamento riesce, l’aggressore può installare una web shell, eseguire comandi, aggiungere amministratori WordPress, sottrarre dati e prendere il controllo dell’installazione.

Due campagne già operative su larga scala

L’attività contro Super Forms sarebbe cominciata il 14 luglio 2026, per poi superare le 40.000 richieste di exploit il 18 agosto 2026. I tentativi diretti alla vulnerabilità di Elementor Pro sono invece iniziati il 19 agosto 2026.

Wordfence ha descritto le due campagne in report pubblicati nella stessa settimana. Non è stata formulata un’attribuzione a un gruppo criminale specifico: gli indirizzi IP osservati identificano infrastrutture utilizzate negli attacchi, ma non provano l’identità degli operatori.

Le due vulnerabilità rientrano nella categoria CWE-434, cioè il caricamento senza adeguate restrizioni di file potenzialmente pericolosi. Il risultato finale è simile, ma i meccanismi di sfruttamento sono differenti.

Per CVE-2026-14894, NVD assegna un punteggio CVSS 9.8 con vettore:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Per CVE-2026-32475, il punteggio NVD è CVSS 9:

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

Un’altra valutazione riporta per Elementor Pro una gravità pari a 9.0/9.8. Il dato va tenuto distinto dal punteggio ufficiale NVD disponibile, che resta 9.

Super Forms accetta PHP mascherato da immagine

CVE-2026-14894 interessa tutte le versioni di Super Forms – Drag & Drop Form Builder fino alla 6.3.313 inclusa. La correzione è disponibile nella versione 6.3.314.

La falla si trova nel flusso AJAX utilizzato per inviare i moduli. L’handler submit_form, accessibile anche agli utenti non autenticati attraverso un endpoint nopriv, non applica correttamente né la verifica del tipo di file né un controllo delle capability WordPress.

Era presente un nonce di sessione, ma non costituisce una protezione efficace. Un visitatore non autenticato può infatti ottenerlo liberamente richiamando un altro endpoint nopriv, per poi usarlo nella richiesta malevola.

Gli attacchi osservati inviano richieste POST a:

/wp-admin/admin-ajax.php

La richiesta utilizza l’azione super_submit_form e include parametri come form_id=2, sf_nonce, sf_upload_field e il tipo files. L’attaccante controlla inoltre il nome del file e il contenuto trasmesso.

In un campione analizzato, il payload PHP era codificato in Base64 e dichiarato come se fosse un’immagine GIF:

data:image/gif;base64

Il contenuto reale, tuttavia, era codice eseguibile. Il file veniva salvato con il nome:

Mushr00w_upl.php

Si tratta di una web shell predisposta per ricevere e caricare ulteriori payload. Il MIME apparentemente innocuo non impedisce quindi l’esecuzione, perché il controllo non stabilisce in modo affidabile la reale natura del file.

Elementor Pro aggirato con un array costruito ad arte

CVE-2026-32475 riguarda Elementor Pro fino alla versione 4.2.1. NVD non indica una versione iniziale precisa del ramo vulnerabile. La release corretta è la 4.2.2.

Lo sfruttamento richiede una configurazione specifica sul sito bersaglio: deve esistere almeno una pagina Elementor pubblicata che contenga un widget Form con un campo File Upload. L’attacco resta privo di autenticazione, ma questa precondizione spiega la maggiore complessità indicata nel vettore CVSS.

Il bypass sfrutta il modo in cui viene strutturato il campo di caricamento. L’aggressore lo invia come array: il primo elemento viene lasciato vuoto, mentre il secondo contiene il payload PHP e un nome che termina con l’estensione .php.

Questa costruzione elude la validazione. Il plugin scrive quindi il file nella directory:

/wp-content/uploads/elementor/forms/

Il nome viene generato casualmente, ma l’estensione .php controllata dall’attaccante viene conservata. A quel punto è sufficiente richiamare direttamente il file per eseguire comandi sul server.

Patchstack aveva già divulgato i dettagli di CVE-2026-32475 il mese scorso. L’attività successivamente osservata conferma che le informazioni tecniche sono state integrate in campagne reali, non soltanto in test dimostrativi.

Dalla web shell al controllo completo del sito

Il primo effetto delle due vulnerabilità è la possibilità di depositare codice PHP in una posizione raggiungibile via web. Da quel momento, l’impatto dipende dai privilegi dell’account con cui il server esegue PHP e dalla configurazione dell’hosting.

Una web shell può essere utilizzata per:

• caricare malware e strumenti aggiuntivi;
• eseguire comandi arbitrari sul sistema;
• modificare temi, plugin e configurazioni;
• creare account WordPress con privilegi amministrativi;
• leggere credenziali e dati presenti nel database;
• alterare o cancellare contenuti;
• mantenere un accesso persistente al server;
• compromettere altri siti ospitati nello stesso ambiente, se l’isolamento è insufficiente.

L’aggiornamento del plugin chiude la vulnerabilità, ma non elimina file già caricati o account creati dall’aggressore. Per i siti rimasti esposti durante le campagne, la patch deve quindi essere accompagnata da una verifica retrospettiva.

Nelle schede NVD disponibili non risulta indicata l’inclusione di CVE-2026-14894 o CVE-2026-32475 nel catalogo CISA Known Exploited Vulnerabilities. Non è pertanto possibile indicare una data di inserimento o una scadenza CISA. Non sono noti neppure elementi sufficienti per collegare questi episodi ad altri precedenti recenti dei due vendor nel KEV.

L’assenza di uno stato KEV noto non riduce però l’urgenza: lo sfruttamento è documentato direttamente attraverso centinaia di migliaia di richieste malevole.

Patch e controlli da eseguire subito

Chi gestisce installazioni WordPress deve aggiornare immediatamente:

• Super Forms alla versione 6.3.314 o successiva;
• Elementor Pro alla versione 4.2.2 o successiva.

Occorre controllare anche eventuali copie disattivate o obsolete dei plugin. Un componente non utilizzato ma ancora presente sul server può conservare codice vulnerabile e ampliare la superficie esposta.

Per Elementor Pro va ispezionata in particolare la directory:

/wp-content/uploads/elementor/forms/

Bisogna cercare file PHP inattesi, aggiunti o modificati di recente, senza limitarsi ai nomi conosciuti. Nel caso di Super Forms, i log HTTP devono essere esaminati per individuare richieste verso:

/wp-admin/admin-ajax.php

Tra gli indicatori più specifici figurano l’azione super_submit_form, il nome Mushr00w_upl.php, payload PHP codificati in Base64 e caricamenti dichiarati come image/gif ma salvati con estensione .php.

Gli amministratori dovrebbero inoltre controllare:

• nuovi account WordPress con privilegi elevati;
• modifiche non autorizzate a plugin, temi e file di configurazione;
• processi PHP o richieste anomale dirette alle cartelle di upload;
• connessioni in uscita insolite dal server;
• modifiche a credenziali, contenuti o impostazioni del sito.

Indirizzi IP osservati e risposta a un’eventuale compromissione

Tra le sorgenti associate agli attacchi contro Super Forms sono stati segnalati:

103.168.147.235
103.168.146.131
103.154.152.178
103.170.97.7
182.10.130.51
189.4.122.140
129.227.46.143
64.176.209.104
103.164.182.122
37.9.33.62

Per Elementor Pro sono stati osservati:

2602:fa59:10:7a1::1
185.196.220.85
103.84.230.85
103.90.148.202
216.126.225.208
167.254.240.75
167.254.241.119
114.10.17.253
114.10.45.151
2406:ef80:2:7d19::1

Questi indirizzi possono essere bloccati o sottoposti a monitoraggio, ma non devono diventare l’unico criterio di rilevamento. Le infrastrutture possono cambiare, essere condivise oppure risultare compromesse a loro volta.

Se emergono segnali di intrusione, occorre rimuovere le web shell, ripristinare i file da copie affidabili e ruotare le credenziali di WordPress, hosting, FTP/SFTP, database e API. La sola cancellazione del payload visibile non garantisce la bonifica: l’aggressore potrebbe avere predisposto altri meccanismi di persistenza.