La sera del 10 agosto 2026, una ricercatrice di sicurezza di Pillar Security ha collegato un server MCP open source al proprio agente AI e ha fatto tre normali chiamate a uno strumento. Formatta questo testo. Riassumi quest’altro. Il server si è comportato bene. Poi è cambiato. Alla quarta interazione, lo stesso server, stessa versione, stesso nome su ogni schermo, ha cominciato a restituire istruzioni diverse, istruzioni che spingevano l’agente verso le chiavi SSH e le credenziali AWS e gli dicevano di tacere a riguardo. Nulla era stato sfruttato nel senso classico del termine. Lo strumento aveva semplicemente deciso, alla terza chiamata, di smettere di essere lo strumento che dichiarava di essere.

Il manuale che legge te

Per vedere il trucco serve un solo fatto sul Model Context Protocol, lo standard di collegamento che permette agli agenti di usare strumenti esterni. Ogni strumento si presenta all’agente con un nome, una descrizione e uno schema, e l’agente legge tutti e tre come contesto nel decidere cosa fare. La documentazione non viene mostrata a un essere umano; viene consumata dal modello. Il che significa che i metadati di uno strumento sono prompt, e i prompt sono istruzioni. Una descrizione malevola è indistinguibile, dal lato dell’agente, da una legittima. Il settore ha passato un anno a irrobustirsi contro i prompt injection contrabbandati tramite email e pagine web, e per tutto quel tempo c’era una strada più rapida: diventare lo strumento, e scrivere la propria descrizione.^[1]

Quattro escalation

La strada verso quel server è stata lastricata in piena vista, e ogni suo gradino appariva, a prima vista, come un vecchio problema con un nuovo indirizzo. A settembre 2025 un attaccante ha registrato su npm un pacchetto chiamato postmark-mcp, impersonando Postmark, un servizio legittimo di invio email il cui server MCP permette agli agenti di spedire posta. Il pacchetto finto si è costruito la fiducia sopra quindici versioni pulite, poi ha aggiunto un backdoor nella versione 1.0.16 che copiava in segreto ogni email inviata dall’agente verso un server esterno, in copia nascosta. Il progetto ATLAS di MITRE l’ha catalogato come il primo server MCP malevolo trovato in natura. Postmark non c’entrava nulla.^[2]

Sei mesi dopo l’attacco ha smesso persino di fingersi una specie nuova. A marzo 2026 qualcuno ha avvelenato su PyPI stessa l’ultima versione di litellm, una diffusa libreria Python. Nessun agente è stato ingannato da nulla. L’ambiente di coding di uno sviluppatore, Cursor, ha provato a caricare automaticamente un server MCP locale, e la catena di dipendenze del server, non bloccata a versioni precise come di consueto, ha scaricato con zelo la libreria appena avvelenata pochi minuti dopo la sua pubblicazione. Il malware ha fatto cadere un file nei site-packages che si esegue a ogni avvio di Python e lancia un payload codificato in base64. Era costruito in modo sciocco: il payload ha innescato una fork bomb sulla macchina, undicimila processi a CPU piena, ed è l’unico motivo per cui la vittima se ne è accorta. Il commento di Karpathy, riportato dal racconto della vittima stessa, è stato che senza quel bug sarebbe passato inosservato molto più a lungo. Quarantasettemila download erano già usciti dalla porta nei primi quarantasei minuti. La conclusione della ricercatrice merita una cornice: ci hanno presi tramite i server MCP con un classico attacco alla catena di fornitura, senza bisogno di ingannare alcun LLM.^[3]

A febbraio dello stesso anno lo stesso copione si era dato un sistema riproduttivo. I ricercatori di Socket hanno documentato un worm diffuso attraverso diciannove pacchetti npm, che rubava credenziali per fornitori di modelli AI, SSH, AWS e GitHub, e spediva con sé un proprio server MCP come payload: il malware usava lo standard di connessione dell’ecosistema degli agenti come vettore per il salto successivo.^[4]

