Eine einzige HTTP-Anfrage kann den KI-Roboter Reachy Mini vollständig übernehmen

Fünf Sicherheitslücken im Roboter entdeckt

JFrog Security Research berichtete am 3. November 2026 über seine Untersuchung von Reachy Mini, der von Pollen Robotics und Hugging Face entwickelt wurde. Der Open-Source-Roboter basiert auf dem Raspberry Pi Compute Module 4 und ist laut Quelle in den Versionen Lite und Wireless erhältlich. Sie kosten jeweils $399 und $499.

Reachy Mini ist für sprach- und bildbasierte Interaktionen konzipiert und kann für Bildungs- und Forschungszwecke eingesetzt werden. Ein Python-basierter Daemon steuert die Servomotoren, die Kamera und das Audiosystem und installiert außerdem Anwendungen aus dem Hugging-Face-Spaces-Ökosystem. Für die Kommunikation zwischen dem Roboter und dem zugehörigen Dashboard betreibt der Daemon einen HTTP-Server auf Basis von FastAPI.

JFrog identifizierte fünf CVEs. Durch deren Verkettung demonstrierten die Forscher die Ausführung von Angreifercode, dauerhaften Root-Zugriff und letztlich die Kontrolle über die Motoren des Roboters. Nach Angaben des Unternehmens könnte ein weiteres Angriffsszenario bereits voraussetzen, dass ein Betreiber eine manipulierte Website öffnet. Dadurch würde das Gerät im Hintergrund kompromittiert.

Der über das Netzwerk erreichbare Daemon läuft ohne Authentifizierung

Im Zentrum des Problems steht reachy-mini-daemon, der die wichtigsten Funktionen des Roboters steuert. Der Dienst lauscht in allen Betriebsmodi auf TCP-Port 8000 an jeder Netzwerkschnittstelle. Bei der Wireless-Version ist der Daemon über die WLAN-Schnittstelle des Roboters erreichbar, bei der Lite-Version über den Computer des Entwicklers und beim Simulator über den lokalen Rechner.

Wireless-Roboter lassen sich außerdem per mDNS unter dem Namen reachy-mini.local finden. Laut JFrog verfügt der Dienst über keine Authentifizierung, während die CORS-Konfiguration jeder Website das Senden von Anfragen erlaubt. Ein Angreifer in einem gemeinsam genutzten Heim-WLAN, Büronetzwerk oder Vorführnetz auf einer Konferenz könnte dadurch auf die Steuerschnittstelle zugreifen.

Der Quelle zufolge schränkt die Option localhost-only das Lauschen auf Netzwerkverbindungen nicht tatsächlich ein. Die Einstellung beeinflusst lediglich, ob die WLAN-IP-Adresse angezeigt wird, während der uvicorn-Server weiterhin an 0.0.0.0 gebunden bleibt. Die Forscher weisen daher darauf hin, dass Betreiber trotz dieser Option weiterhin gefährdet sein können.

Ein Installationsendpunkt kann den Angriff auslösen

Laut der Analyse von JFrog ist der Endpunkt für die Anwendungsinstallation ein zentraler Bestandteil der Angriffskette. In der Anfrage /api/apps/install kann der Client dem Daemon einen als lokale Quelle angegebenen Pfad übermitteln. Der Daemon gibt ihn direkt an den Befehl uv pip install weiter. Der Endpunkt verfügt über keine Positivliste, keine URL-Validierung und keine Einschränkung des Quellentyps.

Bei der Installation aus einer pip-Paketquelle kann pip automatisch den zur Erstellung des Pakets erforderlichen Code ausführen, etwa die Datei setup.py. JFrog betont, dass dies dem dokumentierten Verhalten von pip entspricht. Das Risiko entsteht dadurch, dass der Prozess durch eine nicht authentifizierte Netzwerkeingabe gesteuert wird.

In dem von den Forschern vorgestellten Beispiel legt der Angreifer ein manipuliertes Python-Quellpaket auf einem für den Roboter erreichbaren HTTP-Server ab und sendet anschließend eine einzige HTTP-Anfrage zur Installation. Der Daemon antwortet mit einer Aufgaben-ID, während der Paket-Build-Prozess den Angreifercode ausführen kann.

Update und vorübergehender Schutz

Laut JFrog sind Versionen betroffen, die vor der korrigierten Version 1.11.0 veröffentlicht wurden. Wer nicht sofort aktualisieren kann, sollte nach Empfehlung des Unternehmens Port 8000 mit einer Firewall blockieren. Auf dem Roboter kann dies auf die WLAN-Schnittstelle angewendet werden, auf einer Workstation auf jede Schnittstelle außer der Loopback-Schnittstelle.

Weitere vorübergehende Maßnahmen sind der Verzicht auf die Installation nicht vertrauenswürdiger Anwendungen, eine strengere Konfiguration der sudo-Regeln und der Verzicht auf das Surfen im Internet, während eine Verbindung zum Netzwerk des Roboters besteht. JFrog weist ausdrücklich darauf hin, dass diese Maßnahmen kein Ersatz für die Installation der korrigierten Software sind.

Der Quelle zufolge betrifft die Sicherheitslücke mehrere Einsatzmodi von Reachy Mini. Das Risiko kann sich daher auf das eigene WLAN des Geräts, die Workstations der Entwickler und lokal ausgeführte Simulatoren erstrecken, wenn der Daemon in einem für einen Angreifer zugänglichen Netzwerk betrieben wird.