Deadbugz: ein MCP-Server, der beim dritten Tool-Aufruf feindselig wird und innerhalb von 74 Minuten in 23 Repositorys gepusht wurde

Am 10. August 2026 eröffnete ein GitHub-Konto, zellkernel, 23 Pull Requests in 74 Minuten gegen nicht zusammenhängende KI-, MCP- und Entwickler-Tooling-Repositories, wobei jeder einen MCP-Server namens productivity-suite hinzufügte, der zwei gewöhnliche Tools bewarb, format_text und summarize. Laut Pillar Security – das Unternehmen gab der Kampagne den Namen Deadbugz und veröffentlichte seinen Bericht am 12. August – lieferte der Server bei seinen ersten drei Aufrufen ehrliche Ergebnisse und schrieb dann die Metadaten um, die er an den Agenten übergab: Die Toolbeschreibungen und Prompt-Inhalte begannen, das Modell auf SSH-Schlüssel, AWS-Anmeldeinformationen, Shell-Verlauf und Kubernetes-Konfiguration zu lenken und es anzuweisen, diese Aktivität vor dem Benutzer geheim zu halten. Neunzehn der 23 Pull Requests waren geschlossen, vier waren noch offen und keiner war zusammengeführt worden, als Pillar sie prüfte. Es wurde kein Opfer bestätigt. Dies ist ein einzelner Eintrag, von anderen gemeldet und hier unter Verweis auf sie zitiert. Die anderen dokumentierten Agentenvorfälle – jeder mit eigenen Quellen, Schweregrad, Vertrauensstufe und Widerspruchskennzeichnung – befinden sich in dem KI-Vorfallarchiv — sodass eine Supply-Chain-Kampagne, die auf Agenten-Tooling abzielt, neben dem Rest dessen gelesen werden kann, was tatsächlich geschehen ist.

Das Archiv bewertet diesen Eintrag mit hoher Schwere und Konfidenz A – gut dokumentiert, mit übereinstimmenden Primärquellen –, während es separat keine bestätigten realen Schäden verzeichnet. Beides ist gleichzeitig wahr, und die Kluft dazwischen ist das, worum es in dem Eintrag geht: eine Kampagne, deren Design in ungewöhnlichem Detail dokumentiert wurde, bevor sie ein Opfer hervorbrachte, das irgendjemand namentlich nennen kann. Die zwei wichtigen Daten liegen zwei Tage auseinander. Die Pull-Requests gingen am 10. August raus; Ariel Fogel von Pillar Security veröffentlichte die Analyse am 12. August, und der Beitrag trägt einen dauerhaften Hinweis, dass er aktualisiert würde, sobald verifizierte Informationen eingingen.

Drei Anrufe, dann ändern sich die Metadaten.

Ein MCP-Server muss keinen Code auf einer Maschine ausführen, um zu ändern, was ein Agent tut. Tool-Definitionen werden dem Modell in jeder Sitzung als Kontext übergeben, was bedeutet, dass der Server, der sie bereitstellt, die Anweisungen, die der Agent liest, umschreiben kann, während der Name des Tools, sein Repository und sein Manifest exakt unverändert bleiben. Deadbugz basiert auf dieser Asymmetrie, und Pillars Bezeichnung dafür ist runtime-gated MCP metadata poisoning.

Die Mechanik ist so überschaubar, dass man sie in einem Satz zusammenfassen kann. Der Server führt einen im Arbeitsspeicher befindlichen Zähler pro Client für tools/call-Anfragen. Bei den ersten drei verhält er sich normal. Sobald der Zähler ausgelöst wird, kommen spätere tools/list- und prompts/get-Antworten verändert zurück – andere Tool-Beschreibungen, anderer Prompt-Inhalt –, die den Agenten auf SSH-Schlüssel, AWS-Anmeldedaten, Shell-Verlauf und Kubernetes-Konfiguration hinweisen und ihn anweisen, die Aktivität vor dem Nutzer zu verbergen. Der vergiftete Prompt-Text trägt den Marker deadbugz und eine Bitcoin-Adresse.

Das Gate ist auch der Grund, warum die üblichen Abwehrmaßnahmen es nicht erkennen. Die Payload ist seit der ersten Anfrage in der Quelle vorhanden; weder am Code noch an der Konfiguration ändert sich im Moment des Umschaltens etwas. Ein statischer Scan, ein SBOM-Eintrag oder ein einmaliges Lesen des Tool-Manifests zum Installationszeitpunkt sieht ein Formatierungswerkzeug, denn genau das gibt das Werkzeug zurück, bis der Zähler sich ändert. Pillar beschreibt das verzögerte Umschalten als Research-Evasion-Technik und sagt, seine Forscher hätten sowohl die Schwelle als auch die veränderten Metadaten bestätigt, indem sie reine Textanfragen an den live laufenden Remote-Dienst sandten und die Antworten mit der öffentlichen Quelle abglichen.

