Deadbugz: Die vierte MCP-Angriffsklasse versteckt sich, bis Sie ihr vertrauen

Zentrale Erkenntnisse

• 23 Pull Requests in 74 Minuten — ein einziges GitHub-Konto reichte die Kampagnen-PRs in nicht verwandten KI-, MCP- und Developer-Tool-Projekten am 10. August 2026 ein; keiner wurde über den Review-Mechanismus von GitHub gemerged, aber vier waren zum Zeitpunkt der Offenlegung noch offen (Pillar Security).
• Drei harmlose Aufrufe, dann werden die Metadaten umgeschrieben — der bösartige MCP-Server führt einen aufrufbezogenen Zähler; nach der dritten tools/call-Anfrage weisen die folgenden tools/list- und prompts/get-Antworten den Agenten an, SSH-Schlüssel, AWS-Zugangsdaten, Shell-History und Kubernetes-Konfiguration zu suchen und die Aktivität vor dem Nutzer zu verbergen.
• Runtime-gesteuerte Metadaten-Manipulation ist die vierte eigenständige MCP-Angriffsklasse — STDIO-Befehlsinjektion → Tool-Poisoning → SHA-Pinning-Umgehung → runtime-gesteuerte Metadaten-Manipulation nach Vertrauensaufbau. Der Deadbugz-Mechanismus ist vor dem Deployment am schwersten zu erkennen, weil der Server die Erstprüfung besteht und die Payload erst aktiviert wird, wenn der Client ein Nutzungsmuster etabliert hat.
• Tool-Definition-Fingerprinting ist die Verteidigung — einen Fingerabdruck der Tool-Definitionen beim Genehmigungszeitpunkt erfassen und abgleichen; jede Änderung an den Tool-Metadaten eines bereits genehmigten Servers als Sicherheitsereignis behandeln, das eine erneute Operatoren-Freigabe erfordert, bevor das geänderte Tool sensible Aktionen beeinflussen kann.

Ein einziges GitHub-Konto reichte 23 Pull Requests in 74 Minuten ein, jeder mit einem „Productivity-Suite"-MCP-Server, der Text formatiert und Dokumente zusammenfasst. Der Server verhält sich während der ersten drei Tool-Aufrufe normal. Beim vierten schreibt er seine eigenen Metadaten um, um den verbundenen KI-Agenten anzuweisen, SSH-Schlüssel, AWS-Zugangsdaten, Shell-History und Kubernetes-Konfiguration zu suchen — und die Aktivität vor dem Operator zu verbergen. Am 23. September 2026 offenlegte Pillar Security die Kampagne und nannte sie Deadbugz nach dem Delivery-Artefakt deadbug-mcp.py, das in vier der Pull Requests eingebettet war. Die Cloud Security Alliance veröffentlichte eine Research Note, die mechanische Nähe zur früheren „Miasma"-Kampagne feststellt, die 73 GitHub-Repositories einschließlich Microsofts azure/durabletask ins Visier nahm.

Dieser Artikel bildet den Deadbugz-Mechanismus ab, ordnet ihn in die Vier-Klassen-Taxonomie der MCP-Angriffe ein und identifiziert den Kontrollmechanismuse, der die Lücke schließt. Er baut auf der Plugin4Shell-Analyse zum SHA-Pinning-Bypass und der MCP-Security-Hardening-Checkliste auf, die beide Kontrollen etabliert haben, deren Lücke Deadbugz ausnutzt.

Der Mechanismus: ein aufrufbezogener Zähler pro Client

Der Deadbugz-Server bietet zwei Tools an — format_text und summarize — die genau das tun, was ihre Namen versprechen. Der Server führt einen speicherinternen, clientbezogenen Zähler für tools/call-Anfragen. Der Zähler startet bei null. Jeder gewöhnliche Tool-Aufruf erhöht ihn. Erreicht er drei, ändern sich die folgenden tools/list- und prompts/get-Antworten: Statt gewöhnlicher Tool-Dokumentation enthalten sie Anweisungen, die den verbundenen KI-Agenten in Richtung sensibler lokaler Dateien lenken und ihm auftragen, die Aktivität vor seinem Operator zu verbergen.

