Skip to main content

Reachy Mini CVE-2026-96456

| EUVDEUVD-2026-85186 MEDIUM
Race Condition (CWE-362)
2026-09-23 JFROG GHSA-w8hv-46m4-pm2j
6.3
CVSS 3.1 · Vendor: JFROG
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Attacker enters Bluetooth range of robot
  2. Delivery
    Wait for legitimate user PIN authentication
  3. Exploit
    Shared auth flag set service-wide
  4. Execution
    Write CMD_ commands from rogue device
  5. Persist
    Invoke command handler on robot
  6. Impact
    Chain to root execution (CVE-2026-62661)

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V15 - Secure Coding and Architecture Concurrency control, locking
MITRE ATT&CK

1 technique across 1 tactic: Privilege Escalation

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires the attacker to be within Bluetooth radio range of the Reachy Mini robot (AV:A) and to have a legitimate operator complete the Bluetooth PIN authentication during the attack window - the exploit rides that session because the authenticated state is a single shared flag on the service instance instead of being bound per calling device (the WriteValue handler ignores BlueZ's options argument that carries the caller's identity). No PIN guessing or brute force is needed by the attacker. LIMITING FACTORS: physical/Bluetooth proximity is mandatory (not remotely exploitable over IP), and a genuine user must authenticate first (UI:R); the shared flag persists only until it resets, bounding exploitation to that authenticated window. Standalone impact is limited command access - root code execution requires chaining with CVE-2026-55419 (file upload) and CVE-2026-62661 (path traversal).

Impact

The CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L = 6.3 MEDIUM) is the only scored signal available; there is no EPSS score, no CISA KEV listing, and no explicitly published standalone proof-of-concept in the provided data (only JFrog's documented research chain). AV:A confirms the attacker must be within Bluetooth radio range, which sharply limits mass or remote exploitation and makes this a proximity/targeted risk rather than an internet-wide one. UI:R is significant: the flaw is a ride-along on a LEGITIMATE user's successful PIN authentication, so the attacker cannot proceed until a real operator authenticates within the same window. In isolation this issue grants only limited command access (C:L/I:L/A:L), but its real weight comes from being step 2 of a JFrog-documented three-step chain - CVE-2026-55419 (media-sounds unrestricted file upload) plants an attacker script, this CVE provides Bluetooth command access, and CVE-2026-62661 (Bluetooth command-handler path traversal) executes that script as root. Chained, the outcome is root code execution, so defenders should not treat the standalone 6.3 as the ceiling. CWE-362 (race condition) accurately reflects the shared-flag TOCTOU nature. Priority is elevated for anyone operating these robots in shared/physical spaces, but the Bluetooth-range plus required-legitimate-authentication gates keep it below a drop-everything emergency absent the full chain.

Exploit ScenarioDerived

An attacker positions a Bluetooth device within radio range of a Reachy Mini robot and waits for a legitimate operator to complete the PIN exchange with the daemon's Bluetooth service. Because the authenticated state is stored in a single shared flag (not bound per device), the attacker then writes CMD_ commands into the open session without ever guessing the PIN. JFrog documented this as the second link of a three-step chain that ultimately runs an attacker-uploaded script as root.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
No patch listed yet 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 23, 2026

Any Bluetooth device within radio range of a Reachy Mini robot can send CMD_ commands by piggybacking on another operator's completed PIN authentication, because the Bluetooth service keeps its authenticated state in a single shared flag on the service instance rather than binding it to the calling device - the WriteValue handler ignores the BlueZ options argument that carries the caller's identity. The CVSS 3.1 vector AV:A/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L (6.3, Medium) reflects that Bluetooth proximity and a genuine user completing the PIN exchange are both required, and that standalone impact is limited to command access; root code execution only follows from chaining with CVE-2026-55419 (unrestricted file upload) and CVE-2026-62661 (path traversal in the Bluetooth command handler). No CISA KEV listing, no EPSS score, and no independently published standalone exploit code were identified at time of analysis - the only public documentation is JFrog's description of this as the second step in a three-step attack chain, with no public exploit identified at time of analysis for this issue alone.

RemediationAI

No vendor-released patch was identified at time of analysis for CVE-2026-96456, so remediation depends on the vendor advisory GHSA-993g-hgjh-whmf (https://github.com/pollen-robotics/reachy_mini/security/advisories/GHSA-993g-hgjh-whmf) and monitoring https://github.com/pollen-robotics/reachy_mini for an updated bluetooth_service.py that binds authenticated state to the caller (for example by keying on the BlueZ options/device object path instead of a shared instance flag). Until a fix ships, the most effective compensating control is to power off or disable the robot's Bluetooth service when it is not actively needed - trade-off: loss of wireless control and app connectivity - or, if Bluetooth must remain enabled, keep the robot physically in a trusted area where no unauthorized device can be within radio range, since the attack is proximity-bound (AV:A) and cannot be performed over IP. Further hardening: restrict Bluetooth use to bonded, known controllers only and exit pairing mode promptly; reduce the window in which the shared authenticated flag remains set by resetting the service (restarting the daemon) after each authenticated command session, which limits but does not eliminate exposure; and treat CVE-2026-55419 (file upload) and CVE-2026-62661 (path traversal) as required companions to address, because root compromise only occurs when all three flaws are present, so any patch review should confirm all three are fixed in the same release.

Affected VersionsENISA

Reachy Mini 0 ≤1.11.0

Affected Packages

euvd reachy_mini no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Reachy Mini's daemon exposes a Bluetooth GATT service implemented in Python at src/reachy_mini/daemon/app/services/bluetooth/bluetooth_service.py. The service requires a connecting device to complete a PIN exchange before it accepts CMD_ commands, but the resulting authenticated state is stored as one shared boolean flag on the service instance, not as a per-device (per-D-Bus-object-path) attribute. Under BlueZ, the calling device's identity is delivered to characteristic write handlers through the 'options' argument, yet the handler signature WriteValue(self, value, options) ignores options entirely, so the code cannot distinguish the device that authenticated from any other device in range. This maps to CWE-362 (Concurrent Execution Using Shared Resource with Improper Synchronization) in that the shared flag is a state resource written by one party and read/relied upon by the handler on behalf of others - effectively an authentication-state confusion whose exposure window is bounded by how long the flag remains set before it resets. The attacker never guesses or brute-forces the PIN; they simply wait within Bluetooth range for a legitimate operator to authenticate, then issue CMD_ writes during that authenticated window. Because only command access is granted at this stage, the full remote-code-execution chain requires prior placement of an attacker-controlled script via the media sounds API file upload (CVE-2026-55419) and then traversal to execute it as root through the Bluetooth command handler path traversal (CVE-2026-62661).

Know when Reachy Mini gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (JFROG) PRIMARY 6.3 MEDIUM
AV:A/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L
vuln.today AI 6.3 MEDIUM

Bluetooth proximity gives AV:A; the attacker needs no PIN so PR:N, but a legitimate user must authenticate first (UI:R); the shared-flag session hop crosses an authentication boundary (S:C) yielding limited command access (C/I/A:L).

3.1 AV:A/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L
4.0 AV:A/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (JFROG).

CVSS VectorVendor: JFROG

Attack Vector
Adjacent
Attack Complexity
Low
Privileges Required
None
User Interaction
Required
Scope
Changed
Confidentiality
Low
Integrity
Low
Availability
Low

DescriptionCVE.org

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.

Threat Intelligence Overview

EPSS Score
0.2%
Top 96% exploitable
Prevalence
Low
niche open-source robotics platform, small real-world production footprint
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.2%
Patch available No
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
None
System Exposure· derived
Controlled
Automatable
No
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

32
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +32
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Path traversal exploits occur when applications use user-controlled input to construct file system paths without proper validation.

Malicious file upload attacks exploit insufficient validation when web applications accept user-provided files.

Race conditions occur when multiple concurrent requests exploit the brief time gap between checking a condition and acting upon it (TOCTOU - Time of Check, Time of Use).

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy