Wordfence ha pubblicato in questi giorni due rapporti che, letti insieme, raccontano una sola storia: oltre 440.000 tentativi di exploit bloccati contro due falle critiche di plugin WordPress che permettono di caricare file PHP arbitrari e prendere il controllo del sito. Le vulnerabilità sono già corrette da settimane. Il problema è che moltissimi siti non hanno aggiornato.

Le due vulnerabilità

CVE-2026-14894 (CVSS 9.8) riguarda Super Forms – Drag & Drop Form Builder. È una mancata validazione del tipo di file che consente a un attaccante non autenticato di caricare qualunque file, compresi eseguibili PHP, ottenendo esecuzione di codice remota. Colpisce le versioni 6.3.313 e precedenti; la correzione è nella 6.3.314, rilasciata l'8 luglio 2026 e resa pubblica il giorno successivo.

CVE-2026-32475 (CVSS 9.0/9.8) riguarda Elementor Pro, uno dei page builder più diffusi al mondo. Anche qui si tratta di caricamento arbitrario di file non autenticato, dovuto a una validazione difettosa degli array di upload nei form. Sono interessate le versioni 4.2.1 e precedenti, corrette nella 4.2.2 del 19 agosto 2026. Lo sfruttamento richiede una condizione precisa: il sito deve avere almeno una pagina Elementor pubblicata contenente un widget Form con un campo di caricamento file.

Come funzionano gli attacchi osservati

Nel caso di Super Forms, gli attaccanti inviano una richiesta POST a /wp-admin/admin-ajax.php sull'endpoint super_submit_form, passando nel campo file una stringa datauristring con payload PHP codificato in Base64 e prefisso fasullo data:image/gif;base64. Il file che ne risulta è una webshell di upload chiamata Mushr00w_upl.php, che poi serve da testa di ponte per caricare payload successivi. L'attività è iniziata il 14 luglio 2026 — lo stesso giorno in cui Wordfence ha distribuito la regola di firewall ai clienti a pagamento — con un picco di oltre 40.000 richieste il 18 agosto.

Nel caso di Elementor Pro il trucco è diverso e più elegante: il campo di upload viene inviato come array in cui il primo elemento è vuoto e il secondo contiene il payload PHP con estensione .php. Questa struttura manda in tilt la validazione, che smette di controllare gli elementi successivi. Il file finisce in /wp-content/uploads/elementor/forms/ con nome casuale ma estensione scelta dall'attaccante, ed è poi richiamabile direttamente via HTTP. Gli attacchi sono partiti il 19 agosto, poche ore dopo la pubblicazione dei dettagli da parte di Patchstack.

Il conteggio è di circa 250.000 tentativi bloccati per Super Forms e 190.000 per Elementor Pro. Numeri di questa scala non sono opera di attacchi mirati: significano scansione automatizzata indiscriminata di tutta la rete.

Cosa significa per le aziende italiane

Qui il contesto italiano conta più che altrove, per una ragione strutturale: WordPress è la spina dorsale del web delle PMI italiane, ed Elementor è di gran lunga il page builder più usato da agenzie e freelance che realizzano quei siti. Il sito istituzionale, il portale di un comune, la vetrina dell'e-commerce, il modulo "contattaci" dello studio professionale: sono quasi tutti WordPress con Elementor sopra.

Il rischio concreto non è "il sito viene defacciato". Una webshell PHP su un sito aziendale significa tre cose molto peggiori.

Primo: i dati dei form. Il modulo contatti, la richiesta di preventivo, la candidatura di lavoro con CV allegato. Sono dati personali, spesso archiviati nel database WordPress o inviati per email. Una compromissione qui è un data breach a tutti gli effetti, con obbligo di valutazione e — se il rischio per gli interessati non è improbabile — notifica al Garante entro 72 ore ai sensi dell'art. 33 GDPR. Se tra i CV o i moduli ci sono categorie particolari di dati, la soglia si abbassa ulteriormente e può scattare anche la comunicazione agli interessati (art. 34).

Secondo: chi è il titolare del trattamento. Nella maggioranza dei casi il sito è stato realizzato e viene mantenuto da un'agenzia esterna. L'azienda resta titolare; l'agenzia è responsabile del trattamento ex art. 28 GDPR. Se il contratto non specifica chi aggiorna plugin e core, e con quale frequenza, in caso di incidente quella lacuna diventa un problema del titolare, non del fornitore. Ho visto più di un contratto di manutenzione che copre "aggiornamenti grafici e contenutistici" e tace completamente sulla sicurezza.

Terzo: il sito come trampolino. Un server compromesso viene usato per ospitare pagine di phishing, distribuire malware o inviare spam. Il danno reputazionale (dominio in blacklist, avvisi di Google Safe Browsing sul proprio sito) sopravvive a lungo alla bonifica tecnica.

Per i soggetti in perimetro NIS2, va ricordato che gli obblighi di gestione del rischio coprono l'intera superficie ICT, non solo i sistemi "importanti": un sito vetrina esposto su Internet e non aggiornato è precisamente il tipo di debolezza che un'autorità di vigilanza guarda per prima, perché è verificabile dall'esterno in trenta secondi.

Cosa fare subito

  • Aggiornare senza attendere: Super Forms alla 6.3.314 o superiore, Elementor Pro alla 4.2.2 o superiore. Sono correzioni disponibili rispettivamente da luglio e da agosto.
  • Verificare la compromissione, non solo la versione. Aggiornare oggi non rimuove una webshell caricata a luglio. Cercare file .php in /wp-content/uploads/ — directory in cui non dovrebbe esistere alcun PHP — e in particolare in /wp-content/uploads/elementor/forms/. Cercare esplicitamente Mushr00w_upl.php.
  • Bloccare l'esecuzione di PHP nelle directory di upload, con una direttiva del web server: su Apache un php_flag engine off in /wp-content/uploads/.htaccess, su nginx una location che nega \.php$ sotto /wp-content/uploads/. È una mitigazione strutturale che neutralizza l'intera classe di attacchi, non solo queste due CVE.
  • Controllare gli utenti amministratori creati di recente e le attività pianificate (cron di WordPress) anomale.
  • Verificare i log del web server a partire dal 14 luglio per Super Forms e dal 19 agosto per Elementor Pro, cercando POST verso admin-ajax.php con action=super_submit_form e richieste GET dirette a file PHP sotto /wp-content/uploads/.
  • Chiedere conto al fornitore: se il sito è gestito da un'agenzia, chiedere per iscritto quando sono stati applicati questi aggiornamenti e se è stata fatta una verifica di compromissione. La risposta scritta serve anche a documentare l'accountability lato titolare.

Il punto vero

Nessuna di queste due falle era uno zero-day. Entrambe erano corrette e documentate prima che iniziassero gli attacchi di massa. Quello che i 440.000 tentativi bloccati misurano non è la bravura degli attaccanti, ma la distanza fra il momento in cui una patch esiste e il momento in cui viene applicata — una distanza che, sul web italiano fatto di siti realizzati una volta e poi dimenticati, si misura in mesi.