Summary
The Reachy Mini daemon exposes an app-installation endpoint without authentication, allowing an unauthenticated caller to select a Hugging Face Space for installation. Because package installation executes build and setup code, a reachable daemon may run attacker-controlled code on the robot, particularly when the wireless service is accessible from the local network.
Affected context
The issue occurs in Reachy Mini daemon deployments that expose the HTTP API and enable the app installation route. Wireless deployments may bind the daemon to all network interfaces, making the endpoint reachable by other hosts on the same network, while non-wireless deployments may limit access to the local host. The selected Hugging Face Space is downloaded and installed as a Python package, so package installation can execute code supplied by the package author.
Exploit preconditions
- Attack surface: The Reachy Mini daemon HTTP API, specifically the app installation endpoint.
- Required access: Network connectivity to the daemon; no application credential is required.
- Trigger point: Processing an app-installation request that selects a Hugging Face Space.
- Why exploitation is possible: The endpoint lacks an effective authentication dependency, and the chosen package may execute attacker-controlled build or setup code during installation.
Why this happens
The endpoint relies on a dependency that returns an application manager but does not verify the caller's identity or authorization. This maps primarily to CWE-306, Missing Authentication for Critical Function, because a sensitive installation capability is exposed without credential checks. The resulting package installation behavior also relates to CWE-494, Download of Code Without Integrity Check, because externally selected code is downloaded and executed without an adequate trust or integrity boundary.
Potential impact
- An unauthenticated network caller may cause arbitrary package code to run on the robot.
- The robot's local data, credentials, or connected services could be exposed.
- The robot's behavior or installed applications could be modified.
- The compromise could enable persistence, safety-impacting actions, or further access depending on runtime privileges.
General mitigation guidance
Mitigation generally focuses on protecting the installation function and reducing trust in externally selected packages.
Common defensive patterns include:
- Require strong authentication and explicit authorization for app installation and management operations.
- Bind administrative services to the narrowest required interface and avoid unnecessary LAN exposure.
- Treat downloaded packages as untrusted and use allowlists, signed artifacts, provenance checks, and reproducible package sources where practical.
- Install and execute applications in isolated environments with least-privilege identities and restricted filesystem, network, and device access.
- Apply integrity verification before installation and separate package retrieval from privileged robot control.
- Do not rely on CORS as an access-control mechanism; enforce authorization at the server and network layers.
How teams detect issues like this
Organizations can detect this class of issue through:
- Static analysis and API policy checks that flag sensitive routes without authentication or authorization dependencies.
- Code review signals such as installation, update, or download handlers that accept externally controlled package names or repositories.
- Tests that verify unauthenticated requests are rejected across every network interface and deployment mode.
- Runtime monitoring for unexpected app-installation requests, package-manager activity, and outbound downloads from the daemon.
- Policy enforcement requiring signed or approved package sources before code installation.
- Automated security review tools can help identify missing authentication and untrusted code-download patterns, but should be supplemented with deployment-level testing.
