Deadbugz: en MCP-server som blir fientlig vid det tredje verktygsanropet, pushat till 23 repon på 74 minuter

Den 10 augusti 2026: ett GitHub-konto, zellkernel, öppnade 23 pull-förfrågningar på 74 minuter mot orelaterade AI-, MCP- och utvecklarverktygsrepositorier, där var och en lade till en MCP-server med namnet productivity-suite som annonserade två vanliga verktyg, format_text och summarize. Enligt Pillar Security, som kallade kampanjen Deadbugz och publicerade sin rapport den 12 augusti, gav servern ärliga resultat för sina första tre anrop och skrev sedan om metadatan som den överlämnade till agenten: verktygsbeskrivningarna och promptinnehållet började styra modellen mot SSH-nycklar, AWS-autentiseringsuppgifter, shellhistorik och Kubernetes-konfiguration och instruera den att dölja den aktiviteten för användaren. Nitton av de 23 pull-förfrågningarna var stängda, fyra var fortfarande öppna och ingen hade slagits samman när Pillar granskade dem. Inget offer har bekräftats. Detta är en post, rapporterad av andra och här citerad med hänvisning till dem. De andra dokumenterade agentincidenterna, var och en med egna källor, allvarlighetsgrad, konfidensklass och markering för omstridd status, finns i AI-incidentarkivet — så en leveranskedjekampanj riktad mot agentverktyg kan läsas vid sidan av resten av det som faktiskt har hänt.

Arkivet bedömer denna post som hög allvarlighetsgrad och konfidens A – väl dokumenterad, med primärkällor som stämmer överens – samtidigt som det separat noterar att ingen bekräftad verklig skada har konstaterats. Båda sakerna är sanna samtidigt, och gapet mellan dem är vad posten handlar om: en kampanj vars utformning dokumenterades i ovanlig detalj innan den skapade ett offer som någon kan namnge. De två datum som har betydelse ligger två dagar isär. Pull-förfrågningarna skickades ut den 10 augusti; Ariel Fogel från Pillar Security publicerade analysen den 12 augusti, och inlägget har en stående notis om att det skulle uppdateras när verifierad information kom in.

Tre anrop, sedan ändras metadata

En MCP-server behöver inte köra kod på en maskin för att ändra vad en agent gör. Verktygsdefinitioner ges till modellen som kontext vid varje session, vilket innebär att servern som levererar dem kan skriva om instruktionerna som agenten läser samtidigt som den lämnar verktygets namn, dess repository och dess manifest exakt som de var. Deadbugz bygger på den asymmetrin, och Pillar kallar det runtime-gated MCP-metadatagiftning.

Mekaniken är liten nog att beskriva i en mening. Servern har en minnesintern räknare per klient för tools/callförfrågningar. För de första tre gör den som den ska. När räknaren har utlösts kommer senare tools/list och prompts/getsvar tillbaka ändrade – olika verktygsbeskrivningar, olika promptinnehåll – som riktar agenten mot SSH-nycklar, AWS-inloggningsuppgifter, skalhistorik och Kubernetes-konfiguration och instruerar den att dölja aktiviteten för användaren. Den förgiftade prompttexten bär markören deadbugz och en Bitcoin-adress.

Grinden är också orsaken till att de vanliga försvarsmekanismerna inte fångar den. Nyttolasten finns i källan från den första begäran; ingenting i koden eller konfigurationen ändras vid själva växlingen. En statisk genomsökning, en SBOM-post eller en engångsläsning av verktygets manifest vid installation ser ett formateringsverktyg, eftersom det är vad verktyget returnerar tills räknaren ändras. Pillar beskriver den fördröjda växlingen som en teknik för att undvika forskningsanalys och säger att dess forskare bekräftade både tröskeln och de ändrade metadataen genom att skicka textbaserade förfrågningar till den aktiva fjärrtjänsten och matcha svaren mot den offentliga källan.

En detalj gör fällan bredare än en enda session. Servern annonserar tools.listChanged, den MCP-kapabilitet som säger till en klient att dess verktygslista har reviderats. En klient som följer den signalen kommer att läsa om definitionerna mitt i sessionen och hämta den förgiftade versionen utan någon operatörsåtgärd; en klient som cachar definitioner vid godkännande kommer inte att göra det. Vilket beteende en given agent har är en egenskap hos klienten, inte hos servern, och Pillars redogörelse räknar inte upp klienter vid namn.

Leverans: 23 pull requests på 74 minuter

Distributionen var inte ett paket i ett register eller ett förgiftat beroende begravt i en lockfil. Det var pull-request-spam mot projekt som inte hade något att göra med serverns förmodade funktion, vilket är den form ett lågkostnadsförsök i leveranskedjan antar när angriparen inte kan få ett maintainer-konto: skicka in tillräckligt många konfigurationsändringar och vänta på att en blir sammanslagen eller tillämpad lokalt.

