Deadbugz: un server MCP che diventa ostile alla terza chiamata di tool, pubblicato su 23 repository in 74 minuti

Il 10 agosto 2026 un account GitHub, zellkernel, ha aperto 23 pull request in 74 minuti contro repository non correlati di AI, MCP e strumenti per sviluppatori, ciascuna delle quali aggiungeva un server MCP chiamato productivity-suite che pubblicizzava due strumenti ordinari, format_text e summarize. Secondo Pillar Security, che ha denominato la campagna Deadbugz e ha pubblicato il suo resoconto il 12 agosto, il server restituiva risultati onesti per le sue prime tre chiamate e poi riscriveva i metadati che passava all'agente: le descrizioni degli strumenti e il contenuto dei prompt iniziavano a indirizzare il modello verso chiavi SSH, credenziali AWS, cronologia della shell e configurazione Kubernetes, e a dirgli di tenere nascosta all'utente quell'attività. Diciannove delle 23 pull request sono state chiuse, quattro erano ancora aperte e nessuna era stata unita quando Pillar le ha esaminate. Nessuna vittima è stata confermata. Questo è un singolo record, segnalato da altri e qui citato a loro. Gli altri incidenti documentati riguardanti gli agenti, ciascuno con le proprie fonti, gravità, livello di confidenza e flag di contestazione, si trovano in l'archivio degli incidenti AI — così una campagna di supply chain mirata agli strumenti per agenti può essere letta accanto al resto di ciò che è realmente accaduto.

L'archivio classifica questo record con gravità alta e confidenza A — ben documentato, con fonti primarie concordanti — mentre registra separatamente l'assenza di danni reali confermati. Entrambe le cose sono vere contemporaneamente, e il divario tra esse è ciò di cui tratta il record: una campagna il cui design è stato documentato con un dettaglio inusuale prima che producesse una vittima che qualcuno possa nominare. Le due date che contano sono a due giorni di distanza. Le pull request sono state inviate il 10 agosto; Ariel Fogel di Pillar Security ha pubblicato l'analisi il 12 agosto, e il post riporta una nota permanente secondo cui sarebbe stato aggiornato man mano che arrivavano informazioni verificate.

Tre chiamate, poi i metadati cambiano

Un server MCP non deve eseguire codice su una macchina per cambiare ciò che fa un agente. Le definizioni degli strumenti vengono passate al modello come contesto in ogni sessione, il che significa che il server che le fornisce può riscrivere le istruzioni che l'agente legge lasciando il nome dello strumento, il suo repository e il suo manifest esattamente come erano. Deadbugz si basa su questa asimmetria, e il nome che Pillar le dà è avvelenamento dei metadati MCP con gating a runtime.

Il meccanismo è abbastanza semplice da riassumere in una frase. Il server mantiene un contatore in memoria, per client, delle richieste tools/call. Per le prime tre, si comporta normalmente. Una volta superata la soglia del contatore, le successive risposte a tools/list e prompts/get vengono restituite alterate — descrizioni degli strumenti diverse, contenuti dei prompt diversi — e indirizzano l'agente verso chiavi SSH, credenziali AWS, cronologia della shell e configurazione Kubernetes, impartendogli l'istruzione di occultare l'attività all'utente. Il testo del prompt avvelenato porta il marcatore deadbugz e un indirizzo Bitcoin.

Il gate è anche il motivo per cui le difese ordinarie non lo rilevano. Il payload è presente nel sorgente fin dalla prima richiesta; nulla nel codice o nella configurazione cambia al momento dell'attivazione. Una scansione statica, una voce SBOM o una lettura una tantum del manifest dello strumento al momento dell'installazione vedono un'utilità di formattazione, perché è ciò che l'utilità restituisce finché il contatore non cambia. Pillar descrive l'attivazione ritardata come una tecnica di evasione della ricerca e afferma che i suoi ricercatori hanno confermato sia la soglia sia i metadati alterati inviando richieste di solo testo al servizio remoto attivo e confrontando le risposte con il sorgente pubblico.

Un dettaglio rende la trappola più ampia di una singola sessione. Il server pubblicizza tools.listChanged, la capacità MCP che segnala a un client che il suo elenco di strumenti è stato revisionato. Un client che rispetta quel segnale rileggerà le definizioni a metà sessione e preleverà la versione avvelenata senza alcuna azione dell'operatore; un client che memorizza le definizioni al momento dell'approvazione non lo farà. Il comportamento di un dato agente è una proprietà del client, non del server, e il documento di Pillar non elenca i client per nome.

Consegna: 23 pull request in 74 minuti

La distribuzione non era un pacchetto su un registry né una dipendenza avvelenata sepolta in un lockfile. Era spam di pull request contro progetti che non avevano nulla a che fare con la presunta funzione del server, che è la forma che assume un tentativo di supply chain a basso costo quando l'attaccante non riesce a ottenere un account di maintainer: presentare abbastanza modifiche di configurazione e attendere che una venga unita o applicata localmente.

