La vulnerabilita’ Gravity SMTP CVE-2026-4020 ha generato in poche settimane oltre diciassette milioni di tentativi di exploit registrati dai principali firewall WordPress, con un picco di quattro milioni di richieste bloccate in una sola giornata il 7 giugno. La falla, presente nel plugin Gravity SMTP usato da decine di migliaia di siti, permette a chiunque su internet di scaricare in un’unica richiesta HTTP circa 365 kilobyte di configurazione interna, comprese chiavi API e token OAuth attivi verso Amazon SES, Google Workspace, Mailjet, Resend e Zoho. Per chi gestisce siti WordPress non e’ uno dei soliti avvisi da archiviare: e’ una falla critica che espone credenziali realmente operative, e che va affrontata oggi.
Cosa e’ successo e perche’ la falla e’ grave
Il Gravity SMTP e’ un add-on del piu’ noto Gravity Forms che instrada le email transazionali del sito attraverso provider professionali come Amazon SES e Mailjet, evitando le consegne via PHP mail e migliorando recapito e tracciamento. E’ un plugin diffuso su circa centomila installazioni, tipicamente in setup dove le email aziendali, le notifiche d’ordine WooCommerce, i moduli di richiesta preventivo e le ricevute fiscali transitano attraverso un servizio SMTP esterno. La vulnerabilita’ CVE-2026-4020 ha ribaltato proprio questa promessa di affidabilita’: un endpoint REST non protetto consentiva di leggere il blob di configurazione del plugin, inclusi i campi marcati come “sensitive” che custodivano chiavi API in chiaro e token OAuth gia’ scambiati con i provider esterni.
Il problema non e’ un crash, non e’ un defacement, non e’ un ransomware visibile in homepage. E’ una fuoriuscita silenziosa di credenziali. Una volta esfiltrate, le chiavi possono essere usate per inviare email autenticate a nome del dominio, oppure per consumare quote SES e Mailjet a spese del legittimo proprietario, o ancora per inserirsi nei flussi OAuth e raggiungere caselle Gmail e Workspace collegate. Sui forum di sicurezza sono apparsi report di siti i cui domini sono finiti in blacklist nel giro di poche ore dopo l’exploit, perche’ usati per ondate di phishing partite da SES con la reputazione del cliente legittimo. Il danno reputazionale e di deliverability supera, in molti casi, il costo immediato di un incidente.
I dati di telemetria che hanno alimentato il bollettino raccontano una pressione costante e crescente: dalla prima meta’ di maggio 2026 fino alla seconda settimana di giugno gli scanner automatizzati hanno percorso l’intero IPv4 in cerca di installazioni vulnerabili, con un picco il 7 giugno e ondate ricorrenti la mattina ad orari europei. Questo significa che nessun sito e’ nascosto: anche un piccolo gestionale interno o un blog dimenticato di un cliente storico viene comunque toccato dagli scanner. La domanda non e’ se sei stato testato, ma se hai aggiornato in tempo.
Come funziona tecnicamente l’exploit
Il vettore e’ una richiesta HTTP non autenticata diretta a un endpoint REST registrato dal plugin per ottenere lo stato della configurazione lato amministratore. Nelle versioni vulnerabili manca un controllo di capability adeguato, e l’endpoint risponde a chiunque, restituendo l’intera struttura interna con i campi che dovrebbero essere visibili solo agli admin loggati. Il payload pesa intorno ai 365 kilobyte e include, tra le altre cose, l’oggetto “providers” con le credenziali attive: access key e secret di Amazon SES, token Mailjet, API key Resend, token OAuth gia’ rinnovati di account Google connessi tramite la console del plugin.
Una volta in possesso di queste chiavi, l’attaccante non ha bisogno di tornare sul sito vittima. Le credenziali funzionano direttamente verso le API di Amazon, Mailjet o Google, e l’attacco prosegue su infrastrutture esterne. Questo rende molto difficile la rilevazione lato vittima: nei log del sito si vede solo una richiesta REST riuscita, magari da un IP residenziale di un cloud asiatico, e nulla di anomalo per ore. La vittima si accorge spesso del problema solo quando il provider SES sospende l’account per abuse report, o quando il dominio finisce nelle blacklist di Spamhaus e SORBS dopo essere stato usato per spedire campagne di phishing.
Per dare un’idea del meccanismo: la stessa logica della falla la abbiamo gia’ vista in vulnerabilita’ simili su altri plugin che gestivano credenziali esterne. Il copione e’ sempre lo stesso: un endpoint REST creato per comodita’ degli sviluppatori, mai messo dietro una verifica adeguata, che ritorna piu’ dati di quanti ne dovrebbe. Quello che cambia, in questo caso, e’ la natura delle credenziali esposte: non password hashate o nonce, ma chiavi gia’ valide presso terzi, immediatamente utilizzabili senza bisogno di crackarle.
Chi e’ esposto e cosa significa per agenzie e PMI italiane
L’installazione di Gravity SMTP e’ tipica di tre profili. Il primo sono le PMI che vendono online con WooCommerce e instradano fatture, conferme d’ordine e ricevute di pagamento attraverso Amazon SES o Mailjet per garantire un recapito sopra il 95%. Una piccola ferramenta di Bergamo che vende ricambi industriali e una boutique di Torino che lavora dropshipping con la Francia hanno spesso lo stesso identico setup. Il secondo sono le agenzie che gestiscono portafogli di clienti in cui il plugin viene installato di default come standard interno, quindi una singola configurazione errata si moltiplica su decine di siti. Il terzo sono i siti vetrina con form di contatto e preventivo dove le email partono comunque tramite SMTP esterno per evitare lo spam.
Per chi gestisce un’agenzia, l’impatto operativo va oltre il singolo cliente: significa dover capire, oggi pomeriggio, su quanti siti del proprio portafoglio e’ installato il plugin, in che versione, e se la chiave API esposta e’ anche la stessa usata su altri progetti. Capita spesso che un’unica chiave SES sia condivisa tra piu’ clienti per comodita’: in quel caso la compromissione di un sito espone tutti gli altri. E’ il momento di fare un inventario serio, non un controllo a campione. Una PMI di Como che gestisce internamente il sito e’ esposta in modo diverso ma non meno serio: spesso non ha un firewall WordPress, non legge i bollettini di sicurezza, e si accorgera’ del problema solo quando le email di conferma ordine smetteranno di arrivare ai clienti.
Da un punto di vista normativo, va ricordato che un’esfiltrazione di chiavi API che permette l’accesso a sistemi di posta e potenzialmente a metadati dei destinatari delle email puo’ configurare un data breach ai sensi del GDPR. Anche se i dati personali non vengono direttamente esposti, l’accesso non autorizzato a un sistema che li tratta resta una violazione notificabile entro 72 ore. Le agenzie che gestiscono il sito per conto del cliente sono, nella catena di responsabilita’, responsabili del trattamento e quindi corresponsabili nella valutazione e nella notifica. Questo aggiunge urgenza all’azione tecnica.
Cosa fare subito sul tuo sito o sul portafoglio clienti
La prima azione e’ l’aggiornamento del plugin alla versione patchata rilasciata dal vendor nella seconda settimana di giugno. Aggiornare non e’ opzionale, e non basta da solo: se il sito e’ rimasto vulnerabile anche solo poche ore tra fine maggio e meta’ giugno, e’ realistico che le chiavi siano gia’ state esfiltrate, e una semplice patch non risolve il furto gia’ avvenuto. Va quindi seguita la procedura di rotazione completa delle credenziali, che e’ la parte piu’ importante e piu’ spesso saltata. Dopo l’update, si entra nella console del provider SMTP usato (SES, Mailjet, Resend, Zoho) e si revocano e ricreano tutte le chiavi che il plugin aveva memorizzato. Le nuove chiavi vanno reinserite nel sito solo dopo aver verificato l’integrita’ del plugin.
In parallelo, conviene leggere i log degli ultimi trenta giorni per cercare richieste sospette verso gli endpoint REST del plugin. Anche senza un SIEM, un grep sui log nginx o Apache contro pattern come “/wp-json/gravity-smtp” o nomi di endpoint del plugin restituisce in pochi secondi un elenco di IP che hanno toccato l’area incriminata. Se ci sono IP esterni a quelli amministrativi noti, la presunzione di compromissione e’ altissima. A quel punto serve allargare l’analisi: verificare le metriche di invio del provider, cercare email partite a orari anomali, controllare se sono comparsi nuovi mittenti autorizzati, e parlare con il cliente prima che parli con un suo destinatario arrabbiato.
Una serie di azioni concrete che proponiamo come checklist operativa per il portafoglio:
- Censire i siti con Gravity SMTP attivo, includendo le installazioni dormienti e i siti di staging che condividono chiavi col produzione.
- Aggiornare immediatamente alla versione corrente del plugin e validare l’aggiornamento da front-end e back-end.
- Rotare in console provider tutte le chiavi API e i token OAuth presenti, anche se l’aggiornamento sembra essere stato applicato prima dell’inizio degli attacchi.
- Attivare un firewall WordPress (Wordfence, Patchstack o equivalente) almeno in modalita’ monitoraggio sui siti che ne erano sprovvisti.
- Notificare al cliente in italiano semplice cosa e’ successo, cosa hai fatto e cosa puo’ verificare lui stesso, senza nascondere il rischio ma senza nemmeno terrorizzarlo.
Prospettive: cosa cambia nella sicurezza WordPress dopo questo episodio
L’episodio Gravity SMTP non e’ un caso isolato. Negli ultimi diciotto mesi i bollettini di sicurezza WordPress hanno raccontato una tendenza coerente: i plugin che gestiscono credenziali verso servizi esterni (SMTP, social, pagamenti, marketing automation) sono diventati il bersaglio numero uno, perche’ rappresentano scorciatoie verso infrastrutture cloud che valgono molto di piu’ del singolo sito vittima. E’ un cambio strategico per chi attacca: invece di cercare zero-day complessi che danno accesso al server, si caccia il singolo endpoint dimenticato che restituisce una chiave AWS gia’ valida. Il ROI per l’attaccante e’ eccellente.
Per chi sviluppa o sceglie plugin, questo si traduce in un criterio di selezione piu’ severo: non basta piu’ il numero di installazioni o le recensioni a quattro stelle, conta come il plugin gestisce la persistenza dei segreti, se li cifra a riposo, se espone endpoint REST e con quali capability. E’ un livello di analisi che fino a poco tempo fa era riservato a contesti enterprise, e che oggi qualunque agenzia che gestisca portafogli di una certa dimensione deve incorporare nel processo di onboarding di un plugin. Anche un’analisi rapida del repository ufficiale e degli ultimi sei mesi di changelog dice molto: vendor che chiudono CVE con trasparenza e tempi rapidi sono partner affidabili, vendor che minimizzano sono campanelli d’allarme.
L’altra prospettiva e’ quella delle assicurazioni cyber, che in Italia stanno entrando anche nel segmento PMI con prodotti specifici. Un incidente come Gravity SMTP, se sfocia in un data breach notificato, puo’ attivare clausole di rimborso ma anche di rivalsa, e le compagnie chiedono evidenza delle misure di sicurezza in essere. Avere un registro degli aggiornamenti, un firewall attivo, un piano di rotazione delle chiavi e una documentazione delle responsabilita’ tra agenzia e cliente non e’ piu’ un nice-to-have: sara’ richiesto in fase di sottoscrizione e usato in fase di liquidazione.
Cosa significa per la tua agenzia o PMI
In pratica, da oggi al weekend, ecco le azioni concrete da pianificare nel tuo workflow di agenzia o nel tuo team interno IT:
- Apri un foglio condiviso con la lista dei siti che gestisci, identifica quelli con Gravity SMTP attivo e segna la versione installata.
- Pianifica una finestra di intervento entro 48 ore: aggiornamento del plugin, rotazione delle chiavi sul provider, test di invio email post-rotazione.
- Imposta un alert continuo (anche solo via email) sui bollettini Patchstack e WPScan, e includilo nel rituale settimanale del team tecnico.
- Aggiungi al contratto di manutenzione una clausola che descriva la procedura di risposta agli incidenti, i tempi di intervento e le responsabilita’ di notifica.
- Comunica al cliente in modo proattivo l’aggiornamento eseguito: la fiducia si guadagna piu’ nei post-mortem ben gestiti che nei mesi in cui non succede nulla.
Fonte originale dell’analisi tecnica e dati di telemetria: The Next Web – Gravity SMTP CVE-2026-4020 e SecurityWeek.