Pillars uppdelning av de 23 är tredelad. Sjutton lägger till en fjärransluten MCP-slutpunkt, productivity-suite-mcp[.]onrender[.]com/mcp, som hostas på Render; fyra anropar en dold lokal Python-fil på ~/.config/.cache/.sys/.deadbug-mcp.py; två är katalog- eller listningsinlämningar, som rapporten behandlar som rekognosering eller utfyllnad snarare än leverans. Tidsfönstret anges som 9:52 PM till 11:07 PM UTC den 10 augusti 2026 — 74 minuter i avslöjandets formulering, även om de två tidsstämplarna själva spänner över 75, och ingenting i protokollet hänger på den minuten. Endast ett målrepository anges individuellt: getsentry/sentry-mcp, pull request #1239, som citeras som ett exempel på leveransen av den lokala artefakten.

Kontot bakom det var betydande för sin ålder. Vid tiden för Pillars insamling hade zellkernel 50 offentliga repositorier, 20 av dem forks, och 21 av dessa 50 hade skapats den 10 augusti, samma dag som kampanjen. Profilen var korslänkad till X-kontot @llmgod, som länkade tillbaka till GitHub-kontot, vilket är den typ av ömsesidig länkning som talar för en identitet skapad för ändamålet snarare än en kapad.

Nitton stängda, fyra öppna, noll sammanslagna är den mest upprepade siffran i journalen och också den som oftast läses som ett klartecken, vilket den inte riktigt är. GitHubs sammanslagningsknapp är inte en vörds körningshistorik: en underhållare kan hämta en branch och köra den, tillämpa en konfiguration manuellt, eller så kan ett CI-jobb hämta en PR:s head innan någon kommenterar. De fyra pull requests som skriver en konfiguration som anropar en lokal skriptsökväg är de där den luckan spelar störst roll, eftersom skriptet hämtas och körs helt utanför GitHubs sammanslagningsredovisning. Cloud Security Alliance Labs framförde samma poäng i sin notis den 2 september: antalet stängda och icke sammanslagna bevisar inte att ingenting kördes.

Vad som är fastställt, och vad som inte är det

Fastställt genom avslöjandet, i den bemärkelsen att Pillar rapporterar detta utifrån artefakter som Pillar har läst och i ett fall från en tjänst som Pillar har frågat: servern och dess källkodsarkiv, de två annonserade verktygen, räknaren och tröskelvärdet på tre anrop, de fyra målen för autentiseringsuppgifter, PR-antalen och deras merge-status vid granskningen, samt kopplingen mellan GitHub-kontot och X-handtaget. Pillars eget test mot den aktiva slutpunkten är den starkaste posten på listan, eftersom det är en reproduktion snarare än en läsning av källkoden.

Inte fastställt, och arkivet är noggrant med det: ett offer. Arkivets real_harm-fält är satt till false, vilket är ett uttalande om bevis, inte om avsikt – ingen har framlagt en värd, en logg eller en stulen autentiseringsuppgift som är knuten till den här kampanjen. Inte heller är personen eller gruppen bakom zellkernel och @llmgod identifierad; Pillar hänför operationen till kontona och stoppar där. Det finansiella motivet vilar på en Bitcoin-adress inbäddad i nyttolasten, vilket är en slutledning utifrån en indikator, inte ett konstaterande om aktören. Och den fråga en försvarare helst vill få svar på – om kampanjen fortfarande pågår – har inget svar i arkivet: inlägget markerades som ett som skulle uppdateras, och ingen senare revidering eller nedtagningsanmälan från GitHub eller Render är synlig.

Bekräftelsen är tunnare än förtroendegraden kan antyda, och det är värt att säga rakt ut. Två Cloud Security Alliance Labs forskningsanteckningar, daterade 30 augusti och 2 september 2026, upprepar kampanjen; den senare är uttrycklig i att den krediterar Pillar för upptäckten, PR-detaljerna, serverns beteende och attribueringen av kontot, och beskriver ingen egen oberoende verifiering. En Armor bloggpost daterad 22 september 2026 ger defensiv vägledning och säger att Pillar tog isär servern; den erbjuder inget eget forensiskt bevis. Ingen CVE tilldelades, och CSA säger att detta inte är en sårbarhet i MCP-specifikationen. Per den 29 oktober 2026 ger sökningar ingen säkerhetsrådgivning från GitHub eller Render, och ingen bevakning i den bredare säkerhetsfackpressen — ingen artikel i BleepingComputer, The Register, SecurityWeek eller Hackread — vilket är ovanligt för en leveranskedjekampanj av den här formen och är i sig en del av vad dokumentationen visar. "Primärkällor stämmer överens" betyder här en ursprunglig primärkälla och en uppsättning sekundära dokument som härrör från den.