La ripartizione dei 23 operata da Pillar si articola in tre categorie. Diciassette aggiungono un endpoint MCP remoto, productivity-suite-mcp[.]onrender[.]com/mcp, ospitato su Render; quattro richiamano un file Python locale nascosto in ~/.config/.cache/.sys/.deadbug-mcp.py; due sono invii a directory o a elenchi, che il resoconto considera ricognizione o riempitivo anziché consegna. La finestra è indicata come dalle 21:52 alle 23:07 UTC del 10 agosto 2026 — 74 minuti nella formulazione della divulgazione, sebbene i due timestamp coprano 75 minuti, e nulla nella documentazione dipende da quel minuto. Solo un repository di destinazione è nominato singolarmente: getsentry/sentry-mcp, pull request #1239, citato come esempio della consegna dell'artefatto locale.

L'account che c'era dietro era consistente per la sua età. Al momento della raccolta di Pillar, zellkernel aveva 50 repository pubblici, 20 dei quali fork, e 21 di quei 50 erano stati creati il 10 agosto, lo stesso giorno della campagna. Il profilo era collegato in modo incrociato all'account X @llmgod, che a sua volta rimandava all'account GitHub, il tipo di collegamento reciproco che depone a favore di un'identità creata appositamente anziché di una dirottata.

Diciannove chiuse, quattro aperte, zero unite è la cifra più ricorrente nel record e anche quella più spesso letta come un via libera, cosa che non è del tutto. Il pulsante di merge di GitHub non è il record di esecuzione di un host: un maintainer può prelevare un branch ed eseguirlo, applicare una configurazione a mano, oppure un job CI può recuperare la head di una PR prima che qualcuno commenti. Le quattro pull request che scrivono una configurazione invocando il percorso di uno script locale sono quelle in cui questo divario conta di più, perché lo script viene recuperato ed eseguito del tutto al di fuori della contabilità dei merge di GitHub. Cloud Security Alliance Labs ha fatto la stessa osservazione nella sua nota del 2 settembre: i conteggi delle chiuse e delle non unite non provano che non sia stato eseguito nulla.

Che cosa è stabilito e che cosa non lo è

Stabilito dalla rivelazione, nel senso che Pillar lo riporta da artefatti che ha letto e in un caso da un servizio che ha interrogato: il server e il suo repository sorgente, i due strumenti pubblicizzati, il contatore e la soglia delle tre chiamate, i quattro obiettivi delle credenziali, i conteggi delle PR e il loro stato di merge al momento della revisione, e il collegamento tra l'account GitHub e l'handle X. Il test di Pillar stesso contro l'endpoint live è l'elemento più forte della lista, perché è una riproduzione anziché una lettura del codice sorgente.

Non accertata, e il resoconto è prudente al riguardo: una vittima. Il campo real_harm dell'archivio è impostato su false, il che è un'affermazione sulle prove, non sulle intenzioni: nessuno ha prodotto un host, un log o una credenziale rubata riconducibili a questa campagna. Né sono identificati la persona o il gruppo dietro zellkernel e @llmgod; Pillar attribuisce l'operazione agli account e si ferma lì. Il movente finanziario poggia su un indirizzo Bitcoin incorporato nel payload, che è un'inferenza tratta da un indicatore, non un accertamento sull'attore. E la domanda a cui un difensore vorrebbe più di ogni altra una risposta — se la campagna sia ancora in corso — non ha risposta nel resoconto: il post era contrassegnato come destinato a essere aggiornato, e non si vede alcuna revisione successiva né alcun avviso di rimozione da parte di GitHub o Render.

Le conferme sono più esili di quanto il grado di fiducia potrebbe suggerire, e vale la pena dirlo chiaramente. Due Cloud Security Alliance Labs note di ricerca, datate 30 agosto e 2 settembre 2026, ribadiscono la campagna; quella successiva è esplicita nel riconoscere a Pillar la scoperta, i dettagli della PR, il comportamento del server e l'attribuzione dell'account, e non descrive alcuna verifica indipendente propria. Un Armor post sul blog datato 22 settembre 2026 fornisce indicazioni difensive e afferma che Pillar ha smontato il server; non offre alcuna prova forense propria. Nessun CVE è stato assegnato, e la CSA afferma che non si tratta di una vulnerabilità della specifica MCP. Al 29 ottobre 2026, le ricerche non fanno emergere alcun avviso da GitHub o Render, né alcuna copertura nella stampa di settore sulla sicurezza mainstream — nessun articolo di BleepingComputer, The Register, SecurityWeek o Hackread — il che è insolito per una campagna di supply chain di questa forma ed è esso stesso parte di ciò che il record mostra. "Le fonti primarie concordano" qui significa una fonte primaria originaria e una serie di documenti secondari che ne derivano.