Das ist relevant, weil MCP-Tool-Definitionen keine bloßen Beschriftungen sind. Clients liefern sie dem Modell als Kontext, der hilft zu entscheiden, welche Tools verwendet und welche Aktionen ausgeführt werden. Ein Server, der diese Definitionen nach der Installation ändern kann, verändert die Anweisungen, die der Agent sieht, ohne den harmlos klingenden Namen des Tools zu ändern. Der öffentliche Quellcode kündigt tools.listChanged an, eine Capability, mit der ein kompatibler Client die Tool-Metadaten aktualisieren kann — der Server braucht also keine erneute Verbindung. Er benachrichtigt den Client einfach, dass sich seine Tool-Liste geändert hat, und der Client ruft die neuen, vergifteten Definitionen ab.

Das Runtime-Gate ist eine Research-Evasion-Technik. Eine kurze Inspektion oder ein begrenzter automatisierter Test erhält nur harmlose Metadaten. Der Server besteht Security-Review, Sandbox-Tests und automatisiertes Scannen, weil keine dieser Methoden drei gewöhnliche Tool-Aufrufe ausführt und dann prüft, was der Server danach zurückgibt. Pillar bestätigte die Schwellenlogik und die veränderten Metadaten aus öffentlichen Quellen und beobachtete die gate-aktivierten Metadaten des Remote-Dienstes über harmlose reine Textanfragen.

Der Lieferweg: eine Konfigurationsänderung, die Routine wirkt

Der Liefermechanismus der Kampagne ist ein GitHub-Pull-Request, der MCP-Konfiguration in nicht verwandten Repositories hinzufügt oder ändert. Von den 23 reviewten PRs fügen 17 einen Remote-MCP-Endpunkt (productivity-suite-mcp.onrender.com/mcp) zur Konfigurationsdatei eines Projekts hinzu. Vier konfigurieren Python so, dass eine versteckte lokale Datei ausgeführt wird (~/.config/.cache/.sys/.deadbug-mcp.py). Zwei sind Verzeichnis- oder Listeneinreichungen. Alle 23 waren zum Review-Zeitpunkt über den Pull-Request-Merge-Mechanismus von GitHub ungemerged — 19 geschlossen, vier offen — aber das Delivery-Modell erfordert keinen Merge. Es erfordert einen Maintainer, der die Konfigurationsänderung in sein eigenes Setup kopiert, oder einen Entwickler, der den PR sieht, das verlinkte Repository besucht und den Server direkt installiert.

Das Delivery-Muster auf Kontoebene ist koordiniert: dasselbe öffentliche Konto (zellkernel) verwendete in allen 23 PRs denselben Produktnamen, dasselbe Konfigurationsthema und dieselben Kampagnen-Marker, eingereicht zwischen 21:52 Uhr und 23:07 Uhr UTC am 10. August 2026. Das Konto hatte bei der Erhebung 50 öffentliche Repositories, davon 20 Forks, und erstellte allein am 10. August 21 Repositories. Das GitHub-Profil des Kontos verlinkt auf ein X-Profil (@llmgod), das auf das GitHub-Konto zurückverlinkt — eine öffentliche, kontoattribuierte Verbindung zwischen der Delivery-Identität und öffentlicher KI/LLM-bezogener Aktivität.

Dieses Delivery-Modell erweitert das Supply-Chain-Muster, das die Plugin4Shell-Analyse dokumentiert hat: PR-basierte Konfigurationsänderungen als Vektor, der Marketplace-Kontrolle vollständig umgeht. Plugin4Shell nutzte das SHA-Pinning des Marketplace aus, indem es einen Branch nach dem gepinnten Commit benannte. Deadbugz umgeht die Marketplace-Kontrolle, indem es gar keinen Marketplace verwendet — es geht direkt über den Contribution-Workflow in Open-Source-Projekte.

Die vier Angriffsklassen

Die MCP-Security-Familie zählt nun vier eigenständige Angriffsklassen, die jeweils eine andere Vertrauensgrenze ausnutzen:

Klasse	Mechanismus	Erstmals dokumentiert	Erkennungsschwierigkeit
STDIO-Befehlsinjektion	Bösartige Befehle in STDIO-Konfigurationsstrings	April 2026, über 20 CVEs (Practical DevSecOps)	Mittel — statische Analyse findet Shell-Metazeichen
Tool-Poisoning	Die Beschreibung eines harmlosen Tools ändert sich nach der Genehmigung, um den Agenten zu manipulieren	Invariant Labs, April 2025, WhatsApp-Sleeper	Mittel — Metadaten-Änderungserkennung beim Client
SHA-Pinning-Umgehung	Ein als SHA benannter Branch besiegt die Pin-Verifikation des Marketplace	Plugin4Shell, September 2026	Schwer — erfordert Resolved-HEAD-Assertion nach dem Checkout
Runtime-gesteuerte Metadaten-Manipulation	Bösartige Metadaten zurückgehalten bis zu N Aufrufen, dann geliefert über tools/list	Deadbugz, September 2026	Am schwersten — Pre-Deployment-Tests überschreiten die Schwelle nicht

