Sicherheitslücke in der Google MCP Toolbox: Was Nutzer selbst gehosteter KI-Systeme überprüfen sollten

Titelbild: Google Cloud — MCP-Toolbox-Architektur.

CVE-2026-93328 verknüpft eine konkrete Software-Sicherheitsmeldung mit einem größeren Thema rund um Home-Server: Ein KI-Tool-Dienst kann über Datei- und Cloud-Storage-Berechtigungen verfügen, die über das hinausgehen, was der Agent für die ihm gestellte Aufgabe benötigt. Prüfen Sie zuerst die genau betroffene Komponente, statt anzunehmen, dass alle MCP-Server denselben Fehler aufweisen.

Dieser Leitfaden trennt das veröffentlichte Ereignis von der praktischen Umsetzung. Er erklärt, was die Quelle belegt, wo die Beweislage endet und wie sich ein Workflow mit privaten Dateien bewerten lässt, ohne anzunehmen, dass ein beeindruckendes Modell oder ein neuerer Server die Notwendigkeit eines begrenzten Zugriffs und einer Überprüfung entfallen lässt.

Welche Software wird in der Sicherheitsmeldung beschrieben?

Der Eintrag in der GitHub Advisory Database beschreibt eine Path-Traversal-Schwachstelle und fehlende Autorisierung in der Cloud-Storage-Quelle von Google Cloud MCP Toolbox for Databases. Der betroffene Versionsbereich gilt nur für diese Komponente. Eine nicht damit zusammenhängende MCP-Implementierung, ein Connector, der diese Quelle nie ausführt, oder eine andere Version muss separat bewertet werden. Bewahren Sie den installierten Image-Digest, das Release-Tag und die Konfiguration auf, damit sich der Vergleich überprüfen und nicht bloß aus einem angezeigten Anwendungsnamen ableiten lässt.

Der Datenbankeintrag war bei der Überprüfung als ungeprüft markiert und sollte daher nicht als vollständige Empfehlung zur Bereitstellung des Anbieters präsentiert werden. Folgen Sie den Verweisen zum Upstream-Repository und vergleichen Sie sie mit den aktuellen Versionshinweisen. Der verlinkte Pull Request fügt Einschränkungen für Buckets und lokale Pfade hinzu, aber sein früheres Merge-Datum ist nicht das Datum der öffentlichen Bekanntgabe. Eine Chronologie, der zufolge das Projekt erst diese Woche alles behoben hat, würde die Beweislage falsch darstellen.

Warum ist die Aktualisierung nur ein Teil der Sicherheitsgrenze?

Ein aktualisiertes Image kann Schutzmaßnahmen enthalten und dennoch mit permissiven Einstellungen, unnötigen Einbindungen oder weitreichenden Cloud-Zugangsdaten ausgeführt werden. Prüfen Sie die tatsächlich wirksame Konfiguration, statt anzunehmen, dass ein Einstellungsname eine eingeschränkte Bereitstellung belegt. Ein Tool, das das Host-Dateisystem lesen und in einen Remote-Bucket schreiben kann, schafft einen Datenübertragungsweg, auch wenn das Modell selbst anderswo gehostet wird. Welche Ressourcen das Tool erreichen kann, hängt von der Identität ab, unter der es ausgeführt wird.

Erfassen Sie lokale Stammverzeichnisse, Bucket-Zugriffe, Laufzeitbenutzer und Netzwerkerreichbarkeit. Bevorzugen Sie ein dediziertes Aufgabenverzeichnis und eine zweckgebundene Dienstidentität. Kann der Prozess nicht auf das Familienarchiv oder nicht zugehörige Cloud-Buckets zugreifen, hat ein fehlerhafter Tool-Aufruf weniger Möglichkeiten, Schaden anzurichten. Beschränkungen sollten unterhalb der Prompt-Ebene greifen: Betriebssystemberechtigungen, Container-Einbindungen und Cloud-IAM bleiben wirksam, wenn ein Agent eine Anfrage missversteht oder in abgerufenen Inhalten auf feindliche Anweisungen stößt.