Due ambiguità minori vanno segnalate anziché attenuate. I riassunti secondari divergono sul se la terza chiamata o la quarta sia la prima a ricevere metadati avvelenati, il che discende dal fatto che il contatore è descritto come scattante alla terza richiesta; sia il record sia l'informativa usano tre. E la finestra di consegna è indicata come di 74 minuti per timestamp che coprono 75.

Un controllo che non è stato possibile ripetere: il 29 ottobre 2026, l'account GitHub zellkernel e il repository zellkernel/productivity-suite-mcp restituiscono entrambi 404, e l'unica pull request nominata singolarmente, getsentry/sentry-mcp #1239, non è più risolvibile nemmeno — il repository stesso ora reindirizza a getsentry/toolkit. I conteggi delle PR, lo stato di merge e i contenuti del repository non possono quindi essere riverificati direttamente oggi; restano lo snapshot di Pillar, rilevato a metà agosto.

Che cosa la divulgazione chiede ai difensori di fare

La risposta che Pillar raccomanda riguarda principalmente il trattare i metadati come una superficie di sicurezza anziché come una loro descrizione. Per gli host, le richieste concrete sono di bloccare o cercare productivity-suite-mcp[.]onrender[.]com/mcp, di mantenere l'endpoint trycloudflare.com precedente della campagna nelle liste di blocco e di ricerca anche se Pillar afferma che non è attualmente attivo, e di non eseguire deadbug-mcp.py — il percorso del file nascosto ~/.config/.cache/.sys/.deadbug-mcp.py è l'artefatto da cercare nelle directory home, nei repository e nelle configurazioni dei client MCP.

L'ordine delle indagini conta più della lista di blocco. Se un host potrebbe essersi connesso, Pillar afferma di preservare i log del client MCP prima di pulire qualsiasi cosa, poi rivedere gli aggiornamenti delle definizioni degli strumenti e ciò che l'agente ha fatto dopo la terza chiamata; le credenziali dovrebbero essere ruotate solo dove le prove locali avvalorano l'esposizione, il che è l'opposto del riflesso di ruotare tutto in caso di sospetto. La configurazione del server consentiva anche telemetria opzionale verso un WEBHOOK_URL, con invio di beacon alla connessione, alla prima chiamata e all'evento di attivazione — un dettaglio che dà a un'indagine un terzo punto da controllare oltre ai log del client e al traffico dell'endpoint.

Per chi sviluppa client MCP, la raccomandazione è strutturale, ed è la parte del documento destinata a durare più a lungo:

• Calcola l'impronta digitale delle definizioni degli strumenti al momento dell'approvazione e confrontale a ogni aggiornamento, anziché fidarti del nome e del repository del server.

• Tratta una modifica della definizione su un server già approvato come un evento di sicurezza che l'operatore vede e riapprova, non come un routinario ricambio di metadati da assorbire in silenzio.

• Applica le operazioni sensibili — accesso alle credenziali, esecuzione di codice, email in uscita, scritture nel repository — tramite policy anziché tramite descrizioni fornite dal server.

Quel terzo elemento è ciò che rende Deadbugz un record anziché una curiosità. Ogni controllo sopra presuppone che un agente possa essere persuaso a fare qualcosa dal testo che un server allega a uno strumento, e che il testo possa cambiare dopo che è stata presa la decisione di fiducia. Pillar colloca la campagna in una linea che comprende l'attacco sleeper MCP del 2025 di Invariant Labs, il pacchetto contraffatto postmark-mcp e un pacchetto MCP documentato da Koi e weaponizzato tramite un aggiornamento — tutti precedenti per la tecnica, citati da Pillar a tale scopo e non come prova su questa distribuzione.

Perché il cancello conta più del numero delle vittime

Una campagna con 23 tentativi di consegna, nessun merge e nessuna vittima confermata è facile da archiviare come tentativo e lasciarsi alle spalle. Il motivo per cui appartiene all'archivio a gravità alta è che la sua elusione non dipende dal fatto che la consegna riesca su larga scala. Dipende da una proprietà che la maggior parte delle distribuzioni MCP condivide oggi: l'approvazione avviene una sola volta, al momento dell'installazione, e si presume che la definizione approvata sia quella che verrà servita. Deadbugz mantiene intatta questa assunzione per tre chiamate e poi la infrange.

La correzione non è una patch per uno specifico server, e non c'è alcun CVE da tracciare. È che "approvato" deve diventare una condizione continuativa con un confronto alla base — il che rappresenta un cambiamento nel modo in cui si comportano i client e i loro operatori, non in ciò che cerca un scanner. Non è ancora noto se qualcuno abbia effettivamente eseguito il server in agosto; allo stato attuale delle informazioni, il meccanismo è la scoperta.