Un attacco silenzioso sta colpendo in queste ore decine di migliaia di installazioni WordPress self-hosted. Il vettore è un plugin apparentemente innocuo, Gravity SMTP, usato per gestire l’invio di email tramite servizi esterni. La falla, attivamente sfruttata su larga scala, permette a un aggressore di ottenere API key, token OAuth e l’intera configurazione di sistema con una sola richiesta HTTP, senza bisogno di autenticazione.

I numeri messi insieme da Wordfence – la società di sicurezza controllata da Defiant – danno la misura del fenomeno: oltre 17 milioni di tentativi di exploit bloccati dall’inizio dell’ondata. Le stime parlano di più di 100.000 siti WordPress che montano il plugin potenzialmente vulnerabile, una superficie d’attacco enorme per un componente che, in molti casi, viene installato e dimenticato.

Cosa è in gioco: dalle email alle chiavi dell’infrastruttura

Il plugin Gravity SMTP centralizza l’invio di notifiche, email transazionali e messaggi di sistema attraverso provider esterni come Google Workspace, Mailgun o SendGrid. Per farlo conserva nelle proprie impostazioni le credenziali OAuth o le API key di questi servizi. Una volta esfiltrate, un attaccante non si limita a leggere la posta: può impersonare il dominio, lanciare campagne di phishing altamente credibili o, peggio ancora, usare quelle stesse chiavi per muoversi lateralmente verso altri servizi cloud collegati.

Per chi gestisce stack on-premise, il danno potenziale va oltre il singolo sito. In ambito enterprise, un server WordPress può fungere da interfaccia pubblica di applicazioni interne, inclusi cruscotti per modelli LLM autogestiti o piattaforme di ticketing. Se l’istanza condivide la rete con altri servizi, le credenziali trafugate diventano un trampolino per compromettere ambienti più critici.

La lezione per chi sceglie il self-hosting

Questa vicenda non è una semplice notizia di cronaca web. Fa riflettere su quanto sia sottile il confine tra un plugin laterale e la sicurezza complessiva di un’infrastruttura on-premise. Il paradigma self-hosted offre controllo diretto sui dati e sui flussi, ma delega a componenti terzi – temi, plugin, dipendenze – la gestione di funzioni spesso trascurate. L’aggiornamento costante e la verifica delle configurazioni diventano quindi prassi irrinunciabili, non accessori.

Basti pensare alle installazioni di WordPress che vengono usate come frontend leggero per sistemi di intelligenza artificiale locali: un avviso via email su un job di training terminato, una notifica di alert, una comunicazione automatica agli utenti. Un singolo plugin SMTP non curato può esporre le chiavi che tengono insieme l’intero stack di notifiche, con ricadute dirette su reputazione, operatività e costi.

Uno sguardo più ampio

Il mass-exploit su Gravity SMTP si inserisce in un framework già noto a chi opera su architetture self-hosted: l’aumento esponenziale degli attacchi automatizzati contro componenti open source e plugin di terze parti. Non è un caso isolato, ma il sintomo di una superficie d’attacco che cresce con l’aumento delle integrazioni. La risposta non sta soltanto nell’applicare patch, ma nel ridisegnare la postura di sicurezza intorno a ogni micro-componente, soprattutto quando gestisce credenziali.

Per chi valuta deployment on-premise, esistono trade-off chiari: da un lato il pieno controllo di dati e processi, dall’altro la responsabilità di mantenere aggiornato e monitorato ogni strato dello stack, compresi i plugin che sembrano innocui. La vicenda Gravity SMTP lo ricorda in modo fin troppo concreto.