Start / Themen / Digitalisierung & KI / Antwort
Digitalisierung & KI

Dokumentierte Sicherheitsvorfälle bei KI-Agenten, MCP-Servern und OAuth-Integrationen

Kurz gesagt

Zwischen 2022 und 2026 sind mehrere dokumentierte Vorfälle rund um vernetzte KI- und Integrationssysteme belegt: unauthentisierte Codeausführung in MCP-Entwicklerwerkzeugen (2025/2026), gestohlene OAuth-Tokens bei GitHub-Drittintegrationen (2022), Vishing-Angriffe auf Salesforce Connected Apps (2025) und ein Social-Engineering-Angriff auf Retool trotz Multi-Faktor-Authentifizierung (2023). Das wiederkehrende Muster: Ein lokales Entwicklungswerkzeug oder eine Drittintegration besitzt produktionsähnliche Macht, wird aber wie ein Randthema behandelt.

MCP-Entwicklerwerkzeuge: Drei Vorfälle in kurzer Zeit

Juni 2025 — MCP Inspector: Eine fehlende Authentisierung zwischen dem Browser-Client und einem lokalen Proxy ermöglichte unauthentisierte Remote-Code-Ausführung. Der Fehler wurde mit Version 0.14.1 behoben.

Juli 2025 — mcp-remote: Ein manipulierter oder kompromittierter Autorisierungsendpunkt konnte über eine Command-Injection-Schwachstelle zur Ausführung von Befehlen führen.

Januar 2026 — MCPJam Inspector: Eine Netzwerkbindung ohne ausreichende Authentisierung ermöglichte erneut unauthentisierte Remote-Code-Ausführung. Die dazugehörige Einschätzung ist eindeutig: „Nur ein Dev-Tool" ist kein Sicherheitsargument — auch reine Entwicklerwerkzeuge laufen häufig mit weitreichenden lokalen Rechten.

Alle drei Fälle zeigen dasselbe Muster: Ein lokales Entwicklungswerkzeug besitzt produktionsähnliche Macht, wird aber seltener geprüft, aktualisiert und abgesichert als produktive Systeme.

Zwei verbreitete, aber falsche Annahmen

Zwei Mythen sollten aus diesen Vorfällen abgeleitet ausdrücklich verworfen werden: Erstens, lokale MCP-Server seien ungefährlich, weil sie nicht in der Cloud liefen — falsch, denn sie können mit den Rechten des ausführenden Nutzers auf Dateien, Prozesse und gespeicherte Zugangsdaten zugreifen. Zweitens, ein Eintrag in einer MCP-Registry sei bereits ein Sicherheitszertifikat — ebenfalls falsch: Ein Registry-Eintrag, Popularität oder Open-Source-Status ersetzen keine eigene Codeprüfung, digitale Signatur, Versionsfixierung oder Sandbox-Ausführung.

OAuth-Token-Diebstahl bei Drittintegrationen

2022 — GitHub: Gestohlene OAuth-Tokens von Drittanbieter-Integrationen ermöglichten Zugriff auf private Repositories mehrerer Organisationen.

Juni 2025 — Salesforce Connected Apps: Dokumentierte Vishing-Kampagnen (telefonisches Social Engineering) bewegten Mitarbeiter dazu, bösartige Connected Apps zu autorisieren. Anschließend griffen die Angreifer auf Unternehmensdaten zu.

August 2025 — Salesloft Drift: Kompromittierte OAuth-Tokens einer Drittintegration dienten als Brücke, um auf verbundene Salesforce-Instanzen zuzugreifen.

September 2023 — Retool: Ein Social-Engineering-Angriff führte trotz aktiver Multi-Faktor-Authentifizierung zur Kompromittierung; nach Anbieterangabe waren 27 Cloud-Kunden betroffen.

Der zentrale technische Fehler: Token-Passthrough

Eine wiederkehrende Ursache ist das sogenannte Token-Passthrough-Problem: Ein Integrations- oder MCP-Server darf ein für ihn selbst ausgestelltes Zugriffstoken nicht ungeprüft an ein nachgelagertes System weiterreichen. Tut er es doch, entsteht ein „Confused Deputy"-Problem — ein System handelt im Vertrauen auf ein Token, das eigentlich für einen anderen Zweck ausgestellt wurde. Technisch lässt sich dieses Risiko unter anderem durch Proof-of-Possession-Verfahren (etwa mTLS oder DPoP) reduzieren, die den Wert eines gestohlenen Bearer-Tokens für Angreifer deutlich senken.

Warum Multi-Faktor-Authentifizierung allein nicht reicht

Der Retool-Vorfall widerlegt einen weiteren verbreiteten Mythos: Multi-Faktor-Authentifizierung verhindere die Übernahme von Integrationskonten zuverlässig. Das ist falsch — gezieltes Social Engineering kann auch aktive MFA-Schutzmaßnahmen umgehen, wenn Mitarbeiter zur Freigabe eines Anmeldevorgangs oder einer Autorisierung bewegt werden.

Was Unternehmen daraus konkret ableiten sollten

  • MCP-Server und Drittanbieter-Integrationen wie jeden anderen Softwarelieferanten mit hoher Hebelwirkung behandeln: Codeprüfung, Signaturprüfung, feste Versionen, Sandbox-Ausführung
  • Regelmäßig prüfen, welche Connected Apps und OAuth-Integrationen tatsächlich aktiv sind — und nicht mehr benötigte Berechtigungen entziehen
  • Mitarbeiter gezielt für Vishing- und Social-Engineering-Versuche im Kontext von Autorisierungsanfragen sensibilisieren
  • Token-Weitergabe an nachgelagerte Systeme technisch unterbinden, statt sich allein auf Vertrauen zu verlassen

Häufige Fragen

Sind lokale MCP-Server sicherer als Cloud-Server?
Nein, sie können mit den Rechten des Nutzers auf Dateien, Prozesse und Zugangsdaten zugreifen.
Ist ein MCP-Registry-Eintrag ein Sicherheitsnachweis?
Nein, er ersetzt keine eigene Codeprüfung, Signatur oder Sandbox.
Schützt Multi-Faktor-Authentifizierung zuverlässig vor Kontoübernahme?
Nicht zuverlässig, wie der Retool-Vorfall von 2023 zeigt — gezieltes Social Engineering kann sie umgehen.
Was ist Token-Passthrough?
Die ungeprüfte Weitergabe eines Zugriffstokens an ein nachgelagertes System, ein zentrales Risiko bei Integrationen.