Brevo, la piattaforma francese di email marketing conosciuta fino a poco tempo fa come Sendinblue, ha vissuto la settimana peggiore della sua storia recente. Tra il 10 e il 14 settembre 2026 l’azienda ha subito due attacchi distinti nel giro di quattro giorni: prima una falla nella gestione del protocollo SAML SSO ha esposto 138 account clienti, poi una chiave API di Cloudflare rubata ha permesso a un aggressore di riscrivere il codice JavaScript caricato da oltre 100.000 siti web in tutto il mondo. Per le aziende italiane ed europee che si appoggiano a Brevo per moduli di iscrizione, chat dal vivo e automazioni di marketing, l’episodio è un promemoria diretto: la sicurezza del proprio sito dipende anche da fornitori che nessuno controlla in prima persona.
Cos’è successo: l’attacco in breve
Il 14 settembre 2026 un aggressore ha usato una chiave API di Cloudflare rubata, con permessi completi sull’account e memorizzata nel codice sorgente dell’applicazione, per creare un Cloudflare Worker malevolo all’interno dell’infrastruttura di Brevo. Per circa cinque ore e mezza il Worker ha riscritto le risposte servite ai visitatori di brevo.com, sibforms.com e di tre file JavaScript che i clienti dell’azienda incorporano direttamente nei propri siti, secondo il post-mortem ufficiale pubblicato da Brevo. Il codice iniettato mostrava ai visitatori un falso controllo “verifica di essere umano” in stile Cloudflare, tecnica nota come ClickFix, che induce la vittima a incollare ed eseguire un comando nel proprio sistema operativo.
Quell’attacco non è arrivato da solo. Quattro giorni prima, il 10 settembre, un altro aggressore aveva già sfruttato una falla nella gestione SAML SSO di Brevo per accedere a 138 account clienti, tra cui quello del produttore di portafogli hardware per criptovalute Trezor. Due violazioni distinte, nella stessa settimana, sullo stesso fornitore: un caso che gli analisti di sicurezza stanno già citando come esempio da manuale di quanto possa diventare fragile la catena di fiducia tra un’azienda e i suoi fornitori cloud.
Cronologia dettagliata: dal 10 al 25 settembre 2026
Ricostruire la sequenza esatta aiuta a capire come due incidenti separati abbiano finito per amplificarsi a vicenda, minando la fiducia dei clienti proprio mentre l’azienda cercava di gestire la prima crisi.
| Data | Evento |
|---|---|
| 10 settembre 2026, ore 06:30 UTC | Un aggressore sfrutta una falla nella gestione SAML SSO e ottiene accesso a 138 account Brevo |
| 10 settembre 2026, ore 08:30 UTC | Brevo chiude l’accesso non autorizzato, disconnette gli utenti attivi e resetta le sessioni |
| 10-14 settembre 2026 | Sei account vengono usati per inviare phishing ai contatti salvati, 43 subiscono l’esportazione della lista contatti |
| 14 settembre 2026 | Un aggressore usa una chiave API Cloudflare rubata per creare un Worker malevolo sull’account Brevo |
| 14 settembre 2026, per circa 5 ore e mezza | Il Worker riscrive le pagine di brevo.com, sibforms.com e tre script JavaScript incorporati dai clienti |
| 16 settembre 2026 | La società di ricerca Rescana pubblica la prima analisi indipendente dell’incidente Cloudflare |
| 17 settembre 2026 | Brevo pubblica il post-mortem ufficiale sull’attacco alla chiave API |
| 18-25 settembre 2026 | Trezor conferma che circa 347.000 utenti hanno ricevuto email di phishing legate alla prima violazione |
Chi è Brevo e perché l’incidente riguarda anche l’Italia
Brevo, rinominata così nel 2023 dopo essere stata nota per anni come Sendinblue, è una piattaforma francese che unisce email marketing, SMS, automazione, CRM e widget di chat per siti web. Il modello di distribuzione è quello tipico del software as a service: le aziende clienti non installano nulla, incorporano semplicemente uno script JavaScript fornito da Brevo nelle proprie pagine per gestire moduli di iscrizione, popup e conversazioni con i visitatori. È proprio questo meccanismo, comodo per chi lo usa, ad aver trasformato un singolo account Cloudflare compromesso in un vettore capace di raggiungere oltre 100.000 domini diversi in un colpo solo.
Per le piccole e medie imprese italiane, che spesso scelgono piattaforme di marketing automation proprio per evitare di gestire infrastrutture proprie, l’episodio mette in luce un rischio poco discusso nelle valutazioni di sicurezza standard: un fornitore SaaS può diventare il punto debole anche quando il sito dell’azienda cliente non ha mai subito una violazione diretta. Chi incorpora script di terze parti eredita, di fatto, anche i loro incidenti.
La prima violazione: la falla SAML SSO e i 138 account
Il primo incidente, reso noto da Brevo nel proprio status page ufficiale, ha coinvolto una debolezza nel modo in cui la piattaforma gestiva l’autenticazione Single Sign-On basata su SAML. Alle 06:30 UTC del 10 settembre un aggressore ha sfruttato questa falla per accedere a 138 account clienti. Di questi, sei sono stati usati per inviare email di phishing direttamente ai contatti salvati al loro interno, sfruttando così l’infrastruttura legittima e affidabile di Brevo per superare i filtri antispam. Altri 43 account hanno subito l’esportazione completa della lista contatti, mentre i restanti 93 non hanno mostrato attività sospette oltre all’accesso.
Tra le vittime più note figura Trezor, produttore ceco di portafogli hardware per criptovalute, il cui account rientrava tra i 138 compromessi. Secondo quanto riportato da SecurityWeek, circa 347.000 utenti Trezor hanno ricevuto email di phishing a seguito di questa fuga di dati, un numero che mostra quanto possa espandersi rapidamente il danno quando il bersaglio non è l’utente finale ma il fornitore che gestisce le comunicazioni per suo conto. Brevo ha dichiarato di aver chiuso l’accesso non autorizzato entro le 08:30 UTC dello stesso giorno, circa due ore dopo il rilevamento.
La seconda violazione: la chiave Cloudflare rubata
Appena quattro giorni dopo aver chiuso il primo incidente, Brevo ne ha dovuto affrontare un secondo, di portata molto più ampia. Il 14 settembre un aggressore ha ottenuto una chiave API di Cloudflare con permessi completi sull’account, una chiave a lunga durata che, secondo quanto ammesso dalla stessa azienda, era rimasta memorizzata nel codice sorgente dell’applicazione invece che in un sistema dedicato alla gestione dei segreti. Con quella chiave l’aggressore ha potuto creare Worker, route e record DNS su tutte le zone Cloudflare controllate da Brevo, inclusi i domini brevo.com, sendinblue.com e sibforms.com, che secondo alcune analisi indipendenti risolvevano tutti attraverso lo stesso account Cloudflare, ampliando così il raggio d’azione di un’unica credenziale rubata.
Come ha spiegato Brevo, “una chiave API di Cloudflare a lunga durata con permessi completi sull’account era memorizzata nel codice sorgente dell’applicazione ed è stata ottenuta dall’aggressore” (Brevo, citata da BleepingComputer). La società di ricerca indipendente Rescana ha confermato la dinamica dell’attacco: “Il 14 settembre 2026, Brevo (già Sendinblue) è stata colpita da una compromissione della supply chain a livello di edge CDN” (Rescana).
Cos’è il ClickFix e perché funziona ancora nel 2026
ClickFix non è un malware in senso stretto, ma una tecnica di ingegneria sociale che ha guadagnato terreno negli ultimi due anni proprio perché aggira i controlli tecnici tradizionali. Invece di sfruttare una vulnerabilità del browser, convince la vittima a eseguire di persona il codice dannoso.
Come funziona il trucco del falso controllo di verifica
La pagina compromessa mostra un banner che imita una verifica di sicurezza legittima, spesso in stile Cloudflare, chiedendo all’utente di dimostrare di non essere un bot. Il banner chiede poi di aprire la finestra Esegui di Windows, PowerShell o il Prompt dei comandi, incollare una stringa già copiata negli appunti ed eseguirla. In quel momento è la vittima stessa, non un exploit del browser, a lanciare il payload malevolo sul proprio computer.
Perché inganna anche utenti esperti
Il trucco funziona perché sfrutta un riflesso ormai automatico: milioni di persone incontrano ogni giorno controlli CAPTCHA o verifiche “sei umano” e li completano senza pensarci troppo. Quando la richiesta arriva da un dominio legittimo come brevo.com, riconosciuto e caricato in migliaia di siti diversi, il livello di sospetto scende ulteriormente. Alcuni report indicano che, oltre al lure principale rivolto ai visitatori, il codice iniettato tentava anche di installare un plugin WordPress malevolo quando rilevava una sessione amministrativa attiva, un dettaglio che avrebbe potuto trasformare una compromissione lato visitatore in una compromissione diretta del sito stesso.
La scala del danno: oltre 100.000 siti coinvolti
Le stime più citate parlano di oltre 100.000 siti web che incorporavano gli script Brevo modificati durante la finestra di attacco, secondo l’Ufficio federale svizzero per la cibersicurezza, che ha confermato: “Oltre 100.000 siti web in tutto il mondo sono già stati colpiti”. È importante distinguere due livelli di impatto, spesso confusi nella copertura mediatica dei giorni successivi: il numero di siti che caricavano codice compromesso non coincide con il numero di visitatori che hanno effettivamente eseguito il comando dannoso proposto dalla schermata ClickFix. Il primo dato misura l’esposizione potenziale, il secondo misura il danno reale, e le fonti coinvolte non hanno ancora pubblicato una stima verificata di quest’ultimo.
Resta comunque significativo che, per riscrivere codice destinato a decine di migliaia di domini indipendenti tra loro, l’aggressore non abbia dovuto violare nemmeno uno di quei siti. Gli script di Brevo per moduli, chat e tracciamento vengono richiamati direttamente dal dominio dell’azienda, quindi modificare il file alla fonte è bastato a propagare il contenuto malevolo a chiunque continuasse a richiamare quella versione.
Come Brevo ha risposto: il post-mortem e le contromisure
Brevo ha pubblicato il proprio resoconto ufficiale il 17 settembre, tre giorni dopo l’inizio dell’attacco alla chiave Cloudflare. Nel documento l’azienda ha ammesso esplicitamente la causa tecnica dell’incidente e ha spiegato perché sia risultato difficile da individuare in tempo reale: “Poiché il Worker riscriveva le risposte al margine della rete e rimuoveva intestazioni di sicurezza come la Content-Security-Policy, i nostri server di origine e i file rimanevano invariati, e i controlli di integrità standard non hanno rilevato la modifica” (Brevo).
Questo passaggio è cruciale per capire la natura dell’attacco: chi avesse controllato i file effettivamente ospitati sui server d’origine di Brevo non avrebbe trovato nulla di sospetto, perché la modifica avveniva a livello di Cloudflare Worker, cioè nel punto in cui il traffico viene servito ai visitatori finali. Un controllo di integrità basato solo sul codice sorgente, senza monitorare cosa viene effettivamente consegnato al browser, non avrebbe potuto rilevare la manomissione.
Perché il codice sorgente ha tradito Brevo
La causa radice individuata da Brevo è semplice da descrivere e comune a moltissime organizzazioni: una credenziale con privilegi troppo ampi, senza scadenza, salvata dove chiunque avesse accesso al repository poteva leggerla. L’anti-pattern e la pratica consigliata si possono riassumere così.
// Anti-pattern individuato nell'incidente Brevo
const cloudflareApiKey = "cf_key_a1b2c3d4e5f6...";
// chiave a permessi pieni, senza scadenza, nel codice versionato
// Pratica consigliata
const cloudflareApiKey = process.env.CF_API_TOKEN;
// token con scope limitato a una sola zona, rotazione programmata,
// caricato da un secret manager e mai committato nel repositoryNon esiste, al momento, un CVE assegnato a questo incidente, perché non è stata sfruttata una vulnerabilità software in senso classico. L’aggressore ha usato una credenziale legittima ma rubata, un dettaglio che colloca il caso Brevo più vicino agli incidenti di gestione dei segreti che a un tradizionale zero-day.
Confronto storico: da polyfill.io a Brevo
L’incidente Brevo si inserisce in una linea di attacchi alla supply chain del software che negli ultimi due anni ha colpito ripetutamente l’ecosistema JavaScript e le sue dipendenze condivise. Il caso più simile per struttura resta polyfill.io, il dominio CDN ampiamente incorporato da siti di tutto il mondo che, dopo un cambio di proprietà, ha iniziato a servire reindirizzamenti malevoli agli utenti mobile. In entrambi i casi il meccanismo è lo stesso: i siti si fidano di uno script ospitato altrove, e compromettere il punto di distribuzione basta a raggiungere ogni sito che lo richiama, senza dover violare nessuno di essi singolarmente.
| Incidente | Periodo | Vettore d’attacco | Portata stimata |
|---|---|---|---|
| Polyfill.io | 2024, con effetti ancora segnalati nel 2025 | Dominio CDN riacquistato e usato per servire redirect malevoli | Centinaia di migliaia di siti che richiamavano lo script |
| Attacco a crates.io | 2026 | Pacchetto Rust compromesso nella catena delle dipendenze | 244 milioni di download coinvolti |
| Ecosistema npm | 2025-2026, ricorrente | Pacchetti compromessi distribuiti tramite il registry | Sviluppatori e pipeline CI/CD a valle |
| Brevo | 14 settembre 2026 | Chiave API Cloudflare rubata, Worker malevolo lato edge | Oltre 100.000 siti che incorporano gli script Brevo |
Rispetto all’attacco a crates.io, che ha colpito la catena di dipendenze lato sviluppatore, il caso Brevo ha raggiunto direttamente gli utenti finali nel browser, senza passare da una build o da una pipeline CI/CD. È un vettore più vicino, per certi versi, a quanto già visto con la fuga di chiavi AWS da repository Git esposti, dove ancora una volta una singola credenziale mal gestita ha aperto la porta a un impatto molto più ampio del previsto.
Impatto sul mercato: fiducia, email marketing e concorrenza
Nel settore dell’email marketing e dell’automazione, la fiducia è l’unico vero prodotto in vendita: le aziende affidano a piattaforme come Brevo le liste contatti, le comunicazioni con i clienti e, sempre più spesso, anche l’aspetto pubblico del proprio sito attraverso moduli e widget. Una doppia violazione nel giro di una settimana mette sotto pressione proprio quella fiducia, indipendentemente dalla rapidità della risposta tecnica. Le aziende che valutano fornitori di marketing automation, in Italia come nel resto d’Europa, stanno già iniziando a chiedere dettagli più specifici su rotazione delle chiavi API, segregazione degli account cloud e monitoraggio dell’integrità degli script pubblicati, requisiti che fino a poco tempo fa raramente comparivano nei questionari di due diligence dei fornitori SaaS.
L’episodio arriva anche in un momento in cui il mercato dell’email marketing e della marketing automation resta uno dei segmenti più competitivi del software B2B europeo, con diversi fornitori che puntano proprio sulla sicurezza e sulla trasparenza degli incidenti come leva differenziante rispetto ai concorrenti. Un doppio incidente pubblico, seguito da un post-mortem dettagliato ma comunque arrivato dopo la scoperta di ricercatori indipendenti, pesa nella percezione di chi deve scegliere a chi affidare le proprie comunicazioni. Per chi gestisce anche il livello DNS delle proprie applicazioni, l’episodio riporta l’attenzione su quanto conti la configurazione di base dei resolver e dei servizi DNS usati in produzione.
Cosa possono fare aziende e sviluppatori italiani per proteggersi
L’incidente Brevo offre indicazioni pratiche precise, applicabili sia da chi gestisce infrastrutture cloud sia da chi si limita a incorporare script di terze parti sul proprio sito.
Per chi gestisce le chiavi API
- Usare token con permessi limitati a una singola zona o risorsa, mai chiavi con accesso completo all’account
- Impostare una scadenza breve e una rotazione automatica delle credenziali, invece di chiavi valide a tempo indeterminato
- Adottare strumenti di secret scanning nel repository e nella pipeline CI/CD per intercettare credenziali dimenticate nel codice, come descritto anche nella guida a npm Provenance con Sigstore
- Separare gli account Cloudflare, o le zone DNS, per ridurre il raggio d’azione di un’eventuale credenziale rubata
Per chi incorpora script di terze parti
- Valutare l’uso di Subresource Integrity (SRI) sugli script esterni, quando il fornitore lo consente, per bloccare versioni modificate
- Applicare una Content Security Policy che limiti i domini da cui il browser può caricare script eseguibili
- Monitorare periodicamente il contenuto effettivo degli script esterni caricati in produzione, non solo il codice del proprio sito
- Formare gli amministratori a riconoscere le schermate di verifica false, in particolare quelle che chiedono di incollare comandi in un terminale
Il contesto europeo: fornitori digitali e responsabilità condivisa
L’incidente Brevo si inserisce in un perimetro normativo europeo che negli ultimi anni ha progressivamente allargato gli obblighi di sicurezza anche ai fornitori di servizi digitali usati a cascata dalle aziende, e non solo alle grandi infrastrutture critiche. La direttiva NIS2 e il regolamento GDPR impongono già oggi, a chi tratta dati personali attraverso un fornitore terzo, di valutare i rischi introdotti da quel fornitore come parte della propria superficie di attacco. Un episodio come quello di Brevo, che coinvolge sia l’esportazione di contatti sia l’iniezione di codice su siti terzi, tocca entrambi i fronti normativi contemporaneamente: la protezione dei dati personali e la sicurezza dei servizi digitali erogati a valle.
Non risulta, al momento della pubblicazione, una dichiarazione formale delle autorità italiane o europee specifica su questo caso, ma la vicenda rientra pienamente nel tipo di scenario che le ispezioni previste dal recepimento NIS2 in Italia stanno iniziando a considerare: non più solo la sicurezza diretta di un’azienda, ma anche la solidità della catena di fornitori digitali da cui dipende.
Previsioni: cosa aspettarsi nei prossimi mesi
Sulla base della dinamica dell’incidente e delle tendenze già in atto nel settore della sicurezza della supply chain, ci sono alcuni sviluppi plausibili nei prossimi mesi.
- La rotazione automatica delle chiavi API e il secret scanning diventeranno requisiti contrattuali standard nei rapporti tra aziende europee e fornitori SaaS di marketing e CRM
- Più fornitori adotteranno la segregazione degli account Cloudflare o CDN per singolo servizio, per limitare il raggio d’azione di future credenziali rubate
- Cresceranno le richieste di trasparenza sugli incidenti, con clienti che pretenderanno tempi di disclosure più rapidi rispetto ai tre giorni impiegati da Brevo per il secondo post-mortem
- Altri fornitori di widget e script embeddable, non solo nel settore email marketing, verranno sottoposti a controlli di sicurezza più approfonditi da parte dei clienti aziendali
- La tecnica ClickFix continuerà a comparire in nuove campagne, spostandosi progressivamente da siti compromessi singolarmente a fornitori centralizzati con grande base di script incorporati
Nessuna di queste previsioni è certa, ma tutte derivano da pattern già osservati in incidenti precedenti come quello di polyfill.io, dove la pressione del mercato ha finito per spingere sviluppatori e aziende verso pratiche più rigorose di gestione degli script di terze parti.
Domande frequenti
Cos’è successo esattamente a Brevo?
Tra il 10 e il 14 settembre 2026 Brevo ha subito due attacchi distinti: una violazione di 138 account tramite una falla SAML SSO, e successivamente il furto di una chiave API Cloudflare usata per iniettare codice ClickFix in script caricati da oltre 100.000 siti.
Chi è stato colpito dalla violazione SAML SSO?
Sono stati compromessi 138 account clienti Brevo, tra cui quello di Trezor. Sei account sono stati usati per inviare phishing, 43 hanno subito l’esportazione dei contatti, e circa 347.000 utenti Trezor hanno ricevuto email di phishing come conseguenza.
Cos’è il ClickFix e come funziona?
ClickFix è una tecnica di ingegneria sociale che mostra un falso controllo di verifica e induce la vittima a incollare ed eseguire manualmente un comando dannoso tramite la finestra Esegui di Windows o un terminale, aggirando così i controlli tecnici del browser.
Quanti siti web sono stati coinvolti dall’attacco alla chiave Cloudflare?
Secondo le stime riportate da più fonti, tra cui l’Ufficio federale svizzero per la cibersicurezza, oltre 100.000 siti caricavano gli script Brevo modificati durante la finestra di attacco di circa cinque ore e mezza.
È stato assegnato un CVE a questo incidente?
No. L’attacco non ha sfruttato una vulnerabilità software tradizionale, ma l’uso di una credenziale legittima rubata, quindi viene classificato come incidente di gestione dei segreti e sicurezza della supply chain, non come una falla con identificativo CVE.
Il mio sito è a rischio se uso Brevo?
La finestra di attacco attiva si è chiusa il 14 settembre 2026 e Brevo ha dichiarato di aver revocato la chiave compromessa. Chi utilizza script Brevo dovrebbe comunque verificare i log di accesso del proprio sito nel periodo interessato e valutare l’adozione di Subresource Integrity per gli script esterni in futuro.
Come si può prevenire un attacco simile alla propria infrastruttura?
Evitando chiavi API a permessi pieni e senza scadenza, adottando secret scanning automatizzato, segmentando gli account cloud per servizio e monitorando il contenuto effettivo servito dagli script di terze parti, non solo il codice sorgente versionato.
Cosa ha fatto Brevo dopo aver scoperto l’attacco?
Brevo ha revocato la chiave Cloudflare compromessa, rimosso il Worker malevolo e pubblicato un post-mortem pubblico il 17 settembre 2026, spiegando la causa radice e i motivi per cui i controlli di integrità standard non avevano rilevato la modifica in tempo reale.
