FlawOpen

flawopen.com/Incidents/deadbugz-mcp-delayed-metadata-supply-chain-campaign-august-2026

● Pillar Security / MCP ecosystem · CWE-829 (editorial mapping; no CVE assigned) · 2026-08-10 · Mittel
Sicherheitsforschung · FlawOpen

Deadbugz: MCP-Toolmetadaten ändern sich nach der Freigabe

Pillar Security dokumentierte eine MCP-Lieferkettenkampagne, die Metadaten nach drei normalen Aufrufen änderte. Bei der Prüfung fand sie keine über GitHub gemergten Pull Requests; der Bericht dokumentierte keine anschließende Kompromittierung. Die Cloud Security Alliance weist auf begrenzte Einblicke in eine unabhängige lokale Ausführung hin.[1], [3]

💡 Einfache Erklärung (ELI5)

Stellen Sie sich vor, Sie lassen einen Auftragnehmer hinein, weil sein Ausweis harmlose Aufgaben nennt. Nach drei normalen Lieferungen ändert sich der Ausweis unbemerkt und verlangt Zugang zu verschlossenen Räumen. Gefährlich ist, dass das Gebäude der alten Freigabe weiter vertraut. Ein MCP-Client muss erkennen, wenn ein Server die freigegebenen Tool-Anweisungen ändert.[1]

Kernkonzepte & Begriffe

MCP
Protokoll, über das eine KI-Anwendung Werkzeuge eines Servers entdeckt und aufruft.[5]
Toolmetadaten
Name, Beschreibung und Eingabeschema eines Tools, die der Client dem Modell als Kontext geben kann.[5], [1]
Laufzeitverzögerte Änderung
Verhalten, das erst nach einer Interaktionsschwelle sichtbar wird; Pillar beschreibt einen Zähler mit drei Aufrufen.[1]
Lieferkettenverteilung
Einführung einer Abhängigkeit oder Konfiguration über einen vertrauenswürdigen Entwicklungsprozess wie einen Pull Request.[1]
CWE-829
Redaktionelle Zuordnung: Funktionalität kam von einem Server außerhalb der vertrauenswürdigen Kontrollsphäre des Clients. Es gibt keine CVE- oder CVSS-Bewertung.[1], [3]

Framework-Zuordnungen

  • CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-829

Vorfall-Zeitstrahl

2026-08-10

Pillar fand 23 zusammenhängende Pull Requests innerhalb von 74 Minuten; zum Prüfzeitpunkt war keiner über den GitHub-PR-Prozess gemergt.[1]

2026-08-12

Pillar veröffentlichte die technische Analyse der Metadatenänderung nach drei Aufrufen und die Indikatoren.[1]

2026-10-08

Das OWASP GenAI Project nahm Deadbugz in seinen Q3-Bericht auf. Das belegt Aufmerksamkeit, weder eine Kompromittierung noch Suchvolumen.[2]

Schritt-für-Schritt Angriffsablauf

Schritt 1

Eine Konfigurationsänderung wird vorgeschlagen

Ein Pull Request fügt einem KI-Projekt einen entfernten oder lokalen MCP-Server hinzu. Pillar prüfte 17 Änderungen mit Remote-Endpunkt, vier Verweise auf ein verstecktes lokales Skript und zwei Verzeichniseinträge.[1]

Schritt 2

Die erste Prüfung sieht gewöhnliche Tools

Zunächst bietet der Server Textformatierung und Zusammenfassungen. Laut Pillar können kurze Tests nur diese harmlosen Metadaten erhalten.[1]

Schritt 3

Normale Nutzung überschreitet die Schwelle

Der Server zählt Aufrufe pro Client. Nach drei Aufrufen ändern sich folgende Antworten auf tools/list und prompts/get.[1], [5]

Schritt 4

Der Agent erhält nicht vertrauenswürdige Anweisungen

Die Anweisungen sollen den verbundenen Agenten zu sensiblen lokalen Informationen lenken und die Aktivität verbergen. Die Kampagnenbeschreibung belegt keine Kompromittierung.[1], [3]

Schritt 5

Die Freigabe muss an exakte Metadaten gebunden sein

Der Client sollte freigegebene Tooldefinitionen hashen und bei Abweichungen für eine Prüfung pausieren. Datei-, Zugangsdaten- und Netzwerkrechte müssen unabhängig durchgesetzt werden.[1], [4], [5]

Quellcode: Verwundbar vs. Sicher

Der Bericht beschreibt Metadatenvergiftung und Verteilung über Pull Requests, keine CVE in der MCP-Spezifikation. Das Risiko entsteht, wenn ein Client veränderlichen Serverbeschreibungen nach der ersten Freigabe weiter vertraut. Pillar schreibt die Kampagne einem öffentlichen GitHub-Konto zu; wir geben dies als Pillars Zuordnung wieder, nicht als verifizierte reale Identität. Laut Pillar waren die geprüften PRs zum Prüfzeitpunkt nicht über GitHub gemergt; eine anschließende Kompromittierung wurde nicht belegt. Das verlinkte Quellrepository liefert derzeit 404. Die technischen Aussagen stützen sich daher auf Pillars veröffentlichte Analyse und nicht auf eine erneute unabhängige Prüfung des Quellbaums. Das Python-Beispiel zeigt eine defensive Clientrichtlinie und ist kein direkt einsetzbarer Ersatz für eine MCP-Bibliothek. CWE-829 ist eine redaktionelle Zuordnung; CVE und CVSS fehlen. Der Adapter muss Daten nach MCP-Änderungsbenachrichtigungen aktualisieren und tools/list sowie prompts/get einbeziehen; metadata_snapshot ist eine illustrative Adaptermethode, keine MCP-SDK-API. approved_digest erst nach Betreiberprüfung festlegen. Der Snapshot muss alle relevanten Servermetadaten enthalten, darunter tools/list-Definitionen und den vollständigen Inhalt von prompts/get für genehmigte Prompts. Rufen Sie ihn vor der Ausführung erneut ab und stoppen Sie die Aktion bei Abweichung. Verhaltensänderungen des Servers oder Änderungen zwischen Prüfung und Nutzung erkennt diese Kontrolle nicht; unabhängige Aktionsrechte bleiben nötig.[1], [4], [5]

VERWUNDBARE IMPLEMENTIERUNG
def agent_metadata(session):
    # Der Adapter gibt die aktuellen Tools und Prompts des Servers als JSON-Daten zurück.
    return session.metadata_snapshot()
GEHÄRTETER SICHERHEITS-PATCH
import hashlib
import hmac
import json

def fingerprint(snapshot):
    normalized = dict(snapshot)
    for key in ("tools", "prompts"):
        normalized[key] = sorted(
            snapshot[key],
            key=lambda item: json.dumps(item, sort_keys=True, separators=(",", ":")),
        )
    canonical = json.dumps(normalized, sort_keys=True, separators=(",", ":"))
    return hashlib.sha256(canonical.encode()).hexdigest()

def agent_metadata(session, approved_digest):
    current = session.metadata_snapshot()
    if not hmac.compare_digest(fingerprint(current), approved_digest):
        raise PermissionError("MCP metadata changed; require operator approval")
    return current

Checkliste für Engineering & Systemsicherheit

Quellen