Il che riporta la storia al server che si comportava bene per tre volte. La squadra di Pillar ha chiamato la tecnica runtime-gated metadata poisoning, e il cancello è ciò che la rende nuova. Il server teneva un contatore privato di chiamate per client; le istruzioni malevole esistevano nel codice dall’inizio, ma venivano trattenute fino alla terza interazione ordinaria. La revisione del codice vedeva un formattatore di testo. Il test in sandbox vedeva un formattatore di testo. Il codice pubblico dichiarava persino che la propria lista di strumenti poteva cambiare, una legittima funzione del protocollo, così che i client conformi avrebbero rinfrescato i metadati nell’esatto momento in cui diventavano ostili. I nomi degli strumenti non sono mai cambiati. Le istruzioni sotto di loro, sì.^[1]

La campagna dietro il server

Deadbugz, come la squadra ha intitolato la propria divulgazione, non era un esperimento isolato ma uno sforzo di distribuzione in corso. Ventitré richieste di pull sono arrivate su repository pubblici di GitHub in settantaquattro minuti nella notte del 10 agosto, da un account che aveva creato ventun repository lo stesso giorno. Diciassette delle richieste chiedevano ai manutentori dei progetti di aggiungere un endpoint MCP remoto, ospitato su una piattaforma di deployment gratuita, alle proprie configurazioni MCP; quattro chiedevano di eseguire uno script locale nascosto lungo un percorso dall’aspetto plausibile; un pugno di altre erano ricognizione. Ogni richiesta, ispezionata al momento della revisione, indicava strumenti di produttività dall’aspetto innocuo. Nessuna era stata fusione quando Pillar ha pubblicato, il che vale la pena dire senza girarci intorno: il cancello ha funzionato in laboratorio, e il riflesso di revisione della comunità, chiudere ventitré richieste sospette, ha funzionato nel mondo reale. La campagna è attiva finché non lo è più.^[1]

La scala dell’escalation è ormai costruita per intero. Un pacchetto typosquat dimostra che gli utenti installeranno il server sbagliato. Una dipendenza avvelenata dimostra che lo stack degli agenti eredita ogni debolezza dell’ecosistema di pacchetti sottostante. Un worm dimostra che i server possono diffondersi. Il metadata poisoning dimostra che il server può mentire su se stesso dall’interno, con un calendario scelto da solo. Ogni gradino era scalabile perché ognuno, dal basso, sembrava il gradino precedente: un vecchio problema di catena di fornitura con la targhetta del nome di un nuovo protocollo.

Difendere la catena di fornitura MCP

Le contromisure, vecchie e nuove, formano una scala corrispondente. Blocca le tue dipendenze a versioni precise, bloccale con hash, verifica prima di aggiornare: il caso litellm dimostra che non è un consiglio decorativo; l’88 percento dei pacchetti dipendenti nel postmortem non aveva alcuna protezione del genere. Tieni una lista di server MCP consentiti e tratta i nuovi come estranei, perché il caso Postmark è un estraneo con un nome familiare. E per il livello runtime, la raccomandazione di Pillar è la linea più netta tracciata finora in questo spazio: trattare ogni cambiamento nella definizione degli strumenti di un server già approvato come un evento di sicurezza significativo, visibile all’utente e con approvazione da rinnovare, e improntare le definizioni al momento dell’approvazione così che la deriva sia rilevabile. Tre chiamate innocue non sono una reputazione. Sono un conto alla rovescia che significa qualcosa solo se stai contando.^[1]

Il caso della difesa

La lettura ottimistica ha prove vere alle spalle, la maggior parte delle quali viene da questi stessi incidenti. Le ventitré richieste di pull di Deadbugz sono state chiuse dai manutentori, non fuse; il litellm avvelenato è stato messo in quarantena da PyPI entro un’ora dalla segnalazione di un utente; l’imitatore di Postmark è stato smascherato dall’azienda vera entro un giorno e catalogato da MITRE come caso di studio per la prossima generazione di difensori. Il worm è stato trovato dai ricercatori, non dalle vittime. La fork bomb è stata la fretta degli attaccanti che si è rivolta contro di loro. Ogni livello dello stack, dal registro dei pacchetti al manutentore del repository all’utente di agenti che ha chiesto a Claude di indagare su un laptop che tasteggiava, ha beccato qualcosa quest’anno, e le divulgazioni dei ricercatori hanno viaggiato abbastanza in fretta da irrobustire l’ecosistema mentre le campagne erano in corso.^[3]

