Deadbugz: MCP-Lieferkettenkampagne schleuste versteckte Angriffsinstruktionen ein

Kampagne gegen fremde Projekte

Am 10. August 2026 reichte das öffentliche GitHub-Konto zellkernel innerhalb von 74 Minuten insgesamt 23 Pull-Requests bei voneinander unabhängigen KI-, MCP- und Entwicklerwerkzeug-Projekten ein. Die Änderungen sollten einen Server namens productivity-suite in fremde Konfigurationen aufnehmen oder auf ein verstecktes lokales Python-Skript verweisen. Pillar Security ordnete diese beobachtete Lieferoperation der Kampagne Deadbugz zu. Das Ereignisdatum ist der 10. August; der Primärbericht trägt lediglich den Aktualisierungsstand 12. August 2026. [1]

Pillar zufolge waren die 23 untersuchten Pull-Requests zum Prüfzeitpunkt nicht über GitHubs Pull-Request-Mechanismus zusammengeführt worden. Neunzehn waren geschlossen, vier noch offen. Siebzehn Änderungen konfigurierten einen entfernten MCP-Endpunkt, vier verwiesen auf die versteckte Datei .deadbug-mcp.py und zwei waren Verzeichnis- oder Listeneinreichungen. Damit ist ein realer Verteilungsversuch gegen fremde Projekte belegt. Nicht belegt ist dagegen, dass ein Zielprojekt den vorgeschlagenen Server dauerhaft übernahm oder darüber Zugangsdaten verlor. [1]

Wie der MCP-Server funktionierte

MCP steht für Model Context Protocol. Das Protokoll ermöglicht es einem KI-System, externe Werkzeuge über einen Client mit einem Server zu verbinden. Der Server beschreibt dabei verfügbare Funktionen und übermittelt Metadaten, anhand derer das Modell Werkzeugaufrufe auswählen kann. Deadbugz nutzte genau diesen Vertrauenskanal: productivity-suite bot zunächst gewöhnlich wirkende Funktionen zum Formatieren und Zusammenfassen von Text an. Seine öffentlich einsehbare Implementierung führte zugleich für jeden verbundenen Client einen internen Zähler über Werkzeugaufrufe. [1] [2]

Nach drei tools/call-Anfragen veränderte der Server bei späteren tools/list- und prompts/get-Antworten die ausgelieferten Beschreibungen. Statt neutraler Dokumentation erschienen Anweisungen, einen angeschlossenen Agenten nach SSH-Schlüsseln, AWS-Zugangsdaten, Shell-Verlauf und Kubernetes-Konfiguration suchen zu lassen und die Aktivität vor dem Nutzer zu verbergen. Entscheidend war kein Timer, sondern die Zahl der Aufrufe. Pillar erzeugte diese veränderten Metadaten in einer kontrollierten Interaktion mit harmlosen Textanfragen und verglich sie mit dem öffentlichen Quellcode. [1]

Verteilung und Tarnmechanismus

Das Konto zellkernel veröffentlichte nach Pillars Auswertung auch das passende öffentliche Repository und verwendete über die Einreichungen hinweg denselben Servernamen, Endpunkt, lokalen Dateipfad und weitere Kampagnenmerkmale. Diese Beobachtungen tragen eine Zuordnung zur öffentlichen Kontoidentität und ihrer Infrastruktur, nicht zu einer festgestellten natürlichen Person. Sie belegen ebenfalls nicht, ob der Code mit oder ohne KI-Unterstützung erstellt wurde. Entdeckt und analysiert wurde die Kampagne von Pillar Security; das Unternehmen veröffentlichte nicht den gefundenen Angriffscode selbst. [1]

Der Aufrufzähler sollte kurze Prüfungen erschweren: Bei den ersten Interaktionen erschien der Server als harmlose Textanwendung, erst nach Überschreiten der Schwelle wurden die schädlichen Instruktionen sichtbar. Der bösartige Inhalt war laut Pillar bereits in der öffentlichen Implementierung vorhanden und wurde abhängig vom Sitzungszustand zurückgehalten. Die September-Einordnungen von Cloud Security Alliance und Adversa beschreiben diesen Mechanismus als laufzeitabhängige Metadatenvergiftung und betonen, dass eine einmalige Kontrolle beim Einrichten eines Servers deshalb nicht ausreicht. [1] [2] [3]

