Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessJoin same LAN as wireless robot
-
DeliveryPublish malicious Hugging Face Space
-
ExploitSend unauthenticated POST /apps/install
-
ExecutionDaemon pip/uv-installs package
-
PersistSetup code executes
-
ImpactArbitrary code runs on robot
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication required for critical functions
MITRE ATT&CK
1 technique across 1 tactic: Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires the wireless (Wi-Fi) variant of Reachy Mini, whose daemon binds 0.0.0.0 per _resolve_bind_host; wired units bind 127.0.0.1 and are only exploitable from localhost. The attacker must have network reachability to the robot's HTTP API on the same LAN (AV:A), then sends an AppInfo body naming any attacker-controlled public Hugging Face Space to POST /apps/install. No authentication, credentials, or user interaction are needed (PR:N/UI:N). The 1.8.2/PR-1207 CORS allow-list change does NOT limit this vector because a direct cross-host HTTP request involves no browser, preflight, or CORS enforcement. |
| Impact | This is a genuine high-priority issue on affected wireless units, not a CVSS-inflated one. The vendor CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (8.8) is well-supported: CWE-306 missing authentication on POST /apps/install, whose only FastAPI dependency (Depends(get_app_manager)) returns the manager object and never checks a credential, means any host on the LAN can trigger it. Impact is full C:H/I:H/A:H because installing the chosen Hugging Face Space runs its build/setup code - arbitrary code execution on the robot. The AV:A (adjacent) rather than AV:N is correct and important: the daemon binds 0.0.0.0 only on the wireless build (_resolve_bind_host), while the wired build binds 127.0.0.1, so network exploitability is model-dependent. No EPSS score, KEV listing, or public POC is present in the input, so exploitation status is 'no public exploit identified at time of analysis' - real risk is bounded by the small deployment footprint rather than by attack difficulty. Data conflict to verify: the input marks a patch as available and cites PR #1207 / v1.11.0, but the PR #1207 diff shown only narrows the CORS allow-list, which the description itself states does NOT fix this issue (CORS is browser-enforced and irrelevant to direct cross-host HTTP). The actual authentication fix is not evidenced by the provided diff and should be verified against v1.11.0. |
| Exploit ScenarioDerived | An attacker on the same Wi-Fi/LAN as a wireless Reachy Mini publishes a malicious public Hugging Face Space, then sends a single unauthenticated POST /apps/install request naming that Space. The daemon downloads and pip/uv-installs it, executing the package's setup code and giving the attacker code execution on the robot. No public exploit is identified in the input, but the attack requires no credentials, no user interaction, and low complexity once on the network. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 23, 2026
Unauthenticated code installation on the Reachy Mini robot daemon (Pollen Robotics) allows any host on the same LAN to execute arbitrary Python code on the robot by posting an attacker-controlled Hugging Face Space to POST /apps/install. The endpoint is reachable without credentials because the wireless variant of the daemon binds to 0.0.0.0, and the handler's dependency chain (Depends(get_app_manager)) never performs an authorization check; the chosen Space's build/setup code is then executed by the daemon via uv or pip. Affected are all Reachy Mini units before the vendor's v1.11.0 patched release (CPE cpe:2.3:a:pollen_robotics:reachy_mini:*); there is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV), though the attacker prerequisites are trivial for anyone sharing the robot's Wi-Fi network. Scoring is AV:A/AC:L/PR:N/UI:N with high confidentiality, integrity and availability impact, consistent with full compromise of the robot host.
RemediationAI
Upgrade Reachy Mini to the vendor's patched release v1.11.0, available from https://github.com/pollen-robotics/reachy_mini/releases/tag/v1.11.0, which incorporates the fix tracked as https://github.com/pollen-robotics/reachy_mini/pull/1207; verify after upgrading that the daemon now requires authentication on POST /apps/install, because the CORS allow-list change shipped in version 1.8.2 (limiting allowed origins to localhost/127.0.0.1) does not close this vector at all - CORS is enforced by browsers and a direct cross-host HTTP request from another machine on the LAN bypasses it entirely, so a device that has only that change remains exploitable. If immediate upgrade is not possible, the most effective compensating control is to eliminate network exposure of the daemon on wireless units: force or override the bind host so the API listens on 127.0.0.1 rather than 0.0.0.0, or, if the LAN-reachability requirement forces 0.0.0.0, place the robot on an isolated network segment and restrict TCP access to the daemon port with host firewall rules that allow only explicitly trusted management addresses - the trade-off is that remote/companion tooling and LAN-based clients will lose connectivity unless they are added to the allow-list. Do not rely on network-layer obfuscation or on the CORS allow-list as a fix. As a detection measure for potentially already-compromised units, audit installed applications and the Python environments managed by the daemon for unexpected Hugging Face Space packages, since installation of an attacker-chosen Space results in arbitrary code execution on the robot.
Affected VersionsENISA
Affected Packages
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 is a small robot whose on-device daemon exposes a FastAPI/Starlette HTTP API (mounted in src/reachy_mini/daemon/app/main.py) for managing the device, including app installation. The vulnerable route is POST /apps/install in src/reachy_mini/daemon/app/routers/apps.py; its only declared dependency is Depends(get_app_manager), a FastAPI dependency that simply returns the shared app-manager object from application state, so no credential, token, or session check occurs anywhere in the request chain. This is the classic CWE-306 pattern (Missing Authentication for Critical Function): a security-critical operation - installing and executing code - is exposed on an interface with no authentication control at all. The endpoint accepts an AppInfo body naming a Hugging Face Space, downloads that Space, and installs it as a Python package through install_package in src/reachy_mini/apps/sources/local_common_venv.py using uv or pip. Because Python package installation executes the package's own build backend and setup code, control over the Space equals control over code that runs on the robot. Exposure depends on the bind address selected by _resolve_bind_host in main.py: wireless units bind 0.0.0.0 (the vendor's own comment notes the robot must be reachable on the LAN), whereas non-wireless units bind 127.0.0.1 and are therefore only reachable from localhost. A previously shipped change (version 1.8.2) replaced the daemon's wildcard CORS policy with an allow-list limited to localhost/127.0.0.1 origins; that mitigation only governs browser-enforced cross-origin reads and provides no protection here, since a direct HTTP request from another machine on the LAN involves no browser, no preflight, and no CORS enforcement.
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
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AV:A because the wireless build binds 0.0.0.0 exposing it on the LAN (not internet-wide); PR:N/UI:N as the endpoint checks no credential; installing a chosen package yields full RCE, so C/I/A:H.
Primary rating from Vendor (JFROG).
CVSS VectorVendor: JFROG
DescriptionCVE.org
The Reachy Mini daemon exposes an HTTP API for managing the robot. Its app installation endpoint, POST /apps/install in src/reachy_mini/daemon/app/routers/apps.py, has no authentication. The handler's only dependency is Depends(get_app_manager), which just hands back the manager object from application state, so nothing in the chain ever checks a credential.
The endpoint takes an AppInfo body naming a Hugging Face Space. The daemon downloads that Space and installs it as a Python package through install_package in src/reachy_mini/apps/sources/local_common_venv.py, using uv or pip. Installing a Python package runs the package's own build and setup code, so whoever chooses the Space chooses what code the robot runs. Anyone can publish a public Hugging Face Space, so this is not a meaningful restriction on the attacker.
How far this reaches depends on the model. In _resolve_bind_host in src/reachy_mini/daemon/app/main.py the daemon binds 0.0.0.0 when it runs as the wireless version and 127.0.0.1 otherwise, with the vendor's own comment explaining that the robot has to be reachable on the LAN. On a wireless unit, then, any host on the same network can install and run code on the robot without credentials.
One related change has already shipped but does not fix this. Version 1.8.2 replaced the wildcard CORS policy with an allow list of localhost and Tauri origins. That closes the browser drive-by route, where a web page the victim visits silently calls the endpoint in the background. It has no effect on this issue: CORS is enforced by browsers and governs whether script may read a response, while a direct HTTP request from another machine on the network involves no browser, no preflight and no CORS check at all.
Executive ViewAI
Pollen Robotics' Reachy Mini robot daemon exposes an unauthenticated code-installation endpoint, meaning any device sharing the robot's Wi-Fi or LAN segment can load and execute arbitrary Python code on the robot host, resulting in full compromise of confidentiality, integrity, and availability. Because no credentials or user interaction are required and the attack surface is adjacent-network, exposure is broad wherever these robots operate on shared or untrusted wireless networks, including labs, classrooms, showrooms, and event venues. Leadership should treat this as a fleet-wide physical and data risk rather than a single-device defect, as compromised robots can be pivoted into corporate networks and may hold credentials, telemetry, or safety-relevant control paths.
Apply vendor patch.
Threat Intelligence Overview
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
More in Reachy Mini
View allUnrestricted file upload in the Reachy Mini daemon (pip/reachy-mini prior to 1.8.2) permits any unauthenticated network-
Any Bluetooth device within radio range of a Reachy Mini robot can send CMD_ commands by piggybacking on another operato
EUVD-2026-85185
GHSA-8w3q-4cmj-h32j
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB