CVE-2026-96456 in Reachy Mini
Summary
by MITRE • 09/23/2026
The Reachy Mini Bluetooth service asks a connecting device for a PIN before it will accept commands. The check protects the session but not the caller, so an attacker in Bluetooth range can ride along on someone else's successful authentication.
The authenticated state is kept in a single shared flag on the service instance rather than per device. BlueZ passes the calling device's identity to the characteristic write handler in the options argument, but WriteValue(self, value, options) in src/reachy_mini/daemon/app/services/bluetooth/bluetooth_service.py ignores options entirely. The handler therefore has no idea which device sent a given write, and it cannot tell the authenticated one from any other.
Once any device completes the PIN exchange, the flag is set and every nearby device can send CMD_ commands until it resets. An attacker simply waits within radio range for a legitimate user to authenticate, then writes commands into the same window. No PIN is ever guessed or brute-forced.
This is the second step of a three-step chain that JFrog documented against the robot. The first is the unrestricted file upload in the media sounds API, tracked as CVE-2026-55419, which places an attacker-controlled script on the filesystem. This issue then provides command access over Bluetooth. The third is the Bluetooth command handler path traversal, tracked as CVE-2026-62661, which runs that script as root.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/23/2026
The Reachy Mini robot presents a critical authentication bypass vulnerability within its Bluetooth Low Energy service architecture, specifically affecting how session states are managed across multiple connected devices. The system is designed to require a PIN code from any connecting device before accepting command inputs, ostensibly providing a layer of security against unauthorized access. However, the implementation contains a fundamental flaw where this authentication check protects the communication session rather than verifying the identity of the caller itself. This architectural oversight allows an attacker operating within Bluetooth range to exploit the shared state mechanism by riding along on a legitimate user's successful PIN exchange. The vulnerability stems from the fact that while the underlying BlueZ stack correctly passes the calling device's identity information through options arguments in characteristic write handlers, the application-level handler for writing values completely ignores this metadata. Consequently, the service instance maintains authentication status using a single shared flag rather than maintaining distinct per-device session states.
From a technical perspective, the core issue lies in the WriteValue function implementation within the bluetooth_service.py module. When a device writes data to the characteristic, the system checks only if the global authenticated flag is set to true, without validating whether the current request originates from the specific device that performed the PIN authentication. This design decision effectively neutralizes the intended security control because once any single device successfully authenticates by providing the correct PIN, the shared flag remains active for all subsequent connections until it is explicitly reset or times out. An attacker does not need to guess or brute-force the PIN; they merely need to wait within radio range for a legitimate user to authenticate and then immediately send malicious commands during that open window of opportunity. This behavior classifies as an authentication bypass where the system fails to properly associate security context with individual endpoints, allowing unauthorized execution of privileged operations over Bluetooth.
The operational impact of this vulnerability is severe given its role in a documented three-step attack chain identified by JFrog Research. While standing alone it allows for command injection via Bluetooth, when combined with other vulnerabilities on the same platform, it facilitates full system compromise. The first step involves an unrestricted file upload flaw that places attacker-controlled scripts onto the filesystem. This vulnerability provides the initial foothold and persistence mechanism. The authentication bypass described here serves as the second step, granting the attacker direct command access over Bluetooth to interact with these files or execute further actions without needing additional credentials. The final step in this chain involves a path traversal vulnerability in the Bluetooth command handler that allows execution of those uploaded scripts with root privileges. This progression demonstrates how seemingly minor authentication flaws can serve as critical pivots in complex attack scenarios, leading to complete control over the robotic system's operating environment and hardware functions.
Mitigation strategies must address both the immediate technical flaw and the broader architectural design principles governing session management. The primary fix requires modifying the bluetooth_service.py handler to enforce per-device authentication states rather than relying on a global shared flag. This involves tracking authenticated sessions based on unique device identifiers such as MAC addresses or Bluetooth handles provided in the options argument, ensuring that each connection maintains its own independent security context. Additionally, implementing session timeouts with shorter durations can limit the window of opportunity for attackers to exploit this state after a legitimate user disconnects. From an industry standard perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-613 Insufficient Session Expiration, as it fails to properly verify identity and maintains active sessions indefinitely without proper lifecycle management. In terms of the MITRE ATT&CK framework, this behavior facilitates lateral movement within local networks by allowing an attacker to leverage existing valid credentials or states from one user to impersonate them against shared resources, specifically mapping to techniques involving session hijacking and credential reuse. Organizations deploying Reachy Mini robots should prioritize patching these Bluetooth service components and consider implementing mutual authentication protocols where the device also verifies the client's identity beyond simple PIN entry, thereby closing the gap that allows state sharing across untrusted endpoints.