Was Verteidiger daraus ableiten können

Pillar empfahl, den genannten entfernten Endpunkt zu blockieren, Änderungen mit dem Namen productivity-suite oder dem versteckten Skriptpfad zurückzuweisen und vorhandene Konfigurationen nach diesen Merkmalen zu durchsuchen. Wo ein Gerät tatsächlich verbunden war, sollten Protokolle gesichert und spätere Agentenhandlungen geprüft werden. Eine vorsorgliche Untersuchung sensibler Zugriffe soll sich dabei auf lokale Belege stützen. Das ist wichtig, weil allein ein Pull-Request oder eine Verbindung noch nicht beweist, dass Dateien gelesen oder Zugangsdaten übertragen wurden. [1]

Für MCP-Clients liegt die wesentliche Abwehrmaßnahme darin, Werkzeugbeschreibungen nicht nur bei der ersten Freigabe zu prüfen. Pillar und die späteren Einordnungen empfehlen, Änderungen an Definitionen sichtbar zu machen, mit einem bekannten Stand zu vergleichen und vor sensiblen Aktionen eine neue Zustimmung zu verlangen. Zugriffe auf Zugangsdaten, Dateien, Codeausführung oder externe Dienste sollten zusätzlich durch Berechtigungsregeln begrenzt bleiben. Dadurch hängt die Sicherheit nicht allein davon ab, ob ein Modell manipulierte natürlichsprachliche Metadaten korrekt als Angriff erkennt. [1] [2] [3]

Belegte Kampagne, unbelegte Agentenreaktion

Die Quellen tragen eine belastbare Darstellung des Angriffsversuchs: öffentliche Pull-Requests, übereinstimmender Quellcode, ein erreichbarer Server und von Forschern abgerufene schädliche Metadaten. Sie dokumentieren aber keine anschließend durch ein KI-System gelesenen Schlüssel, ausgeführten Befehle oder übertragenen Daten. Auch die kontrollierte Interaktion beobachtete die Antworten des Servers, nicht die autonome Reaktion eines Agenten darauf. Ein programmierter Zähler und Angriffsinstruktionen sind Verhalten der Infrastruktur; daraus folgt noch keine Handlung des adressierten KI-Systems. [1]

Die Quellenbasis besteht aus einem detaillierten Primärbericht von Pillar Security und zwei späteren Kontextbeiträgen. Cloud Security Alliance und Adversa bestätigen die Einordnung des Mechanismus, übernehmen die Kerndaten des Vorfalls jedoch wesentlich von Pillar. Es liegen somit nicht drei unabhängige Bestätigungen vor. Ebenso wenig beschreibt der September einen neuen Vorfall: Die Beiträge vom 2. und 7. September ordnen die Kampagne vom 10. August nachträglich ein. Diese Abhängigkeit begrenzt die Sicherheit weitergehender Aussagen über Reichweite und Folgen. [1] [2] [3]

Terminator-Check

Autonomie, Grenzüberschreitung und Täuschung sind jeweils nicht belegt. Der Server lieferte zwar Instruktionen zur Suche nach Geheimnissen und zum Verbergen dieser Suche, doch die Quellen zeigen keinen Agenten, der solche Schritte auswählte oder ausführte. Die Täuschungslogik des Servers und die Absicht des öffentlichen Kampagnenkontos dürfen nicht dem angesprochenen KI-System zugerechnet werden. Ohne beobachtete Agentenhandlung gibt es auch keinen belegten Regel- oder Befugnisverstoß durch KI, unabhängig davon, wie gefährlich die vorgesehenen Aktionen gewesen wären. [1]

Selbsterhaltung ist ebenfalls nicht belegt: Es gibt weder Widerstand gegen Abschaltung noch ein erkennbares Eigeninteresse eines Agenten. Bei der Realweltwirkung bleibt ein Angriffsversuch, weil reale Pull-Requests gegen fremde Projekte eingereicht und schädliche Serverantworten abgerufen wurden. Ein erfolgreicher Datenzugriff durch KI ist jedoch nicht nachgewiesen. Der Terminator-Score beträgt deshalb 0 von 5. Das bedeutet hier ausschließlich: kein belegtes autonomes Fehlverhalten eines KI-Agenten. Es bedeutet ausdrücklich nicht, dass die Lieferkettenkampagne harmlos war. [1]