KIberschutz: pipeshub lässt sechs Lücken offen
Vor über zwei Monaten meldeten wir pipeshub dreizehn Lücken. Sechs sind bis heute nicht behoben, drei davon kritisch. Was Betreiber jetzt tun sollten.
Transparenz vorweg: KIberschutz ist unser eigenes Projekt. Wir prüfen mit KI-Unterstützung Open-Source-Software auf Sicherheitslücken und melden die Funde verantwortungsvoll an die Maintainer. Veröffentlicht wird normalerweise erst, wenn der Fix bei den Nutzern angekommen ist. Bei pipeshub weichen wir davon ab, zum ersten Mal.
Am 25. Juli haben wir dem Projekt dreizehn Lücken gemeldet. Sieben sind inzwischen behoben, fünf davon auch ausgeliefert. Sechs sind bis heute nicht behoben, drei davon stufen wir als kritisch ein. Wer v0.8.0 betreibt, ist damit gegen acht Funde ungeschützt. Die einzige inhaltliche Antwort des Teams kam am 1. September, mit einem Termin, der seit 17 Tagen verstrichen ist. Auf unsere Nachfrage vom 19. September kam nichts mehr. Wer pipeshub betreibt, sollte das wissen, deshalb schreiben wir es jetzt auf. Eine Anleitung zum Angreifen steht nicht drin, dafür das, was ihr selbst tun könnt.
Um welche Software es geht
pipeshub beschreibt sich als Open-Source-Plattform für "Workplace AI". Sie verbindet sich mit Slack, Google Drive, GitHub, Microsoft 365, Notion und über fünfzig weiteren Systemen, macht deren Inhalte durchsuchbar und beantwortet Fragen dazu mit Quellenangaben. Dieselben Inhalte stehen auch eigenen Agenten und MCP-Clients zur Verfügung. Apache-2.0, rund 3.800 Sterne auf GitHub, selbst hostbar per Docker Compose oder Helm.
Genau das macht die Lücken ernst. Eine solche Plattform hält Zugangsdaten zu den wichtigsten Firmensystemen und einen Index über deren Inhalte. Wer sie übernimmt, sitzt an der Schnittstelle zu all diesen Systemen.
Was wir gemeldet haben und was daraus wurde
Gemeldet haben wir über das private Meldeverfahren von GitHub, so wie es die SECURITY.md des Projekts vorsieht. Dort verspricht das Team eine Eingangsbestätigung in 48 Stunden, eine Einschätzung in fünf Werktagen, Updates alle sieben Tage und die Behebung kritischer Lücken in 30 Tagen. Nichts davon ist eingetreten. Fünf Wochen lang kam keine Antwort.
Am 26. August haben wir nachgefragt. Zwei Tage später war der erste Fix im Code, am 1. September kam die Antwort: Man entschuldige sich, die Meldungen seien angekommen, die kritischen würden priorisiert. Und: "We expect to have fixes for all reported issues ready by September 10."
Das Team hat danach tatsächlich geliefert, nur eben nicht alles. Version 0.8.0 vom 14. September behebt fünf Funde, eins der zugehörigen Advisories hat das Team selbst veröffentlicht, mit Nennung von uns als Melder (GHSA-47gf-3x62-7jfm). Am 19. September haben wir uns dafür bedankt und für jeden der übrigen acht Funde einen fertigen Fix-Vorschlag im privaten Advisory-Fork hinterlegt. Darauf kam keine Antwort, die Vorschläge hat bis heute niemand kommentiert. Zwei der acht hat das Team in der letzten Woche selbst im Code behoben, ohne das in den Advisories zu erwähnen. Ein Release dazu gibt es noch nicht.
| Stand | Funde | Schwere |
|---|---|---|
| Behoben und in v0.8.0 ausgeliefert | 5 | 2 hoch, 3 mittel |
| Im Hauptzweig behoben, noch kein Release | 2 | 2 hoch |
| Offen | 6 | 3 kritisch, 2 hoch, 1 mittel |
Die fünf behobenen betreffen die Erzeugung von Signaturschlüsseln und Einmalcodes mit einem nicht kryptografischen Zufallsgenerator, signierte Download-Links ohne Rechteprüfung, eine Verwechslung von Token-Arten und widerrufene Tokens, die weiter galten. Die zwei im Hauptzweig behobenen: Normale Nutzer konnten die API-Schlüssel der eingebundenen Websuche-Dienste im Klartext abrufen, und ein interner Dienstaufruf ließ sich über einen manipulierten Pfad umlenken.
Die sechs offenen Lücken
Zu diesen Funden nennen wir nur die Art der Lücke und die betroffene Komponente, Codestellen und Schritte zum Nachstellen lassen wir weg. Wer die Software betreibt, soll einschätzen können, was auf dem Spiel steht, ohne dass wir eine Anleitung mitliefern.
| Schwere | Bereich | Was möglich ist |
|---|---|---|
| kritisch | Code-Ausführung des Agenten | Ohne ausdrückliche Konfiguration läuft vom Agenten erzeugter Code ohne Container-Isolation im Anwendungscontainer. Jeder angemeldete Nutzer kann so Code auf dem Server ausführen und an dessen Zugangsdaten kommen. |
| kritisch | Datei-Upload der Konnektoren | Ein angemeldeter Nutzer kann Dateien an Stellen außerhalb des vorgesehenen Verzeichnisses schreiben. Je nach Installation reicht das, um Code auf dem Server auszuführen. |
| kritisch | OAuth-Anbieter | Mit einem beliebigen ausgestellten OAuth-Token lassen sich weitere Rechte bis hin zur Organisations-Administration verschaffen. |
| hoch | OAuth-Anbieter | Refresh-Tokens sind nicht an die App gebunden, für die sie ausgestellt wurden. Ein abgeflossenes Token lässt sich über eine andere App einlösen. |
| hoch | Web- und RSS-Konnektor | Serverseitige Abrufe sind nicht auf öffentliche Adressen beschränkt. Nutzer können interne Dienste und Cloud-Metadaten abfragen und bekommen die Antwort zu sehen. |
| mittel | OAuth-Anbieter | Der PKCE-Schutz gegen abgefangene Autorisierungscodes lässt sich umgehen. |
Die drei kritischen Lücken und die im Web-Konnektor setzen ein Konto in der Instanz oder ein dort ausgestelltes Token voraus. Für die beiden übrigen OAuth-Lücken braucht ein Angreifer ein abgeflossenes Refresh-Token oder einen abgefangenen Autorisierungscode. Ohne jeden Zugang von außen kommt man nach unserem Stand an keine der sechs heran. Das ist der wichtigste Punkt für eure Einschätzung, und zugleich eine schwache Beruhigung. Bei einer Plattform, an der die halbe Belegschaft angemeldet ist, ist "ein Konto" keine hohe Hürde.
Was ihr tun solltet
Wenn ihr pipeshub selbst betreibt, hilft bis zu einem Fix-Release nur, die Angriffsfläche zu verkleinern.
- Aktualisiert auf v0.8.0. Das schließt fünf der dreizehn Funde. Außerdem setzt das Helm-Chart ab dieser Version die Container-Isolation für Code-Ausführung als Vorgabe.
- Setzt
SANDBOX_MODE=dockerausdrücklich, egal wie ihr installiert habt. Die Compose-Dateien und das Helm-Chart ab v0.8.0 tun das bereits, aber jede Installation ohne diese Variable fällt auf die unsichere Variante zurück. Prüft es in der laufenden Umgebung, nicht in der Doku. - Begrenzt den ausgehenden Netzverkehr der Konnektor-Dienste. Interne Netze und die Metadaten-Adresse eurer Cloud (169.254.169.254) sollten von dort nicht erreichbar sein. Das entschärft die offene Lücke im Web-Konnektor und schadet auch sonst nicht.
- Räumt beim OAuth-Anbieter auf. Prüft, welche OAuth-Apps registriert sind und welche Tokens ausgestellt wurden, und widerruft, was ihr nicht zuordnen könnt. Wenn ihr den OAuth-Zugang für eigene Agenten oder MCP-Clients nicht braucht, gebt keine Tokens aus.
- Lasst die Instanz nicht offen im Internet stehen und vergebt Konten nur an Menschen, denen ihr auch einen Shell-Zugang auf den Server geben würdet. Klingt drastisch. Solange die Lücke bei der Code-Ausführung offen ist, läuft es aber genau darauf hinaus.
- Rotiert die API-Schlüssel eurer Websuche-Anbieter, falls ihr eine eingebunden habt. Die waren für jeden Nutzer im Klartext abrufbar, und der Fix steckt noch in keinem Release.
Warum wir jetzt veröffentlichen
Unsere Regel ist, dass wir einen Fall erst beschreiben, wenn der Fix beim Nutzer angekommen ist. Davon weichen wir nur ab, wenn ein Projekt über Wochen nicht kooperiert. Das ist hier der Fall, und die Entscheidung haben wir uns nicht leicht gemacht.
Seit der Meldung sind neun Wochen vergangen. Die SECURITY.md des Projekts nennt 30 Tage für kritische Lücken, das Team hat selbst den 10. September zugesagt. Beide Termine sind verstrichen, ohne dass jemand einen neuen genannt hätte. Eine Zeile mit einem realistischen Zeitplan hätte gereicht, und wir hätten gewartet.
Fairerweise: Die SECURITY.md sieht eine Veröffentlichung "typically within 90 days" nach der Meldung vor, nach dem Fix. Wir sind bei Tag 64 und damit früher. Wir halten das für vertretbar, weil die Lücken unabhängig von unserer Meldung existieren und wer gezielt danach sucht, sie finden kann. Wer pipeshub betreibt, hat dagegen bis heute keinen Hinweis, dass etwas im Argen liegt. Die Advisories sind privat, und die Release-Notes erwähnen nur, was behoben wurde.
Das Veröffentlichen der Advisories bei GitHub bleibt Sache des Teams, das tun wir nicht selbst. Unsere Fix-Vorschläge liegen weiter bereit.
Wie es weitergeht
Der Fall steht auf unserer Statusseite unter dem Klarnamen, weil fünf Funde behoben und ausgeliefert sind. Die sechs offenen erscheinen dort erst, wenn ihr Fix in einem Release steckt. Sobald das passiert oder das Team sich meldet, tragen wir es hier nach.