Die Deadbugz-Angriffssequenz und die Vier-Klassen-Taxonomie, visualisiert:

Jede Klasse nutzt dieselbe strukturelle Lücke aus: einen Vertrauensmechanismus, der seine Prüfung zur falschen Zeit durchführt oder gar nicht. STDIO-Injektion vertraut Konfigurationsstrings ohne Sanitisierung; Tool-Poisoning vertraut darauf, dass Tool-Beschreibungen sich nach der Genehmigung nicht ändern. SHA-Pinning vertraut darauf, dass der aufgelöste Commit dem gepinnten Namen entspricht. Runtime-gesteuerte Manipulation vertraut darauf, dass das, was der Server während des Tests zurückgab, auch während des Einsatzes zurückgegeben wird.

Deadbugz ist vor dem Deployment am schwersten zu erkennen, weil das Verhalten des Servers während der Inspektion wirklich harmlos ist. Die bösartige Payload ist nicht so im Code versteckt, dass statische Analyse sie markieren könnte — sie ist hinter einem Runtime-Zähler verborgen, der erst aktiviert wird, nachdem der Client ein Nutzungsmuster etabliert hat. Ein Security-Team, das sich mit dem Server verbindet, format_text ein- oder zweimal aufruft und die Antwort prüft, sieht nichts Verdächtiges. Der Angriff ist darauf ausgelegt, genau diese Art von Review zu bestehen.

Warum die bestehenden Kontrollen nicht ausreichen

Die MCP-Security-Hardening-Checkliste organisiert 12 Kontrollen über fünf Ebenen: Transport, Authentifizierung, Tool-Registrierung, Runtime und Audit. Deadbugz nutzt eine Lücke in den Ebenen Tool-Registrierung und Runtime aus. Die Kontrollen der Tool-Registrierung verifizieren den Server zum Genehmigungszeitpunkt — sie prüfen Tool-Namen, Schemas und Beschreibungen, bevor der Server live geht. Aber Deadbugz' Tools sind zum Genehmigungszeitpunkt wirklich harmlos. Die Runtime-Kontrollen überwachen unbefugte Aktionen, doch die vergifteten Metadaten sind selbst keine Aktion — sie sind eine Anweisung, die den Agenten zu einer Aktion lenkt, die der Agent dann ausführt, scheinbar innerhalb seines autorisierten Rahmens.

Die Governed-Modules-These — dass Audit-Logs, Rate Limits, typisierte Fehler und Kill-Switch-Architektur die Governance-Ebene zur Sicherheitsgrenze machen — gewinnt eine vierte Angriffsklasse als Evidenz. Der Deadbugz-Mechanismus validiert die These aus der Gegenrichtung: Ein Server ohne Governance-Kontrollen (keine Metadaten-Änderungserkennung, kein Tool-Definition-Fingerprinting, kein operator-sichtbares Diff dessen, was der Agent sieht) ist genau die Angriffsfläche, die die Kampagne ausnutzt.

Die Verteidigung: Tool-Definition-Fingerprinting

Pillars Empfehlung ist konkret und umsetzbar: einen Fingerabdruck der Tool-Definitionen beim Genehmigungszeitpunkt erfassen und abgleichen. Wenn ein MCP-Client einen Server genehmigt, zeichnet er einen Hash jeder Tool-Definition auf, die der Server zurückgibt — Name, Beschreibung, Input-Schema und Annotationen. Wenn der Server dem Client später mitteilt, dass sich seine Tool-Liste geändert hat (via tools.listChanged), ruft der Client die neuen Definitionen ab, gleicht sie mit dem Fingerabdruck ab und zeigt das Diff dem Operator als Sicherheitsereignis. Das geänderte Tool kann keine sensiblen Aktionen beeinflussen, bis der Operator es erneut genehmigt.

