Cyberbedrohungen
MCP Server-Schwachstelle unterwandert KI-Agenten
Ein SQL Injection-Bug im SQLite-MCP-Server von Anthropic mit vielen Forks kann gespeicherte Prompts ermöglichen und Angreifern die Schlüssel zu ganzen Agenten-Workflows übergeben. Wir erklären die Schwachstelle, ihre Auswirkungen und Schutz davor.
Save to Folio
Wichtigste Erkenntnisse
- Ein anfälliger SQLite MCP-Server von Anthropic könnte ungepatchten Code über Forks an Tausende nachgelagerte Agenten weitergegeben haben - viele davon wahrscheinlich in der Produktion. Es besteht SQL Injection-Risiko.
- Herkömmliche SQL Injection eröffnet einen neuen Weg zur gespeicherten Prompt-Injection, über die Angreifer KI-Agenten direkt manipulieren.
- Die SQL Injection-Schwachstelle ermöglicht die Ausweitung von Privilegien durch implizites Vertrauen in Workflows. KI-Agenten vertrauen häufig auf interne Daten, und ein Angreifer kann dieses ausnutzen, indem er einen Prompt einbettet, der Agenten später mächtige Tools (E-Mail, Datenbank, Cloud-APIs) aufrufen lässt, um Daten zu stehlen oder sich lateral zu bewegen, wobei er frühere Sicherheitsüberprüfungen umgeht.
- Ein Patch ist nicht geplant, so dass Entwickler Korrekturen selbst implementieren müssen. Unternehmen, die ungepatchte Forks verwenden, setzen sich einem erheblichen Betriebsrisiko aus.
Trend™ Research hat eine einfache, aber gefährliche Lücke aufgedeckt: eine klassische SQL Injection (SQLi)-Schwachstelle in der Referenz-Serverimplementierung des SQLite Model Context Protocols (MCP) von Anthropic. Bevor das GitHub-Repository am 29. Mai 2025 archiviert wurde, war es bereits mehr als 5000 Mal geforkt oder kopiert worden. Der Code ist eindeutig als Referenzimplementierung benannt und nicht für den Produktionseinsatz gedacht.
Anfälliger Code erlaubt es potenziellen Angreifern, nicht autorisierte Befehle auszuführen, bösartige Prompts einzuschleusen, Daten zu stehlen und Workflows von KI-Agenten zu kapern.
Wo liegt die Sicherheitslücke?
Die Schwachstelle liegt in der Art und Weise, wie der Quellcode mit Nutzereingaben umgeht. Diese werden unbereinigt direkt zu einer SQL-Anweisung verknüpft, die dann später vom Python-Treiber sqlite3 ausgeführt wird - ohne Filterung oder Validierung. Diese Lücke stellt ein ernsthaftes Sicherheitsrisiko dar und schafft die perfekten Bedingungen für SQL Injection (SQLi), bei der ein Angreifer bösartige Abfragen in das System einbetten kann.
Das OWASP Cheat Sheet zur Verhinderung von SQL-Injections enthält seit über einem Jahrzehnt dieselbe Empfehlung #1 -- Verwenden Sie parametrisierte Abfragen. Diese verhindern von vornherein SQLi-Angriffe, da die Datenbank zwischen Code und Daten unterscheiden kann. Anderenfalls ist der gesamte Katalog klassischer SQL-Angriffe möglich - Umgehung der Authentifizierung, Datenexfiltrierung, Manipulationen und sogar beliebige Datei-Schreiboperationen über Tricks mit virtuellen SQLite-Tabellen.
Eine einfache SQ Injection kapert einen Support-Bot
Wir haben ein Beispiel aufgesetzt, in dem ein KI-Support-Agent Tickets von einem SQLite-MCP-Server zieht. Kunden reichen Tickets über ein Webformular ein, während ein privilegierter Supporttechniker (oder Bot) alle als offen markierten Tickets sortiert.
Bild 1. Angriffsdiagramm, wie eine SQL Injection zu einer gespeicherten Prompt Injection und einer Datenexfiltration in ein privilegiertes Konto führt.
- Der Angreifer sendet das Ticket ein: Der eingeschleuste Inhalt schließt eine erste SQL-Anweisung mit einem gefälschten Support-Ticket-Eintrag ab und erstellt einen neuen Eintrag mit einer bösartigen gespeicherten Prompt.
- Der bösartige Prompt wird über den anfälligen SQLite MCP-Server gespeichert. Dies ist das LLM-Äquivalent eines gespeicherten XSS-Angriffs, gemeinhin als gespeicherte Prompt Injection bezeichnet, ein bekanntes Top-Risiko in LLM-Umgebungen. Die Schwachstelle im SQLite MCP-Server ermöglicht es dem Agenten, böswillige Prompts im Status „offen“ zu speichern und so alle Backend-Sicherheitsvorkehrungen zu umgehen, die „ausstehende Tickets“ gegen Prompt Injection sortieren. Während der Triage durch KI-Agenten behandelt ein Support-Techniker oder -Bot das Ticket mit den gespeicherten bösartigen Prompts, als wäre es ein gültiger Eintrag.
- Das KI-Modell folgt den Anweisungen im Prompt: Der gespeicherte Prompt veranlasst das LLM, interne Tools aufzurufen, z. B. einen Mail-Client oder einen anderen MCP-Server, der in einem privilegierten Kontext verfügbar und zulässig ist. Da das Mail MCP-Tool mit höheren Rechten arbeitet und der Triage-Workflow jedem als „offen“ markierten Ticket blind vertraut, kann ein einzelner injizierter Prompt in Kombination mit einer gespeicherten Prompt Injection das System durch laterale Bewegungen oder Datenexfiltration kompromittieren.
In einer KI-Agentenumgebung auf Basis eines zum Speichern und Abrufen von Informationen genutzten MCP-Servers, ist ein scheinbar trivialer SQLi-Fehler nicht mehr nur ein Fehler auf der Datenebene, sondern wird zum Sprungbrett für eine gespeicherte Prompt Injection, die den Agenten dazu bringt, privilegierte Aktionen auszuführen, Datendiebstahl zu automatisieren und laterale Bewegungen durchzuführen.
Wir haben das Problem am 11. Juni 2025 privat an Anthropic gemäß den Richtlinien zur verantwortungsvollen Offenlegung weitergegeben. Anthropic antwortete, es handle sich bei dem Repository um eine archivierte Demo-Implementierung, und die Schwachstelle sei daher als „außerhalb des Anwendungsbereichs“ zu betrachten. Zum jetzigen Zeitpunkt ist laut GitHub issue #1348 kein Patch geplant. Darüber hinaus wurden auch alle Referenzimplementierungen von Anthropic archiviert.
Quick-Fix-Checkliste
Da kein offizieller Patch für das archivierte Repository geplant ist, liegt die Aufgabe, ihre Implementierungen vor dieser Schwachstelle zu schützen, weitgehend bei den Entwicklern und Teams. Wir haben eine Quick-Fix-Checkliste für die Identifizierung und das Patchen der Schwachstelle in eigenen Forks oder Implementierungen des SQLite MCP-Servers zusammengestellt:
- Fixen Sie den verwundbaren SQLite MCP-Server manuell, indem Sie f-Strings durch Platzhalter ersetzen: Prüfen Sie, ob Sie den sqlite MCP-Server von Anthropic vor dem 29. Mai 2025 geforkt haben oder ob Sie eine archivierte Version verwenden.
- Whitelist von Tabellennamen für SELECT ... FROM {table}-Konstrukte.
- Verbieten Sie Anweisungs-Stacks über die sqlite3-Konfiguration
- Überwachen Sie auf anomale Prompts, die Ihre LLM-Grenzen überschreiten.
Einzelheiten dazu finden Sie im Originalbeitrag.
Fazit und Empfehlungen
Klassische Fehler bei der Input-Bereinigung bleiben nicht auf die Datenschicht beschränkt, wenn sie sich hinter einem KI-Agenten befinden. Eine einzige, nicht parametrisierte Zeichenfolge in einem MCP-Server kann Tausende von nachgelagerten Forks durchlaufen, in proprietären Code Bases landen und schließlich automatisierte Workflows in einem privilegierten Kontext auslösen. Wenn es einem Angreifer gelingt, ein SQLi in eine Stored Prompt Injection zu verwandeln, kann jeder nachfolgende LLM-Aufruf durch die Anweisungen des Angreifers gesteuert werden - sei es beim Lesen von Kundendatensätzen, beim Abschicken von E-Mails oder beim Eindringen in benachbarte Systeme.
Um diese Lücke zu schließen, sind disziplinierte Codierungsstandards, eine automatisierte Überwachung der Supply Chain- und Laufzeit-Guardrails erforderlich, wobei davon ausgegangen wird, dass jeder gespeicherte Inhalt, unabhängig von seiner Herkunft, schädlich sein könnte.
Best Practices können dabei helfen, Schwachstellen zu verhindern:
- OWASP-Spickzettel zur Verhinderung von SQL-Injection. Die OWASP empfiehlt seit langem parametrisierte Abfragen als Schutzmaßnahme # 1 gegen SQLi. Dies sollte als grundlegende Praxis behandelt werde,.
- Prüfen Sie die Arbeitsabläufe von KI-Agenten auf versteckte vertrauenswürdige Annahmen. Wenn KI-Agenten interne Daten standardmäßig als sicher behandeln, sind sie möglicherweise anfällig für gespeicherte Prompt Injection. Überprüfen Sie, wann und wie KI vom Nutzer generierte oder im System gespeicherte Eingaben liest, interpretiert und darauf reagiert.
- Schränken Sie den Tool-Zugriff in privilegiertem Kontext ein. KI-Agenten sollten keinen uneingeschränkten Zugriff auf Tools wie Mail, Dateisysteme oder externe APIs haben. Führen Sie Überprüfungsschritte, Genehmigungen oder Sandboxing ein, um die Auswirkungen im Falle eines Missbrauchs zu begrenzen.
- Überwachen Sie auf Anomalien. Achten Sie auf verdächtige Prompts, unerwartete SQL-Befehle oder ungewöhnliche Datenflüsse, z. B. ausgehende Mails, die von Agenten außerhalb der Standard-Workflows ausgelöst werden.