Der verlinkte Upstream-Pull-Request nennt allowedBuckets und allowedLocalRoot und weist auf permissive Standardwerte hin. Prüfen Sie die tatsächlich wirksamen Werte für die bereitgestellte Quelle; allein das Vorhandensein dieser Einstellungen in einer neueren Binärdatei belegt keine eingeschränkte Bereitstellung. In derselben Historie wird die Version 1.5.0 vom Juni erwähnt. Daher sollte ein kürzlich veröffentlichter Sicherheitshinweis nicht als neu im Oktober zusammengeführte Fehlerbehebung beschrieben werden.

Wie lässt sich die Gefährdung prüfen, ohne einen Angriff nachzustellen?

Lesen Sie zuerst die Konfiguration und Laufzeitmetadaten. Ermitteln Sie den bereitgestellten Quelltyp, die genaue Version und ob der Endpunkt aus nicht vertrauenswürdigen Netzwerken erreichbar ist. Überprüfen Sie anschließend in einer Staging-Umgebung mit entbehrlichen Testdaten die zulässigen lokalen Stammverzeichnisse und Buckets. Sie müssen weder Produktionsgeheimnisse übermitteln noch eine Exfiltrationssequenz nachstellen, um festzustellen, dass Zugangsdaten oder Einbindungen zu weitreichend sind.

Wenn Protokolle oder andere Belege auf nicht autorisierte Aktivitäten hindeuten, sichern Sie relevante Aufzeichnungen, bevor Sie routinemäßige Bereinigungen vornehmen, und rotieren Sie die Zugangsdaten des betroffenen Dienstes. Ein Versionsupgrade kann einen kopierten Schlüssel weder widerrufen noch eine Datei zurückholen, die das System bereits verlassen hat. Halten Sie Aufzeichnungen zur Behebung getrennt von Erkundungstests und überprüfen Sie nach der Änderung, ob die regulären Abläufe funktionieren. Ziel ist ein Tool-Dienst mit nachweislich begrenzten Berechtigungen, nicht bloß ein Container, der erfolgreich neu startet.

Was sollten Sie messen, bevor Sie diesem Workflow vertrauen?

Erstellen Sie für jede bereitgestellte Instanz einen Offenlegungsnachweis: Image-Digest, Quellkonfiguration, Laufzeitidentität, eingebundene Pfade, Cloud-Identität und erreichbare Endpunkte. Unterscheiden Sie zwischen der Installation einer Komponente und der Aktivierung der betroffenen Quelle. Eine Container-Kennzeichnung oder ein in einer Lockdatei aufgeführtes Paket ist ein nützlicher Anhaltspunkt, verrät aber nicht, welche Konfiguration im laufenden Prozess aktiv ist. Bewahren Sie die Belege auf, auf denen die einzelnen Schlussfolgerungen beruhen.

Prüfen Sie die Durchsetzung anhand ungefährlicher Testdaten. Ein zulässiger Vorgang innerhalb eines eigens dafür vorgesehenen Testverzeichnisses sollte funktionieren; eine Anfrage außerhalb dieses Verzeichnisses sollte von der tatsächlichen Kontrollmaßnahme abgewiesen werden, ohne dass das Modell entscheiden muss, ob sie unangemessen ist. Gehen Sie bei Bucket-Bereichen und IAM genauso vor. Leiten Sie die Durchsetzung nicht allein aus einer Konfigurationsdatei auf dem Datenträger ab: Vergewissern Sie sich, dass der Dienst diese Datei geladen hat und Bereitstellungsüberschreibungen die beabsichtigte Beschränkung nicht ausgeweitet haben.

Wie halten Sie das Ergebnis nachvollziehbar und wiederherstellbar?

Behandeln Sie eine vermutete Offenlegung als betrieblichen Vorfall mit einem zeitlichen Ablauf. Sichern Sie relevante Zugriffsprotokolle, Bereitstellungsaufzeichnungen und Kennungen der Zugangsdaten vor der routinemäßigen Bereinigung und beschränken Sie zugleich den unnötigen Zugriff auf diese Aufzeichnungen. Halten Sie fest, was bekannt ist und was noch nicht festgestellt werden kann. Das Vorhandensein einer anfälligen Version beweist nicht, dass auf Daten zugegriffen wurde; das Fehlen eines passenden Protokolleintrags beweist nicht, dass ein Zugriff unmöglich war.