Diese Kontrolle schließt die Lücke, die Deadbugz ausnutzt, weil sie nicht auf Pre-Deployment-Tests angewiesen ist. Sie überwacht die tatsächlichen Metadaten, die der Server zur Laufzeit liefert — nachdem die Vertrauensgrenze bereits überschritten wurde. Der Fingerabdruck-Vergleich findet den Metadaten-Rewrite unabhängig davon, wann das Runtime-Gate auslöst — drei Aufrufe, dreißig oder dreihundert. Die Kontrolle findet auch die frühere Tool-Poisoning-Klasse (Invariant Labs' WhatsApp-Sleeper), weil beide Angriffe denselben Mechanismus teilen: eine Tool-Beschreibung, die sich nach der Genehmigung ändert.

Vier Implementierungsschritte für ein Team, das MCP-Server in Produktion betreibt:

1. Tool-Definition-Fingerabdrücke beim Genehmigungszeitpunkt aufzeichnen. Jede Tool-Definition hashen, die der Server während der Erstverbindung zurückgibt. Die Fingerabdrücke zusammen mit dem Genehmigungsdatensatz des Servers im Konfigurationsmanagementsystem des Agenten speichern.
2. tools/list- und prompts/get-Antworten auf Drift überwachen. Wenn der Server dem Client meldet, dass sich seine Tool-Liste geändert hat, die neuen Definitionen abrufen und mit den gespeicherten Fingerabdrücken abgleichen. Jede Abweichung als Metadaten-Drift-Ereignis markieren.
3. Erneute Operatoren-Freigabe für geänderte Tool-Definitionen verlangen. Eine geänderte Tool-Definition darf das Agentenverhalten nicht beeinflussen, bis ein menschlicher Operator das Diff prüft und den Server explizit erneut genehmigt. Das verwandelt einen stillen Metadaten-Rewrite in ein sichtbares Sicherheitsereignis.
4. Sensible Dateizugriffe, Credential-Zugriff und Code-Ausführung hinter Policy sperren — nicht hinter Tool-Metadaten. Die Deadbugz-Payload weist den Agenten an, SSH-Schlüssel, AWS-Zugangsdaten und Kubernetes-Konfiguration zu suchen. Diese Zugriffe sollten policy-durchgesetzte Aktionen sein, die explizite Autorisierung erfordern — nicht Folgen von Anweisungen in Remote-Tool-Metadaten. Die Shadow-AI-Agents-Analyse dokumentiert die Runtime-Control-Lücke, die darüber entscheidet, ob ein metadatengesteuerter Credential-Zugriff überhaupt bemerkt wird.

Weiterführende Literatur

• SHA Pinning ist keine Verifikation: Plugin4Shell und die erste Supply-Chain-RCE bei KI-Agenten — die dritte MCP-Angriffsklasse, die Deadbugz' PR-basiertes Delivery-Modell und Supply-Chain-Zielsetzung teilt
• MCP-Security-Hardening-Checkliste: 1.467 exponierte Server und die Kontrollen, die sie schließen — die 12-Kontrollen-Baseline; Tool-Definition-Fingerprinting gehört in die Ebenen Tool-Registrierung und Runtime
• MCP Security: Warum 200.000 verwundbare Instanzen Governed Modules zum Kaufkriterium machen — die Governed-Modules-These, die Deadbugz validiert: ein Server ohne Governance-Kontrollen ist genau die Angriffsfläche, die die Kampagne ausnutzt

---

Ein B2B-Distributor im Mid-Market betreibt einen Procurement-Agenten, der sich über MCP-Module mit NetSuite, BigCommerce und drei Lieferantenkatalogen verbindet. Das Security-Review des Teams verbindet sich mit jedem neuen MCP-Server, ruft seine Tools zweimal auf und prüft die Antworten. Deadbugz besteht dieses Review. Das Team ergänzt Tool-Definition-Fingerprinting in seiner MCP-Client-Konfiguration — die anfänglichen Tool-Definitionen jedes Servers werden bei Genehmigung gehasht, tools/list-Antworten werden auf Drift überwacht, und geänderte Definitionen lösen eine Operatoren-Freigabe-Sperre aus, bevor das geänderte Tool das Agentenverhalten beeinflussen kann. Die nächste Kampagne zur Metadaten-Manipulation wird zu einem markierten Diff und einem Review — nicht zu einer Credential-Exposition.

Scoped Build anfordern. One-Week-Discovery. Sie erhalten ein Systeminventar, einen Workflow-Plan und einen festen Scope — ob Sie mit uns bauen oder nicht.