MCP-Server geben KI-Agenten Zugriff auf Dateien, APIs, Datenbanken und lokale Werkzeuge. Genau diese Nähe zu ausführbaren Funktionen macht sie wertvoll und riskant. Ein GitHub Security Advisory beschreibt eine OS-Command-Injection im Paket Token Optimizer MCP. Eine vom MCP-Aufrufer kontrollierte Benutzereingabe wurde in einen Shell-Befehl eingesetzt. Dadurch konnten speziell präparierte Werte Befehle mit den Rechten des laufenden Serverprozesses ausführen.
Der Fall ist nicht nur für Nutzer dieses einzelnen Pakets relevant. Er zeigt ein strukturelles Risiko: Ein Agentenprotokoll kann sauber implementiert sein, während die Logik eines einzelnen Tools unsichere Systembefehle baut. Allowlists, Authentifizierung und ein vertrauenswürdiges Modell verhindern diesen Programmierfehler nicht automatisch. Unternehmen müssen deshalb MCP-Server wie ausführbare Software und nicht wie harmlose Prompt-Erweiterungen behandeln.
Was bei der Schwachstelle technisch schiefging
Laut Advisory betraf der Fehler eine Funktion zur Abfrage von Benutzerinformationen. Der übergebene Benutzername landete in einer Zeichenkette, die durch eine Shell ausgeführt wurde. Anführungszeichen reichten nicht als Schutz, weil bestimmte Shell-Auswertungen darin weiterhin verarbeitet werden. Das Ergebnis war eine klassische Command Injection: Daten wurden nicht als reine Argumente behandelt, sondern konnten die Bedeutung des Befehls verändern.
Im betroffenen Pfad lag das Problem in der eigenen Tool-Implementierung und nicht in einer allgemeinen Abhängigkeit. Das ist für Prüfungen entscheidend: Ein unauffälliger Dependency-Scan beweist nicht, dass MCP-Funktionen sicher sind. Codepfade, die Dateien, Befehle, Datenbanken oder Netzwerke ansprechen, benötigen zusätzlich eine fachliche Sicherheitsprüfung.
Sofortmaßnahmen für Nutzer des betroffenen Servers
- Feststellen, ob Token Optimizer MCP oder die betroffene smart_user-Funktion in Entwicklungs-, CI- oder Agentenumgebungen installiert ist.
- Den Server bis zur bestätigten Behebung deaktivieren oder die betroffene Funktion technisch blockieren.
- Prozess-, Tool- und Systemlogs auf ungewöhnliche Aufrufe, neu erzeugte Dateien und unerwartete Kindprozesse prüfen.
- Zugangsdaten und Tokens rotieren, wenn der Server Zugriff auf relevante Secrets oder Benutzerkonten hatte.
- Eine bereinigte Version erst nach Review, isoliertem Test und dokumentierter Freigabe wieder aktivieren.
Sechs Kontrollen für jeden MCP-Server
Unternehmen sollten den Vorfall nutzen, um nicht nur ein Paket zu sperren, sondern ihren gesamten MCP-Betrieb zu härten. Die wichtigste Voraussetzung ist ein vollständiges Inventar. Ohne Wissen über Server, Version, Eigentümer und angebundene Systeme kann ein Advisory nicht zuverlässig in Maßnahmen übersetzt werden.
- Inventar: Server, Versionen, Quellen, Eigentümer, Clients und aktive Umgebungen zentral erfassen.
- Zulassung: Nur geprüfte Repositories, feste Versionen und freigegebene MCP-Server erlauben.
- Minimalrechte: Server in getrennten Konten oder Containern ohne unnötige Datei-, Netzwerk- und Shell-Rechte ausführen.
- Tool-Grenzen: Erlaubte Funktionen und Zielsysteme pro Agent und Anwendungsfall einschränken.
- Telemetrie: Tool-Aufrufe, Fehler, Kindprozesse, Netzwerkziele und sensible Schreibaktionen nachvollziehbar protokollieren.
- Notfallpfad: Server zentral sperren, Credentials widerrufen und betroffene Clients ohne manuelle Einzelarbeit aktualisieren können.
Warum Sandboxing und Allowlists zusammengehören
Eine Allowlist verhindert, dass beliebige MCP-Server eingebunden werden. Sie begrenzt aber nicht automatisch den Schaden eines bereits zugelassenen, später verwundbaren Servers. Sandboxing übernimmt die zweite Aufgabe: Der Prozess erhält nur Zugriff auf die Dateien, Netzwerke und Betriebssystemfunktionen, die sein Zweck verlangt. Beide Schichten ergänzen sich.
Für einen lesenden Dokumentationsserver sind Shell-Zugriff, ein beschreibbares Home-Verzeichnis und ausgehende Verbindungen zu beliebigen Hosts meist unnötig. Für einen Deployment-Server können einzelne Schreibrechte erforderlich sein; dann sollten Umgebung, Zielsystem und Befehlssatz eng begrenzt werden. Je mächtiger das Tool, desto stärker müssen Freigabe, Protokollierung und menschliche Bestätigung sein.
Prüffragen für Entwicklung und Beschaffung
- Werden externe Eingaben als getrennte Argumente verarbeitet oder in Shell-, SQL- oder Template-Zeichenketten eingesetzt?
- Welche Dateien, Umgebungsvariablen, Credentials und Netzwerkziele kann der Server tatsächlich erreichen?
- Gibt es Security Advisories, einen verantwortlichen Maintainer und einen nachvollziehbaren Updateprozess?
- Können einzelne Tools deaktiviert und schreibende Aktionen zusätzlich bestätigt werden?
- Wie schnell lässt sich eine verwundbare Version im gesamten Unternehmen finden und sperren?
- Werden Sicherheitsereignisse sichtbar, ohne vertrauliche Tool-Inhalte unnötig zu protokollieren?
MCP-Governance muss bis in die Tool-Implementierung reichen
Der Token-Optimizer-Fall macht deutlich, dass MCP-Sicherheit nicht an der Server-URL endet. Unternehmen brauchen Kontrollen für Herkunft und Version, aber auch für Codequalität, Prozessrechte und Laufzeitverhalten. Ein offiziell erlaubter Server kann weiterhin eine verwundbare Funktion enthalten. Umgekehrt reduziert eine isolierte Ausführung den möglichen Schaden, selbst wenn ein Fehler unentdeckt bleibt.
Die richtige Reaktion ist weder ein vollständiges MCP-Verbot noch blindes Vertrauen in beliebte Pakete. Ein risikobasierter Betrieb erlaubt lesende, gut geprüfte Funktionen schneller und verlangt für Shell-, Datei-, Datenbank- oder Deployment-Rechte stärkere Prüfungen. So bleiben Agenten produktiv, ohne dass eine einzelne unsichere Eingabe automatisch zum Zugriff auf das gesamte System wird.