Ein Detail macht die Falle breiter als eine einzelne Sitzung. Der Server bewirbt tools.listChanged, die MCP-Fähigkeit, die einem Client mitteilt, dass seine Tool-Liste überarbeitet wurde. Ein Client, der dieses Signal beachtet, liest die Definitionen mitten in der Sitzung erneut und zieht die vergiftete Version ohne jegliche Betreiberaktion; ein Client, der Definitionen bei der Genehmigung zwischenspeichert, wird das nicht tun. Welches Verhalten ein bestimmter Agent zeigt, ist eine Eigenschaft des Clients, nicht des Servers, und Pillars Bericht zählt die Clients nicht namentlich auf.

Bereitstellung: 23 Pull Requests in 74 Minuten

Die Distribution war kein Paket in einer Registry oder eine vergiftete Abhängigkeit, die in einer Lockfile vergraben war. Es handelte sich um Pull-Request-Spam gegen Projekte, die nichts mit der angeblichen Funktion des Servers zu tun hatten – die Form, die ein kostengünstiger Supply-Chain-Versuch annimmt, wenn der Angreifer kein Maintainer-Konto erlangen kann: genügend Konfigurationsänderungen einreichen und darauf warten, dass eine davon zusammengeführt oder lokal angewendet wird.

Pillars Aufschlüsselung der 23 ist dreigeteilt. Siebzehn fügen einen Remote-MCP-Endpunkt hinzu, productivity-suite-mcp[.]onrender[.]com/mcp, gehostet auf Render; vier nutzen eine versteckte lokale Python-Datei unter ~/.config/.cache/.sys/.deadbug-mcp.py; zwei sind Einreichungen in Verzeichnissen oder Auflistungen, die der Bericht als Aufklärung oder Füllmaterial statt als Auslieferung einordnet. Das Zeitfenster wird mit 21:52 bis 23:07 UTC am 10. August 2026 angegeben — 74 Minuten in der Darstellung der Offenlegung, obwohl die beiden Zeitstempel selbst 75 umfassen, und nichts in den Unterlagen hängt an dieser Minute. Nur ein Ziel-Repository wird einzeln genannt: getsentry/sentry-mcp, Pull Request #1239, als Beispiel für die Auslieferung lokaler Artefakte angeführt.

Das dahinterstehende Konto war für sein Alter beachtlich. Zum Zeitpunkt von Pillars Erhebung hatte zellkernel 50 öffentliche Repositories, 20 davon Forks, und 21 dieser 50 waren am 10. August angelegt worden, am selben Tag wie die Kampagne. Das Profil war mit dem X-Konto @llmgod verknüpft, das wiederum zurück zum GitHub-Konto verlinkte; dies ist die Art gegenseitiger Verlinkung, die für eine eigens erstellte Identität und nicht für eine gekaperte spricht.

Neunzehn geschlossen, vier offen, null zusammengeführt ist die am häufigsten wiederholte Zahl im Protokoll und zugleich diejenige, die am oftesten als Entwarnung gelesen wird, was sie nicht ganz ist. GitHubs Merge-Schaltfläche ist kein Ausführungsprotokoll eines Hosts: Ein Maintainer kann einen Branch abrufen und ausführen, eine Konfiguration von Hand anwenden, oder ein CI-Job kann den Head eines PR abrufen, bevor jemand kommentiert. Die vier Pull Requests, die eine Konfiguration schreiben, die einen lokalen Skriptpfad aufruft, sind diejenigen, bei denen diese Lücke am stärksten ins Gewicht fällt, weil das Skript außerhalb von GitHubs Merge-Abrechnung vollständig abgerufen und ausgeführt wird. Cloud Security Alliance Labs machte denselben Punkt in seiner Notiz vom 2. September: Die Zahlen der geschlossenen und nicht zusammengeführten Pull Requests beweisen nicht, dass nichts ausgeführt wurde.

Was gilt als gesichert und was nicht

