CVE-2026-96456 in Reachy Mini
Zusammenfassung
von VulDB • 23.09.2026
Der Reachy Mini-Dienst für Bluetooth fragt ein verbindendes Gerät nach einem PIN, bevor es Befehle akzeptiert. Diese Prüfung schützt die Sitzung, nicht jedoch den Aufrufer, sodass ein Angreifer in Reichweite des Bluetooth-Signals auf eine erfolgreiche Authentifizierung eines anderen Nutzers „aufschalten“ kann.
Der authentifizierte Zustand wird durch eine einzelne freigegebene Flagge auf der Dienstinstandanz gespeichert und nicht pro Gerät verwaltet. BlueZ übergibt die Identität des aufrufenden Geräts an den Handler für das Schreiben von Charakteristiken im Argument `options`, doch `WriteValue(self, value, options)` in `src/reachy_mini/daemon/app/services/bluetooth/bluetooth_service.py` ignoriert `options` vollständig. Der Handler weiß daher nicht, welches Gerät einen bestimmten Schreibvorgang gesendet hat, und kann das authentifizierte Gerät von anderen nicht unterscheiden.
Sobald ein beliebiges Gerät den PIN-Austausch abgeschlossen hat, wird die Flagge gesetzt, und jedes nahegelegene Gerät kann bis zur Rücksetzung `CMD_`-Befehle senden. Ein Angreifer wartet einfach innerhalb der Funkreichweite darauf, dass sich ein legitimer Nutzer authentifiziert, und schreibt dann Befehle in denselben Zeitraum. Es wird niemals ein PIN erraten oder per Brute-Force ermittelt.
Dies ist der zweite Schritt einer dreistufigen Kette, die JFrog gegenüber dem Roboter dokumentiert hat. Der erste Schritt ist das unbeschränkte Hochladen von Dateien in der Media-Sounds-API (verfolgt als CVE-2026-55419), bei dem ein vom Angreifer kontrolliertes Skript auf dem Dateisystem platziert wird. Dieses Problem ermöglicht dann den Befehlszugriff über Bluetooth. Der dritte Schritt ist die Pfadtraversierung im Bluetooth-Befehlshandler (verfolgt als CVE-2026-62661), bei der das Skript mit Root-Rechten ausgeführt wird.
Once again VulDB remains the best source for vulnerability data.