Skip to main content

Reachy Mini EUVDEUVD-2026-85185

| CVE-2026-96455 HIGH
Missing Authentication for Critical Function (CWE-306)
2026-09-23 JFROG GHSA-8w3q-4cmj-h32j
8.8
CVSS 3.1 · Vendor: JFROG
View

Attack ChainAIDerived

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

  1. Access
    Join same LAN as wireless robot
  2. Delivery
    Publish malicious Hugging Face Space
  3. Exploit
    Send unauthenticated POST /apps/install
  4. Execution
    Daemon pip/uv-installs package
  5. Persist
    Setup code executes
  6. Impact
    Arbitrary 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.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 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

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

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 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

Vendor (JFROG) PRIMARY 8.8 HIGH
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vuln.today AI 8.8 HIGH

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.

3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
4.0 AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

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

Why It Matters

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.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 94% exploitable
Prevalence
Low
niche open-source research/hobby robot from a single vendor, small installed base
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 HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.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
Scheduled
Exploitation
None
System Exposure· derived
Controlled
Automatable
No
Human Impact
High
Technical Impact
Total

Priority Score

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

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

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