Två mindre oklarheter är värda att påpeka snarare än att släta över. Sekundära sammanfattningar skiljer sig åt kring huruvida det tredje anropet eller det fjärde är det första som får förgiftad metadata, vilket följer av att räknaren beskrivs som att den utlöses vid den tredje begäran; både journalen och redogörelsen använder tre. Och leveransfönstret beskrivs som 74 minuter för tidsstämplar som spänner över 75.

En kontroll som inte kunde upprepas: den 29 oktober 2026 returnerar GitHub-kontot zellkernel och repositoryt zellkernel/productivity-suite-mcp båda 404, och den enda enskilt namngivna pull requesten, getsentry/sentry-mcp #1239, går inte heller längre att slå upp — själva repositoryt omdirigerar nu till getsentry/toolkit. PR-antalen, sammanslagningsstatusen och repositoryts innehåll kan därför inte förstahandsverifieras i dag; de står kvar som Pillars ögonblicksbild, tagen i mitten av augusti.

Vad avslöjandet ber försvararna att göra

Den respons som Pillar rekommenderar handlar mest om att behandla metadata som en säkerhetsyta snarare än som en beskrivning av en sådan. För värdar är de konkreta uppmaningarna att blockera eller jaga efter productivity-suite-mcp[.]onrender[.]com/mcp, att behålla kampanjens tidigare trycloudflare.com-slutpunkt i denylistor och jaktlistor även om Pillar säger att den inte är aktiv just nu, och att inte köra deadbug-mcp.py – den dolda filsökvägen ~/.config/.cache/.sys/.deadbug-mcp.py är artefakten att söka efter i hemkataloger, kodförråd och MCP-klientkonfigurationer.

Utredningsordningen är viktigare än blockeringslistan. Om en värd kan ha anslutit säger Pillar att man ska bevara MCP-klientloggar innan något rengörs, och sedan granska uppdateringar av verktygsdefinitioner och vad agenten gjorde efter det tredje anropet; autentiseringsuppgifter bör endast roteras där lokala bevis stöder exponering, vilket är motsatsen till reflexen att rotera allt vid misstanke. Serverns konfiguration tillät också valfri telemetri till en WEBHOOK_URL, beaconing vid anslutning, första anrop och triggerhändelse – en detalj som ger en utredning ett tredje ställe att leta på utöver klientloggar och slutpunktstrafik.

För dem som bygger MCP-klienter är rekommendationen strukturell, och det är den del av protokollet som håller längst:

• Ta fingeravtryck på verktygsdefinitioner vid godkännandetillfället och jämför dem vid varje uppdatering, i stället för att lita på serverns namn och arkiv.

• Behandla en definitionsändring på en redan godkänd server som en säkerhetshändelse som operatören ser och godkänner på nytt, inte som rutinmässigt metadatabrus som tystas ned.

• Genomdriv känsliga åtgärder – åtkomst till autentiseringsuppgifter, kodkörning, utgående e-post, skrivningar till kodförvaret – via policy i stället för via beskrivningar som servern levererar.

Den tredje punkten är det som gör Deadbugz till ett rekord snarare än en kuriositet. Varje kontroll ovan förutsätter att en agent kan övertalas att göra saker av den text som en server fäster vid ett verktyg, och att texten kan ändras efter att förtroendebeslutet har fattats. Pillar placerar kampanjen i en linje som omfattar Invariant Labs 2025 MCP-sleeperattack, det förfalskade postmark-mcp-paketet och ett Koi-dokumenterat MCP-paket som vapeniserats genom en uppdatering – alla är de precedenter för tekniken, citerade av Pillar för detta och inte som bevis om denna leverans.

Varför grinden betyder mer än antalet offer

En kampanj med 23 leveransförsök, ingen sammanslagning och inget bekräftat offer är lätt att arkivera som ett försök och gå vidare. Skälet till att den hör hemma i arkivet med hög allvarlighetsgrad är att dess undvikande inte beror på att leveransen lyckas i stor skala. Det beror på en egenskap som de flesta MCP-driftsättningar delar i dag: godkännandet sker en gång, vid installationen, och den definition som godkändes antas vara den definition som kommer att serveras. Deadbugz håller den antagelsen intakt under tre anrop och bryter sedan den.

Åtgärden är inte en patch för en specifik server, och det finns ingen CVE att spåra. Det handlar om att "godkänd" måste bli ett fortlöpande villkor med en jämförelse bakom sig – vilket är en förändring i hur klienter och deras operatörer beter sig, inte en förändring i vad en skanner letar efter. Huruvida någon faktiskt körde servern i augusti är fortfarande okänt; enligt det som finns dokumenterat är mekanismen fyndet.