Durch die Offenlegung belegt, und zwar in dem Sinne, dass Pillar dies aus Artefakten berichtet, die Pillar gelesen hat, und in einem Fall von einem Dienst, den Pillar abgefragt hat: der Server und sein Quell-Repository, die beiden beworbenen Tools, der Zähler und die Drei-Aufruf-Schwelle, die vier Credential-Ziele, die PR-Zahlen und ihr Merge-Status zum Zeitpunkt der Überprüfung sowie die Verknüpfung zwischen dem GitHub-Konto und dem X-Handle. Pillars eigener Test gegen den Live-Endpunkt ist der stärkste Eintrag auf der Liste, weil er eine Reproduktion und kein Lesen von Quellcode ist.

Nicht belegt – und der Bericht ist diesbezüglich sorgfältig: ein Opfer. Das Feld real_harm des Archivs ist false, was eine Aussage über die Beweislage ist, nicht über die Absicht – niemand hat einen Host, ein Log oder einen gestohlenen Zugangsdatensatz vorgelegt, die mit dieser Kampagne in Verbindung stehen. Ebenso wenig ist die Person oder Gruppe hinter zellkernel und @llmgod identifiziert; Pillar ordnet die Operation den Konten zu und belässt es dabei. Das finanzielle Motiv beruht auf einer Bitcoin-Adresse, die in der Payload eingebettet ist, was ein Rückschluss aus einem Indikator ist, nicht eine Feststellung über den Akteur. Und die Frage, die ein Verteidiger am dringendsten beantwortet haben möchte – ob die Kampagne noch läuft –, findet im Bericht keine Antwort: Der Beitrag war als einer gekennzeichnet, der aktualisiert werden würde, und es ist keine spätere Überarbeitung oder Löschungsaufforderung von GitHub oder Render ersichtlich.

Die Untermauerung ist dünner, als der Vertrauensgrad vermuten lässt, und das sollte man klar sagen. Zwei Cloud Security Alliance Labs Forschungsnotizen vom 30. August und 2. September 2026 geben die Kampagne erneut wieder; die spätere führt ausdrücklich aus, dass sie Pillar die Entdeckung, die PR-Details, das Serververhalten und die Kontoattribution zuschreibt und keine eigene unabhängige Überprüfung beschreibt. Ein Armor Blogbeitrag vom 22. September 2026 liefert Hinweise zur Verteidigung und sagt, Pillar habe den Server zerlegt; er bietet keine eigenen forensischen Belege. Es wurde keine CVE-Nummer vergeben, und CSA sagt, dass dies keine Schwachstelle der MCP-Spezifikation ist. Stand 29. Oktober 2026 ergeben Suchen weder einen Sicherheitshinweis von GitHub oder Render noch eine Berichterstattung in der etablierten Sicherheitsfachpresse – keinen Artikel von BleepingComputer, The Register, SecurityWeek oder Hackread –, was für eine Lieferkettenkampagne dieser Form ungewöhnlich ist und selbst Teil dessen ist, was die Aufzeichnung zeigt. „Primärquellen stimmen überein“ bedeutet hier eine ursprüngliche Primärquelle und eine Reihe von Sekundärdokumenten, die sich von ihr ableiten.

Zwei kleinere Mehrdeutigkeiten sollten eher benannt als geglättet werden. Die sekundären Zusammenfassungen unterscheiden sich darin, ob der dritte oder der vierte Aufruf der erste ist, der vergiftete Metadaten erhält, was sich daraus ergibt, dass der Zähler beim dritten Request anschlägt; der Datensatz und die Offenlegung verwenden beide drei. Und das Zustellfenster wird mit 74 Minuten für Zeitstempel angegeben, die sich über 75 Minuten erstrecken.

Eine Prüfung, die sich nicht wiederholen ließ: Am 29. Oktober 2026 liefern sowohl das GitHub-Konto zellkernel als auch das Repository zellkernel/productivity-suite-mcp einen 404, und auch der eine namentlich genannte Pull Request, getsentry/sentry-mcp #1239, lässt sich nicht mehr auflösen – das Repository selbst leitet inzwischen auf getsentry/toolkit weiter. Die PR-Zahlen, der Merge-Status und die Repository-Inhalte können daher heute nicht mehr aus erster Hand nachgeprüft werden; sie stehen als Pillars Momentaufnahme, die Mitte August erstellt wurde.

Wozu die Offenlegung die Verteidiger auffordert