Die Wiederherstellung hängt von der betroffenen Komponente ab. Schränken Sie die offengelegte Quelle ein oder deaktivieren Sie sie, ersetzen Sie anfällige Software gegebenenfalls, erneuern Sie betroffene Zugangsdaten und stellen Sie überschriebene Dateien bei Bedarf aus einer bekannten Kopie wieder her. Prüfen Sie anschließend, ob gewöhnliche autorisierte Vorgänge mit den eingeschränkten Berechtigungen weiterhin funktionieren. Dokumentieren Sie nach der Behebung den bereitgestellten Digest und die tatsächlich geltenden Zulassungslisten. Ein Upgrade kann den ausführbaren Code ändern, ohne eine zu weit gefasste Einbindung, eine freizügige Standardeinstellung oder bereits offengelegte Zugangsdaten zu korrigieren.

Wie können Sie den Workflow testen, bevor Sie wichtige Dateien verwenden?

Das Folgende ist ein redaktionelles Prüfprotokoll und keine Behauptung, dass ZimaSpace den Dienst getestet hat. Führen Sie es mit entbehrlichen oder genehmigten Testdaten durch und halten Sie die Testbedingungen zusammen mit dem Ergebnis fest.

1. Erfassen Sie die laufende Komponente und die betroffene Quelle. Vergleichen Sie die bereitgestellte Version mit dem im Sicherheitshinweis genannten Versionsbereich und sichern Sie den exakten Image-Digest sowie die Konfigurationskennung.
2. Lesen Sie den Sicherheitshinweis zusammen mit der Änderung im Upstream. Unterscheiden Sie das Veröffentlichungsdatum von der früheren Implementierungsgeschichte und prüfen Sie die aktuellen Versionsinformationen, bevor Sie ein Update auswählen.
3. Ermitteln Sie die tatsächlich geltenden Berechtigungen. Prüfen Sie lokale Stammverzeichnisse, Container-Einhängepunkte, Laufzeitberechtigungen, Bucket-Bereiche, IAM und die Erreichbarkeit von Endpunkten. Ermitteln Sie Berechtigungen, die der vorgesehene Auftrag nicht benötigt.
4. Prüfen Sie Einschränkungen mit entbehrlichen Testdaten in einer Staging-Umgebung. Überprüfen Sie erlaubte und verweigerte Pfade und Buckets, ohne Produktionsgeheimnisse in Testanfragen aufzunehmen.
5. Sichern Sie Belege und beheben Sie offengelegte Zugangsdaten, falls verdächtige Aktivitäten vermutet werden. Halten Sie Beobachtungen zum Vorfall von Annahmen und explorativen Tests getrennt.
6. Wiederholen Sie nach der Behebung den üblichen autorisierten Arbeitsablauf. Dokumentieren Sie die endgültige Version, die geladene Konfiguration und das Ergebnis der Durchsetzung, damit die Änderung unabhängig überprüft werden kann.

Welche Rolle spielt ein ZimaOS-Server?

Ein ZimaCube 2 Personal Cloud NAS kann eine lokale Speicher- und Anwendungsebene bereitstellen, wenn ein Projekt tatsächlich mehrere Laufwerke, eine SSD-Arbeitsebene oder gemeinsamen Zugriff auf ein wachsendes Archiv benötigt. Wählen Sie die Hardware passend zu den aufzubewahrenden Quelldaten, den aktiven Diensten und der Backup-Richtlinie. Die Produktempfehlung dient als Architekturkontext und ist kein Beleg dafür, dass dieses Cloud-Modell, der Vorschau-Dienst oder das Forschungssystem lokal auf dem NAS ausgeführt wird.

