gemini-bridge-Lücke zeigt das Dateirisiko lokaler Agenten

Worum es geht

Für gemini-bridge wurde am 31. Juli 2026 die Schwachstelle CVE-2026-54785 veröffentlicht. Das Python-Paket verbindet MCP-basierte Agenten mit Googles Gemini CLI. Genau diese Brücke konnte in bestimmten Versionen lokale Dateien lesen, wenn ein Aufrufer Pfade im Parameter files übergab.

Das ist keine Massenpanik-Meldung. Der CVSS-Wert liegt im mittleren Bereich. Interessant ist der Mechanismus: Ein lokales Agenten-Tool bekommt Zugriff auf Dateien, reicht Inhalte an ein externes Modell weiter und kann sie über die Modellantwort wieder sichtbar machen.

Was gemini-bridge tatsächlich macht

gemini-bridge ist ein leichter MCP-Server. Ein Agent kann darüber die Gemini CLI nutzen, etwa um Dateien analysieren zu lassen oder Codekontext an ein Modell zu geben. Laut GitHub-Advisory betraf die Lücke den Modus consult_gemini_with_files in der Inline-Variante.

Die Schwachstelle entstand, weil Dateipfade nicht sauber auf das erlaubte Arbeitsverzeichnis begrenzt wurden. Zwischen Version 1.0.0 und 1.3.1 konnte ein kontrollierter Dateipfad daher auch auf Pfade außerhalb dieses Bereichs zeigen. Die Inhalte wurden anschließend an die Gemini CLI übergeben. Tenable und Miggo beschreiben denselben Kern: Aus einem Dateihilfswerkzeug wurde ein lokaler Dateileser mit externer Weitergabe.

Warum das wichtig ist

MCP-Tools sind praktisch, weil sie Agenten echte Fähigkeiten geben: Dateien lesen, Repos durchsuchen, APIs aufrufen, Kalender prüfen oder Deployments vorbereiten. Genau dadurch ändert sich aber das Risikoprofil. Ein Chatbot ohne Werkzeug kann nur reden. Ein Agent mit Werkzeugen kann handeln.

Bei lokalen Entwickler-Setups liegen oft sensible Dateien nahe beieinander: .env, SSH-Konfigurationen, Quellcode, Kundendaten, interne Notizen. Wenn ein Tool Dateigrenzen zu locker behandelt, reicht nicht mehr nur ein klassischer Exploit. Auch ein bösartiger Prompt, eine vergiftete Aufgabe oder ein falsch konfigurierter Agent kann zum Problem werden.

Der Fall ist deshalb ein gutes Warnsignal für Teams, die MCP-Server schnell in interne Workflows hängen. Die Frage lautet nicht nur: Funktioniert das Tool? Die wichtigere Frage ist: Was darf es unter keinen Umständen sehen?

Einfach erklärt

Stell dir einen Praktikanten vor, der Akten aus einem bestimmten Ordner kopieren darf. Der Auftrag lautet: „Bring mir die drei Verträge aus Schublade A.“ Wenn der Praktikant aber jeden Pfad akzeptiert, kann jemand sagen: „Nimm auch noch den Tresorordner nebenan.“ Die Arbeit wirkt gleich, aber die Grenze ist verschwunden.

Praktisches Beispiel

Ein Entwicklerteam nutzt einen lokalen Agenten für 200 Codeprüfungen pro Woche. Der Agent darf Dateien im aktuellen Projekt an Gemini weitergeben. In einem Repo liegen aber auch eine alte .env-Datei und ein Export mit 500 Testkunden.

Ein manipuliertes Ticket fordert den Agenten auf, „alle relevanten Konfigurationsdateien“ zu prüfen. Wenn das Tool Pfade außerhalb des Projektordners akzeptiert, könnten sensible Inhalte in die Modellrunde geraten. Selbst wenn niemand eine Datenbank direkt angreift, entsteht ein Datenabfluss über den Hilfsweg.

Einordnung und Grenzen

• Die Schwachstelle ist als moderat eingestuft. Sie bedeutet nicht automatisch, dass jede gemini-bridge-Installation kompromittiert wurde.
• Der konkrete Schaden hängt stark davon ab, wie der MCP-Server gestartet wurde, welche Dateien erreichbar waren und wer Tool-Aufrufe auslösen konnte.
• Der Fall ersetzt keine allgemeine Bewertung von Gemini, MCP oder lokalen Agenten. Er zeigt ein konkretes Implementierungsproblem: Dateipfade brauchen harte Grenzen.

SEO- und GEO-Schlüsselbegriffe

gemini-bridge, CVE-2026-54785, MCP security, Model Context Protocol, Gemini CLI, local file read, AI agents security, prompt injection, developer tools security, GitHub Advisory