Die von Pillar empfohlene Reaktion dreht sich hauptsächlich darum, Metadaten als Sicherheitsfläche statt als Beschreibung einer solchen zu behandeln. Für Hosts lauten die konkreten Aufforderungen: productivity-suite-mcp[.]onrender[.]com/mcp blockieren oder danach suchen, den früheren trycloudflare.com-Endpunkt der Kampagne in Deny- und Hunting-Listen beizubehalten, obwohl Pillar sagt, dass er derzeit nicht aktiv ist, und nicht deadbug-mcp.py auszuführen – der versteckte Dateipfad ~/.config/.cache/.sys/.deadbug-mcp.py ist das Artefakt, nach dem in Home-Verzeichnissen, Repositories und MCP-Client-Konfigurationen gesucht werden muss.

Die Reihenfolge der Untersuchung ist wichtiger als die Blockliste. Wenn ein Host möglicherweise eine Verbindung hergestellt hat, sagt Pillar, MCP-Client-Protokolle aufzubewahren, bevor irgendetwas bereinigt wird, dann Aktualisierungen der Tool-Definitionen und das, was der Agent nach dem dritten Aufruf getan hat, zu prüfen; Zugangsdaten sollten nur dort rotiert werden, wo lokale Belege eine Exposition stützen, was das Gegenteil des Reflexes ist, bei Verdacht alles zu rotieren. Die Serverkonfiguration erlaubte außerdem optionale Telemetrie an eine WEBHOOK_URL, Beaconing bei Verbindung, beim ersten Aufruf und beim Trigger-Ereignis — ein Detail, das einer Untersuchung eine dritte Stelle bietet, an der sie über Client-Protokolle und Endpoint-Traffic hinaus nachsehen kann.

Für die Leute, die MCP-Clients bauen, ist die Empfehlung struktureller Art, und sie ist der Teil der Aufzeichnung, der am längsten Bestand hat:

• Tool-Definitionen zum Zeitpunkt der Genehmigung mit einem Fingerabdruck versehen und sie bei jeder Aktualisierung vergleichen, statt dem Namen und dem Repository des Servers zu vertrauen.

• Behandle eine Änderung der Definition auf einem bereits genehmigten Server als Sicherheitsereignis, das der Betreiber sieht und erneut genehmigt, und nicht als routinemäßiges Metadaten-Rauschen, das stillschweigend hingenommen wird.

• Sensible Vorgänge – Zugriff auf Zugangsdaten, Codeausführung, ausgehende E-Mails, Schreibvorgänge im Repository – durch Richtlinien erzwingen statt durch Beschreibungen, die der Server liefert.

Dieser dritte Punkt ist es, der Deadbugz zu einem dokumentierten Fall statt zu einer Kuriosität macht. Jede der oben genannten Kontrollen setzt voraus, dass ein Agent durch den Text, den ein Server an ein Tool anhängt, zu etwas überredet werden kann und dass sich dieser Text nach der getroffenen Vertrauensentscheidung ändern kann. Pillar ordnet die Kampagne in eine Reihe ein, zu der Invariant Labs’ MCP-Sleeper-Angriff von 2025, das gefälschte postmark-mcp-Paket und ein von Koi dokumentiertes MCP-Paket gehören, das durch ein Update für Angriffe nutzbar gemacht wurde – allesamt Präzedenzfälle für die Technik, die Pillar dafür und nicht als Beleg für diese Lieferung anführt.

Warum das Tor wichtiger ist als die Zahl der Opfer

Eine Kampagne mit 23 Zustellversuchen, ohne Merge und ohne bestätigtes Opfer lässt sich leicht unter „versucht“ ablegen und abhaken. Der Grund, warum sie mit hohem Schweregrad ins Archiv gehört, ist, dass ihre Umgehung nicht davon abhängt, dass die Zustellung im großen Maßstab gelingt. Sie hängt von einer Eigenschaft ab, die die meisten MCP-Bereitstellungen heute teilen: Die Genehmigung erfolgt einmalig bei der Installation, und es wird angenommen, dass die genehmigte Definition die Definition ist, die ausgeliefert wird. Deadbugz hält diese Annahme drei Aufrufe lang intakt und bricht sie dann.

Die Behebung ist kein Patch für einen bestimmten Server, und es gibt keine CVE, der man nachverfolgen müsste. Sie besteht darin, dass „approved“ zu einer fortlaufenden Bedingung mit einem dahinterstehenden Vergleich werden muss – was eine Änderung des Verhaltens von Clients und ihren Betreibern ist, nicht eine Änderung dessen, wonach ein Scanner sucht. Ob irgendjemand den Server im August tatsächlich betrieben hat, ist weiterhin unbekannt; nach der derzeitigen Aktenlage ist der Mechanismus der Befund.