Server MCP dannosi e sicurezza delle e-mail: la nuova minaccia alla catena di approvvigionamento
di
Ultimo aggiornamento:
9 Tempo di lettura: 9 min
I punti chiave da prendere in considerazione
- Gli hacker stanno utilizzando pacchetti npm creati tramite typosquatting per indurre gli sviluppatori a installare server MCP (Model Context Protocol) contraffatti.
- Questi server dannosi utilizzano chiavi API aziendali pre-autorizzate, inoltrando in modo invisibile dati sensibili in uscita a domini controllati dagli hacker.
- Poiché queste e-mail transitano attraverso la tua infrastruttura legittima, i filtri tradizionali come SPF e DKIM le lasciano passare automaticamente.
- Per colmare questa lacuna sono necessari un rigoroso controllo delle dipendenze delle applicazioni, un'applicazione delle API basata sul principio del privilegio minimo e un monitoraggio continuo dei volumi aggregati DMARC.
Nel settembre 2025, una singola riga di codice nascosto in una libreria npm open source ha mandato in frantumi le nostre convinzioni sulla sicurezza della catena di approvvigionamento. Ha portato alla ribalta la sicurezza delle e-mail dei server MCP come una nuova e pericolosa categoria di minacce.
Il pacchetto, denominato "postmark-mcp", ha trascorso più di una settimana inoltrando ogni giorno da 3.000 a 15.000 e-mail aziendali a un hacker. Non si è trattato di un exploit zero-day particolarmente sofisticato, ma semplicemente di una regola di base nascosta relativa alla copia nascosta (BCC), eseguita con pieni privilegi amministrativi. Le conseguenze sono state devastanti: sono trapelate password, fatture interne, dati dei clienti e token di autenticazione attivi.
Questo è il primo caso documentato di una violazione di un server MCP da parte di un agente malintenzionato in un ambiente reale. Man mano che gli agenti di intelligenza artificiale autonomi si diffondono nelle pipeline aziendali, stanno mettendo in luce un enorme punto cieco. Le difese tradizionali come SPF, DKIM e DMARC sono state progettate per un'era di instradamento della posta prevedibile e gestito dall'uomo. Il paradigma del Model Context Protocol (MCP) stravolge completamente tale approccio, introducendo un livello di minaccia interna che i tradizionali filtri perimetrali semplicemente non riescono a intercettare.
Cosa è successo – L'incidente del timbro postale mcp
Postmark (gestito da ActiveCampaign) è un noto servizio di posta elettronica transazionale utilizzato da migliaia di aziende per inviare notifiche automatiche fondamentali, come il ripristino delle password e le conferme d'ordine. Per sostenere il boom dell'IA generativa, è stato lanciato su GitHub un repository ufficiale open source che consente agli sviluppatori di collegare l'assistente IA Claude di Anthropic direttamente all'infrastruttura di Postmark tramite il Model Context Protocol.
Approfittando di una vulnerabilità, un malintenzionato ha pubblicato un pacchetto contraffatto chiamato postmark-mcp. Non si è trattato di un semplice errore di digitazione, bensì di una corrispondenza esatta del nome, pensata per ingannare gli sviluppatori che volevano eseguire rapidamente un'installazione tramite npm.
Una strategia a lungo termine: costruire la fiducia
L'autore dell'attacco ha messo in atto una strategia a lungo termine ben pianificata. Nel corso di quindici versioni consecutive (dalla 1.0.0 alla 1.0.15), il pacchetto ha funzionato senza intoppi. Riproduceva fedelmente il codice del repository ufficiale, eseguiva perfettamente le chiamate API e non generava alcun allarme. Ciò gli ha permesso di superare indenne i controlli automatici della sandbox e di guadagnarsi la fiducia iniziale dei sistemi di monitoraggio della sicurezza.
Attivazione del carico utile
Il 17 settembre 2025, con la versione 1.0.16, sono stati causati danni significativi. Nel profondo del file index.js, alla riga 231, lo sviluppatore ha aggiunto una riga di codice. Questa modifica ha aggiunto un indirizzo BCC nascosto a ogni singolo messaggio e-mail in transito sul server e ha reindirizzato le copie a un dominio controllato dall'autore dell'attacco [giftshop.club].
Poiché questo modulo era integrato nel livello applicativo convalidato, disponeva già di un accesso autorizzato alle chiavi API attive. L'attacco non ha richiesto alcuna escalation di privilegi complessa. Ha funzionato perché il codice era in esecuzione all'interno di una pipeline aziendale affidabile. La fuga di dati è proseguita fino al 25 settembre 2025, quando il motore di valutazione dei rischi di Koi Security ha segnalato modelli comportamentali anomali provenienti dalla libreria.
L'impatto
Le verifiche condotte a posteriori da Koi Security e Snyk hanno rivelato che il pacchetto ha totalizzato circa 1.643 download, il che si è tradotto in circa 1.500 installazioni attive a settimana che causavano una fuga di dati su base giornaliera.
Una volta scoperto il problema, l'editore ha rimosso il pacchetto da npm. Ma ecco il vero grattacapo: la rimozione di un pacchetto da un registro pubblico non comporta la sua eliminazione dagli ambienti attivi. Qualsiasi cluster cloud o pipeline di container attivo che utilizzava la versione 1.0.16 ha continuato a perdere dati fino a quando i team non l'hanno individuato e rimosso manualmente. Postmark ha rapidamente rilasciato una dichiarazione in cui chiariva di non aver sviluppato, autorizzato o gestito il pacchetto. Poiché si trattava di una backdoor comportamentale piuttosto che di un difetto del codice, non è stato assegnato alcun identificatore formale Common Vulnerabilities and Exposures, il che lascia dietro di sé un'impronta unica e non verificata di attacco alla catena di fornitura del server MCP.
Se pensate che il vostro team abbia mai utilizzato questo pacchetto, consideratelo un incidente in corso: disinstallatelo immediatamente da ogni ambiente, aggiornate tutte le credenziali e le chiavi API che sono mai passate attraverso di esso e controllate i log di posta alla ricerca di traffico in BCC diretto al dominio segnalato. Vale anche la pena controllare il resto dell'account dell'autore; lo stesso autore gestiva circa altri 31 pacchetti, ognuno dei quali potrebbe comportare lo stesso rischio.
Perché i server MCP rappresentano un obiettivo particolarmente appetibile per gli attacchi via e-mail?
Il Model Context Protocol (MCP) sta rapidamente diventando il framework di integrazione standard per l'intelligenza artificiale aziendale. Secondo le previsioni di Gartner, entro la fine del 2026 il 75% dei fornitori di gateway API avrà integrato suite di strumenti MCP native per gestire la sicurezza della posta elettronica basata sull'intelligenza artificiale agentica.
Che cos'è esattamente un'integrazione Model Context Protocol? Immaginate un server MCP come un ponte API sicuro che collega un assistente IA (come Claude) a archivi di dati esterni, ambienti di sviluppo e strumenti di terze parti. Anziché gestire una rete disordinata di API personalizzate, un agente IA utilizza questo protocollo unificato per interrogare database, consultare sistemi CRM o orchestrare autonomamente flussi di email.
La vulnerabilità fondamentale: la fiducia incondizionata
Per funzionare correttamente, un server MCP necessita di autorizzazioni operative estese e a lungo termine. Quando si collega un agente di intelligenza artificiale a un gateway di posta elettronica per automatizzare la pianificazione o l'assistenza clienti, gli si concede pieno accesso in lettura e scrittura. Esso agisce come un dipendente con pieni diritti di delega.
Come ha sottolineato Idan Dardikman, CTO di Koi Security, le organizzazioni stanno di fatto concedendo privilegi amministrativi illimitati a strumenti di backend sviluppati da autori esterni non verificati e non affidabili.
A differenza dei tradizionali attacchi alla catena di fornitura del software (come quello a SolarWinds) che prendono di mira le infrastrutture di base, i rischi legati ai server MCP di terze parti non richiedono alcuna violazione dell'infrastruttura. Agli hacker basta indurre l'utente a installare il modulo, dopodiché l'agente di intelligenza artificiale lo esegue in modo autonomo. Poiché non vi è alcun intervento umano a verificare un flusso di lavoro automatizzato, una libreria compromessa può sottrarre dati sensibili per giorni senza far scattare alcun allarme.
Il divario nell'autenticazione delle e-mail: cosa può e cosa non può proteggere il DMARC
Mentre i team addetti alla gestione dei rischi si affannano a difendersi da queste minacce via e-mail legate agli attacchi alla catena di approvvigionamento basati sull'intelligenza artificiale, molti ritengono che protocolli come SPF, DKIM e DMARC riusciranno a fermare l'emorragia. Dobbiamo però esaminare attentamente cosa riescono effettivamente a gestire questi controlli e dove si trovano le lacune.
Cosa DMARC, SPF e DKIM sono stati concepiti per impedire
La suite principale composta da SPF, DKIM e DMARC è stata sviluppata per impedire lo spoofing dei domini e impedire ai malintenzionati di lanciare campagne di spoofing via e-mail o BEC sfruttando l'identità del vostro marchio.
- SPF verifica se l'indirizzo IP del server di posta mittente è autorizzato nei tuoi record DNS.
- DKIM aggiunge una firma digitale univoca all'intestazione per dimostrare che il messaggio non è stato alterato durante il trasferimento.
- DMARC le collega tra loro, imponendo regole su come i server di ricezione devono gestire gli errori.
Nell'exploit Postmark-mcp, questi controlli non sono stati aggirati, ma erano del tutto irrilevanti. Poiché il pacchetto dannoso era incorporato all'interno di un'applicazione aziendale legittima, utilizzava chiavi API valide per instradare i messaggi attraverso i server Postmark autorizzati. Ogni e-mail rubata recava una firma DKIM impeccabile e superava perfettamente i controlli SPF. C'è un'amara ironia in tutto questo: quella firma DKIM valida ha persino aiutato il server di ricezione dello stesso aggressore a confermare che i messaggi rubati fossero autentici.
In quali casi l'autenticazione delle e-mail è parzialmente utile
| Componente del protocollo | Protezione contro i server MCP dannosi | Limitazione |
|---|---|---|
| SPF e DKIM | Verifica la validità dell'infrastruttura. | Viene accettato senza problemi poiché l'attacco proviene dal livello applicativo autorizzato. |
| Applicazione DMARC (p=rifiuto) | Impedisce lo spoofing dei domini esterni. | Non è possibile impedire a un'applicazione interna valida di applicare una regola BCC o di divulgare dati direttamente. |
| Reportistica DMARC (RUA / RUF) | Fornisce una visibilità dettagliata sui volumi di invio in uscita e sulle fonti di terze parti. | Richiede un monitoraggio continuo e automatizzato e un'analisi comportamentale per individuare eventuali anomalie. |
Cosa può e cosa non può fare l'autenticazione delle e-mail in questo contesto
DMARC, SPF e DKIM sono stati creati per contrastare lo spoofing, non per prevenire l'esfiltrazione di dati da parte di personale interno
| Non è possibile bloccare | Posso rivelare | Può contenere |
|---|---|---|
| Il server dannoso utilizza una chiave API legittima, pertanto i risultati "PASS" di SPF e DKIM p=reject non possono impedire a un'applicazione interna valida di aggiungere un BCC e divulgare dati direttamente | I report aggregati di RUA tracciano tutte le fonti di invio sul tuo dominio Un improvviso picco nel volume delle transazioni in uscita è il segnale di allarme | Il passaggio a p=reject funge da misura di sicurezza contro le ricadute Impedisce agli hacker di sfruttare i contenuti rubati per falsificare il tuo dominio in successive campagne di phishing |
Il potere di visibilità dei rapporti DMARC
Sebbene non sia in grado di bloccare l'iniezione iniziale di codice, una configurazione matura dell'autenticazione delle e-mail garantisce una visibilità forense fondamentale. Ciò si traduce in report DMARC dettagliati (RUA/RUF).
Se configurati correttamente, questi record forniscono una panoramica chiara di tutti gli indirizzi IP e dei servizi di invio attivi sul proprio dominio. I report aggregati (RUA) riassumono i volumi di invio per origine, mentre i report forensi (RUF) riportano i dettagli relativi ai singoli errori. Se il team SecOps monitora costantemente questi flussi, è in grado di individuare picchi improvvisi e inspiegabili nei volumi delle transazioni in uscita. Il monitoraggio di tali anomalie funge da rilevatore di fumo, segnalando che un'integrazione sta causando una fuga di dati.
Creare un meccanismo di salvaguardia con un'applicazione rigorosa
L'adozione di una politica DMARC rigorosa con impostazione "p=reject" per il proprio dominio costituisce una fondamentale misura di protezione contro le ripercussioni secondarie. Sebbene non impedisca a un server MCP interno di inviare dati in copia nascosta (BCC), questa politica impedisce agli hacker di sfruttare a proprio vantaggio le informazioni rubate. Una politica di rifiuto impedisce infatti agli autori delle minacce di utilizzare fatture trapelate o dati dei clienti per lanciare campagne di phishing mirate e contraffatte contro i vostri clienti e partner utilizzando il vostro dominio effettivo.
Il vero divario: igiene delle credenziali e delle autorizzazioni
In sostanza, questa falla nella sicurezza è stata causata da un errore nella gestione delle identità e degli accessi, non da un problema legato al protocollo di autenticazione. L'attacco è andato a buon fine perché un software non verificato aveva accesso a una chiave API legittima e dotata di privilegi elevati.
La vostra difesa principale in questo caso consiste nel controllo delle dipendenze del codice e nella gestione delle credenziali. Tuttavia, l'implementazione di strumenti di IA autonomi senza un livello di visibilità attivo vi lascia completamente all'oscuro. Il monitoraggio continuo di DMARC crea la rete di sicurezza attiva necessaria per individuare le anomalie comportamentali che indicano un attacco in corso.
Come proteggere la tua organizzazione dagli attacchi via e-mail dannosi di MCP
Per garantire la sicurezza della posta elettronica su un server MCP compromesso è necessario adottare le seguenti misure operative:
1. Verifica l'impronta del tuo server MCP
Non è possibile proteggere ciò che non si monitora. Crea un elenco dettagliato di tutte le integrazioni, i plug-in o i punti di connessione attivi collegati alla tua configurazione di posta elettronica.
- Verifica se l'integrazione proviene da un repository ufficiale del fornitore o da un pacchetto non verificato della comunità su npm o PyPI.
- Indicare chiaramente quali dati e endpoint possono essere interessati da ciascuna integrazione.
- Utilizza strumenti di sicurezza open source come mcp-scan per individuare e analizzare il tuo ambiente alla ricerca di anomalie comportamentali.
2. Applicare il principio del privilegio minimo alle integrazioni di posta elettronica basate sull'intelligenza artificiale
Smettete di concedere un accesso amministrativo illimitato agli strumenti automatizzati.
- Limitare le chiavi API in modo che consentano solo le azioni strettamente necessarie (ad esempio, l'invio di notifiche), bloccando esplicitamente l'accesso completo in lettura e scrittura alla casella di posta.
- Applicare rigidi programmi di rotazione delle chiavi API e revocare immediatamente le credenziali qualora una dipendenza generi un avviso.
- Utilizzare un firewall e politiche di sicurezza di rete per limitare le destinazioni in uscita dai server MCP e inserire nell'elenco delle eccezioni solo gli endpoint API di posta elettronica aziendali conosciuti.
3. Abilitare la generazione di report DMARC e monitorare le anomalie
Se non state analizzando attivamente i dati DMARC aggregati, avete un enorme punto cieco a livello operativo. L'implementazione di uno strumento di analisi DMARC dedicato offre al vostro team una visibilità costante, consentendovi di monitorare i flussi di dati, definire i valori di riferimento relativi ai volumi e ricevere avvisi in caso di improvvisi picchi nelle transazioni in uscita prima che si verifichino danni gravi.
4. Applicare DMARC con p=reject
Lasciare il proprio dominio con una configurazione p=none poco sicura non offre alcuna protezione effettiva. Passare a un livello di applicazione rigoroso p=reject garantisce che, anche se un malintenzionato riuscisse a sottrarre il contenuto delle e-mail tramite un'integrazione compromessa, non potrebbe mai utilizzare tali informazioni rubate per lanciare campagne di spoofing che imitano il dominio ufficiale del vostro marchio.
5. Verificare i server MCP prima della distribuzione
Trattate ogni modulo server MCP con la stessa attenzione riservata a qualsiasi altro componente privilegiato dell'infrastruttura aziendale. Verificate la storia dell'editore, confrontate i pacchetti con la documentazione ufficiale del fornitore ed esaminate il codice sorgente sottostante prima di implementarlo in produzione.
Per ridurre al minimo i rischi, è consigliabile evitare i pacchetti comunitari non certificati e optare per integrazioni certificate e verificate dai fornitori. Per i team che implementano soluzioni di automazione, la scelta di opzioni fornite da fornitori verificati, come il PowerDMARC MCP Server, garantisce un livello di integrazione sicuro e autenticato, progettato specificamente per garantire la sicurezza delle operazioni aziendali.
Il quadro generale – La sicurezza MCP definirà la prossima fase delle minacce via e-mail
La vulnerabilità della libreria postmark-mcp era volutamente poco sofisticata: un solo sviluppatore, un semplice stratagemma basato sul confronto dei nomi e una singola riga di codice nascosto. Eppure ha provocato una fuga di dati su vasta scala. Man mano che le aziende adottano rapidamente strumenti di IA autonomi e l'MCP diventa uno standard nelle architetture software, i gruppi di hacker lanceranno inevitabilmente operazioni molto più sofisticate.
I team di sicurezza devono prepararsi ad affrontare diversi vettori di minaccia emergenti:
- Iniezione indiretta di comandi: gli hacker inviano e-mail dannose volte a manipolare un agente di intelligenza artificiale che legge la posta in arrivo, indurlo a reindirizzare in modo errato dati sensibili o a divulgare chiavi interne.
- Strumenti di workflow dannosi: gli hacker stanno diffondendo strumenti di produttività basati sull'intelligenza artificiale che sembrano utili, ma che in realtà raccolgono di nascosto credenziali e token in background.
- Siti simili di alto valore: sofisticate campagne di typosquatting mirate alle integrazioni aziendali nei settori CRM, risorse umane e finanza sulle reti di pacchetti per sviluppatori.
La posta elettronica è piuttosto vulnerabile poiché si trova al crocevia tra la comunicazione aziendale, la verifica dell'identità (reimpostazione delle password) e i dati aziendali critici. I server MCP che integrano l'intelligenza artificiale in questa infrastruttura hanno accesso a tutti e tre questi aspetti.
Conclusione
Il panorama delle minacce via e-mail si è evoluto ben oltre il semplice phishing esterno. L'incidente relativo a Postmark-MCP dimostra che le organizzazioni devono ora affrontare minacce alla catena di fornitura basate sull'intelligenza artificiale che operano silenziosamente all'interno di ambienti interni considerati sicuri. Questi attacchi di tipo "integrativo" sfruttano credenziali valide per aggirare i filtri tradizionali, ed è proprio per questo che la sicurezza delle e-mail relative ai server MCP dannosi deve ora figurare nell'agenda di ogni CISO.
Per proteggere la tua azienda è necessario trovare un equilibrio tra controlli rigorosi delle autorizzazioni e un monitoraggio continuo dei dati. Combinando una politica di applicazione rigorosa con approfondimenti dettagliati dei report, è possibile individuare volumi di invio anomali e individuare integrazioni non autorizzate prima che i dati vadano persi definitivamente.
Non lasciare i tuoi sistemi automatizzati senza sorveglianza. Proteggi subito il tuo dominio dalle minacce nascoste a livello di applicazione. Scopri tutte le fonti che inviano e-mail a nome del tuo dominio; inizia a monitorarle con DMARC Analyzer di PowerDMARC.
Domande frequenti
Aspetta, se le mie e-mail superano i controlli SPF e DKIM, come può trattarsi di un exploit?
Perché la chiamata proviene dall'interno della rete. Il pacchetto dannoso non sta falsificando il tuo dominio da un server non autorizzato a caso. Si trova proprio all'interno del tuo ambiente applicativo di fiducia e sta dirottando le tue chiavi API reali e legittime. Agli occhi del resto del mondo, il tuo server ha inviato quell'e-mail in modo legittimo, ed è per questo che i protocolli di sicurezza perimetrale gli danno il via libera. Si tratta di un problema di esfiltrazione dei dati, non di spoofing del server.
Se DMARC non è in grado di impedire la fuga di dati, perché dovrei attivarlo?
Immaginate i report aggregati DMARC di RUA come il rilevatore di fumo della vostra rete. Se un server MCP inizia silenziosamente a inviare in copia nascosta (BCC) migliaia di email operative a una casella di posta di terze parti, il volume delle vostre email transazionali registrerà un picco vertiginoso. Se monitorate attivamente i vostri feed di dati DMARC, questo improvviso aumento di volume risalterà immediatamente, fornendo al vostro team SecOps un allarme tempestivo per verificare le dipendenze del codice attivo.
Il nostro team ha bisogno di strumenti di intelligenza artificiale per gestire le e-mail di assistenza. Come possiamo farlo in modo sicuro senza disattivare completamente le integrazioni?
Non è necessario bloccare l'automazione basata sull'IA, basta semplicemente circoscriverla. Innanzitutto, considerate i server MCP come componenti infrastrutturali ad alto rischio: non installate mai script della community non verificati senza aver prima effettuato una revisione del codice. In secondo luogo, limitate l'ambito delle vostre chiavi API con autorizzazioni estremamente specifiche e granulari; se un agente deve solo inviare risposte di assistenza, limitate il suo token API in modo che sia fisicamente impossibile eseguire letture di dati in blocco, creazioni di account o regole BCC. Infine, affidatevi a integrazioni di fornitori verificati come il server MCP di PowerDMARC piuttosto che a cloni della community non verificati.
Come posso verificare se il mio team di sviluppo ha installato per sbaglio un server MCP dannoso?
Il primo passo consiste nell'eseguire una scansione di analisi della composizione del software (SCA) o nell'utilizzare strumenti open source come mcp-scan per mappare il proprio ambiente operativo. Esaminate attentamente i registri pubblici dei pacchetti come npm e PyPI alla ricerca di librerie di terze parti non verificate gestite dalla comunità che gestiscono le vostre pipeline di comunicazione. Se una libreria non è pubblicata direttamente e firmata da un fornitore aziendale verificato, come il repository ufficiale di Postmark o il server MCP sicuro di PowerDMARC, consideratela un rischio fino a quando il codice non viene verificato manualmente.
Specialista dei contenuti presso PowerDMARC
Milena è un'abile scrittrice e creatrice di contenuti con oltre 7 anni di esperienza nella creazione di contenuti coinvolgenti su IT, cybersicurezza, eventi virtuali e altro. Ha una comprovata esperienza nella realizzazione di lavori di alta qualità per riviste internazionali e si è laureata in istituzioni prestigiose come la New York University Abu Dhabi, l'UWC China e il College of Europe.
Ultimi messaggi di Milena Baghdasaryan (vedi tutti)