Trennen Sie Schlussfolgerungen von der Datenverwahrung. Ein gehostetes Modell kann genehmigte Auszüge erhalten, während die maßgeblichen Originale auf dem Server bleiben. Optionale lokale Indexierungs-, Konvertierungs- oder Dienste für kleinere Modelle erfordern eine eigene Bewertung von Arbeitsspeicher und Rechenleistung. Bewahren Sie eine zweite wiederherstellbare Kopie außerhalb des Hauptgeräts auf und betrachten Sie weder RAID noch einen erfolgreichen Upload als vollständige Backup-Strategie. Ein vorhandener kleinerer Server ist weiterhin sinnvoll, wenn er die gemessene Arbeitslast bereits bewältigt.

FAQ

Betrifft dieser Sicherheitshinweis jeden MCP-Server?

Nein. Der zitierte Eintrag beschreibt die Cloud-Speicherquelle in googleapis/mcp-toolbox in den Versionen 1.2.0–1.4.0. Andere Implementierungen und Bereitstellungen müssen separat bewertet werden.

Behebt eine Aktualisierung des Images das Problem vollständig?

Ein Update ist nur ein Teil der Bewertung. Prüfen Sie die wirksamen Beschränkungen für lokale Stammverzeichnisse und Buckets, eingebundene Pfade, die Laufzeitidentität und Cloud-Anmeldedaten. Auch eine neuere Binärdatei kann mit übermäßigen Berechtigungen arbeiten.

Sollte ich den Dateiexport mit Produktionsdaten nachstellen?

Bewerten Sie die Zugriffsmöglichkeiten anhand von Konfigurationsnachweisen und harmlosen Testdaten. Für die Überprüfung einer zu weit gefassten Einbindung, Identität oder Allowlist sind weder produktive Geheimnisse noch private Dateien erforderlich.

Sollte ich einem KI-Tool Zugriff auf mein gesamtes privates Archiv gewähren?

Stellen Sie für die Aufgabe nur die erforderlichen Daten über ein angemessen eingeschränktes Konto oder Arbeitsverzeichnis bereit. Prüfen Sie, was der jeweilige Dienst hochlädt, protokolliert und aufbewahrt. Ein privater Speicherort garantiert nicht, dass ein verbundenes Tool die Verarbeitung lokal hält.

Wann lohnt sich ein größeres NAS?

Wenn das gemessene Wachstum der Quelldaten, der gemeinsame Zugriff, aktive Anwendungen oder Aufbewahrungsanforderungen die Speicherarchitektur rechtfertigen. Dadurch werden weder der Modellzugriff noch nicht unterstützte Laufzeitumgebungen, Upload-Limits des Netzwerks oder Unsicherheiten bei Forschungsaussagen automatisch geklärt.

Wann ist vor dem Produktionseinsatz Schluss?

Brechen Sie ab, wenn Sie die Identität der Software oder des Modells, die Autorität der Eingaben, die Verfügbarkeit der erforderlichen Funktionen oder den Wiederherstellungspfad nicht feststellen können. Klären Sie diese Bedingungen zuerst und wiederholen Sie dann den kleinen Test. Versuchen Sie nicht, fehlende Nachweise durch eine selbstsicherere Empfehlung auszugleichen.

Quellen und weiterführende Informationen

• Offizielle Ankündigung oder Sicherheitshinweis
• Änderungen der Zugriffskontrolle für Upstream-Cloud-Speicher
• Veröffentlichungen des Upstream-Projekts

Berichtsstand: 28. Oktober 2026. Produktverfügbarkeit, Zugangspläne und Sicherheitshinweise können sich ändern. Aussagen aus Upstream-Quellen sind als solche gekennzeichnet; Empfehlungen für Workflows und Architekturbeispiele sind redaktionelle Analysen und keine Messungen aus einem ZimaSpace-Hardwaretest.

Zugehöriger Leitfaden: Kann ein selbst gehosteter KI-Agent über eine schreibgeschützte Dateisystemansicht arbeiten?.

Zugehöriger Leitfaden: So testen Sie, ob die Berechtigungen eines Agenten nur die erforderlichen Tool-Aktionen abdecken.

Zugehöriger Leitfaden: KI-Schwachstellenerkennung vs. automatisiertes Patchen: Welches Problem löst was?.