01
SaaS mit KI-Assistent
Sie geben einem Agenten Tools an die Hand, die auf echte Daten und Systeme zugreifen.
Wir haben 37 reale, populäre MCP-Server geprüft, darunter offizielle Server großer Cloud- und Dev-Anbieter. Fast alle hatten echte, ausnutzbare Lücken: von Befehlsausführung auf dem Host über Datenabfluss bis zu „Sicherheits"-Kontrollen, die sich umgehen lassen. Bei null Fehlalarmen. Hier sind die zehn Klassen, die immer wieder auftauchen, und wie Sie sie bei sich finden, bevor es ein Angreifer tut.
Jeder Server wurde nach demselben Verfahren geprüft: Angriffsfläche kartieren, gezielt nach den MCP-typischen Schwachstellen suchen, jeden Fund adversarial gegenprüfen und nur behalten, was einen konkreten, ausnutzbaren Pfad hat. Was wir nicht beweisen können, melden wir nicht.
Sortiert nach Häufigkeit und Schwere in unserer Prüfung. Acht davon findet kein generischer Scanner: die Lücke steckt nicht in „bekannt-schlechtem Code", sondern darin, welche Fähigkeit wem in die Hand gegeben wird.
Der Server bindet einen HTTP-Endpoint ohne jede Authentifizierung und vertraut auf „läuft ja nur lokal". Dann erreicht ihn jeder lokale Prozess, oder über eine CORS-/DNS-Rebinding-Lücke sogar eine bösartige Webseite, und steuert alle Tools mit den vorab authentifizierten Rechten des Servers (DB-Verbindung, API-Token, angemeldete Browser-Session). Klassischer Confused Deputy.
Prüfen: Auth auf jedem Transport-Eingang? Origin/Host exakt validiert (kein startsWith)? Standard-Bind auf 127.0.0.1?
Tools geben nicht-vertrauenswürdige Inhalte (Webseiten, Repo-Dateien, DB-Zeilen, Tickets) wörtlich in den Agenten-Kontext zurück. Ein manipuliertes Dokument schmuggelt Anweisungen ein, die das Modell dann mit den Schreib-, Exec- oder Fetch-Tools desselben Servers ausführt. Privater Datenzugriff plus fremder Inhalt plus ein Ausgangskanal, die „lethal trifecta".
Prüfen: Wird fremder Tool-Output als Daten markiert und abgegrenzt? Kann er ein zustandsänderndes oder Egress-Tool auslösen?
Server, die eine Schutzmaßnahme bewerben, deren Umsetzung umgehbar ist: eine Kommando-Whitelist, eine Code-Sandbox, ein Read-only-Modus. Wir haben Whitelists über Tool-eigene Exec-Flags gebrochen, Sandboxes über Introspektion und einen Read-only-DB-Modus über Unicode-Whitespace. Der Betreiber verlässt sich genau darauf, um einen Agenten sicher anzuschließen.
Prüfen: Die Kontrolle direkt angreifen. Strukturell durchsetzen, nicht per Textprüfung.
Ein Tool holt eine vom Agenten gelieferte URL ohne Schema-/Host-Allowlist und ohne Sperre für private oder Metadaten-Adressen, und gibt den Body wörtlich zurück (lesbare SSRF, offener Proxy). In der Cloud eskaliert das zum Diebstahl von Instanz-Credentials.
Prüfen: Lässt sich ein Tool auf 169.254.169.254, interne Hosts oder file:// richten? Fail-closed?
Vom Agenten kontrollierte Eingaben erreichen exec/eval/os.system oder eine Sandbox, die keine ist. Ergebnis: beliebige Befehlsausführung auf dem Host oder im Container, oft mit vollen Rechten des Servers.
Prüfen: Nie Agenten-Eingabe in eine Shell. Echte Isolierung, kein „vm" als Grenze.
Tools, die weit mehr können als der Anwendungsfall braucht: volles Dateisystem, beliebiges SQL, beliebige Navigation. Ein einziger Fehlgebrauch oder eine Injection wird dadurch katastrophal.
Prüfen: Jedes Tool auf das Minimum scopen, mächtige Tools hinter explizites Opt-in.
Betreiber-Credentials landen in der Umgebung einer Sandbox neben fremdem Code, Tokens in Logs oder Antworten, TLS-Prüfung auf credential-tragenden Verbindungen deaktiviert.
Prüfen: Aufrufe host-seitig brokern, damit Secrets nie neben untrusted Code liegen. Nie TLS-Prüfung abschalten.
Bind auf 0.0.0.0, Wildcard-Hosts, DNS-Rebinding-Schutz aus, Sandbox-Bypass-Flags an, Default-Admin-Zugänge. Sicher nur für einen Betreiber, der alles nachträglich abdichtet, die meisten tun das nicht.
Prüfen: Safe-by-default. Gefährliche Modi nur per explizitem Opt-in, notfalls Start verweigern.
Vom Agenten gelieferte Pfade entkommen dem konfigurierten Wurzelverzeichnis (../, absolute Pfade, Symlinks, Normalisierungs-Lücken). Die sorgfältigen Server sichern das ab, der lange Rest nicht.
Prüfen: Kanonisieren plus commonpath-Containment, Symlinks ablehnen, nach der Normalisierung prüfen.
Unvalidierte Eingabe erreicht eine panickende API, unbegrenztes Puffern von Ergebnissen, keine Timeouts, keine Panic-Recovery, ein einziger schlechter Aufruf legt den ganzen Server lahm.
Prüfen: Eingaben validieren, fehlerrückgebende APIs, Ergebnisse deckeln/streamen, Timeouts, Prozess-Recovery.
Acht dieser zehn Klassen sind für Standard-Scanner unsichtbar, weil nichts daran „bekannt-schlechter Code" ist: der Fehler liegt darin, welche Fähigkeit wem gegeben wird. Das Muster ist über unverwandte Projekte hinweg so konstant, dass es sich zu einer Checkliste verdichten lässt. Genau die fährt ein AI/MCP Security Snapshot, und laufend ein Continuous Security Desk.
Sie geben einem Agenten Tools an die Hand, die auf echte Daten und Systeme zugreifen.
Ihr Server wird von fremden Agenten angesprochen, deren Verhalten Sie nicht kontrollieren.
Automatisierung mit Zugriff auf Cloud, Code, Datenbanken, Postfächer.
Der Security-Fragebogen zum KI-Feature kommt, bevor Sie ihn erwarten.
In einem kostenlosen Erstgespräch benennen wir die kritischen Tools Ihres MCP-Servers und zeigen an einem echten Befund, wo Ihr agentisches Feature angreifbar ist. Kein Verkaufsgespräch, ein technischer Blick.
Die ehrliche Grenze. Diese Studie ist ein Code-Review populärer Open-Source-MCP-Server; kein Live-Dienst wurde angegriffen, und alle konkreten Funde durchlaufen eine koordinierte, verantwortungsvolle Offenlegung an die jeweiligen Maintainer, bevor Details öffentlich werden. Ein „sauber" heißt „kein Befund auf dem, was wir geprüft haben", nie „bewiesen sicher". Wir untertreiben lieber, als ein grünes Licht zu geben, das keines ist.