È anche vero che il protocollo è giovane, i suoi registri si stanno formalizzando, e il cancello specifico nel server Deadbugz è oggi conoscenza pubblica che i difensori possono cercare. Ma notate ciò che l’ottimismo concede: celebra il rilevamento, non l’assenza. Gli attacchi sono tutti partiti. Il backdoor è arrivato in un numero di versione, il veleno viaggiava su un auto-installatore legittimo, la riscrittura si nascondeva dietro una legittima funzione del protocollo, e le uniche cose in piedi tra ognuno di loro e una corsa sfrenata di raccolta credenziali erano il sospetto umano e una fork bomb accidentale. Una catena di fornitura in cui il consegnabile sono istruzioni, e l’istruzione può cambiare dopo la consegna, ha una proprietà che nessuna catena di fornitura software aveva prima: l’artefatto che hai revisionato non è l’artefatto che esegui. La fiducia, in questo protocollo, non si concede più al momento dell’installazione. Si rinegozia a ogni chiamata, e quest’autunno gli strumenti hanno cominciato a rinegoziare a loro volta.

Lo strumento è stato revisionato. Lo strumento era fidato. Lo strumento aspettava la sua terza chiamata.

---

1. Pillar Security, Deadbugz: Currently Active MCP Supply Chain Campaign (aggiornato al 12 agosto 2026). Server productivity-suite con strumenti benigni format_text e summarize; contatore in memoria per client; «after three tool calls», le risposte di tools/list e prompts/get restituiscono istruzioni in cerca di credenziali (chiavi SSH, credenziali AWS, cronologia della shell, configurazione Kubernetes) più istruzioni di occultamento; dichiara tools.listChanged così i client rinfrescano i metadati mentre i nomi degli strumenti restano invariati; «runtime-gated MCP metadata poisoning»; «Tool descriptions and schemas are a security boundary.» Distribuzione: 23 pull request in 74 minuti (10 agosto 2026, 21:52-23:07 UTC) dall’account zellkernel (17 aggiungono l’endpoint remoto productivity-suite-mcp.onrender.com/mcp, 4 aggiungono lo script nascosto ~/.config/.cache/.sys/.deadbug-mcp.py); esempio: getsentry/sentry-mcp PR #1239; 19 chiuse, 4 aperte, nessuna fusa; attribuzione a livello di account (zellkernel, collegato a @llmgod su X). Raccomandazione: «Treat any change in an already-approved server’s tool definition as a meaningful security event.»
2. Postmark (ActiveCampaign), Security Alert: Malicious ‘postmark-mcp’ npm Package Impersonating Postmark: il pacchetto finto «built trust over 15 versions, then added a backdoor in version 1.0.16 that secretly BCC’d emails to an external server» (settembre 2025); catalogato come caso MITRE ATLAS AML.CS0053, descritto da Koi come il primo server MCP malevolo trovato in natura; si veda anche l’allerta Snyk del 25 settembre 2025.
3. FutureSearch, No Prompt Injection Required (24 marzo 2026): litellm avvelenato su PyPI e scaricato automaticamente da uvx tramite una dipendenza MCP non bloccata in versione in Cursor; persistenza via litellm_init.pth nei site-packages; effetto fork bomb (~11.000 processi) che l’ha reso visibile, con Andrej Karpathy che nota che sarebbe passato altrimenti inosservato molto più a lungo; 47.000 download in 46 minuti, 88% dei pacchetti dipendenti non protetti; PyPI ha messo il pacchetto in quarantena; «MCP servers got us via regular old supply chain attacks, no tricking of LLMs required»; gli utenti di auto-installatori come «beta testers of freshly released malware».
4. Socket (riportato da heise, 26 febbraio 2026): worm su 19 pacchetti npm che ruba credenziali di fornitori AI, SSH, AWS e GitHub, con proprio server MCP come vettore di propagazione.