Reachy Mini CVE-2026-96455: your LAN can install code on it

The desktop robot on your office shelf will install and run a Python package for anyone who asks it nicely over HTTP. CVE-2026-96455, disclosed on September 23 against Pollen Robotics' Reachy Mini, is a CVSS 8.8 missing-authentication flaw (CWE-306) in the robot's daemon. It is a small device and a small bug, and it is the cleanest example this month of a problem most small offices now have: AI hardware that ships as an unmanaged endpoint on the same flat network as everything else.

What actually happened

The flaw is in the app installation route. You can read it yourself in the project's source:

@router.post("/install")
async def install_app(
    app_info: AppInfo,
    app_manager: "AppManager" = Depends(get_app_manager),
) -> dict[str, str]:

The handler's only dependency is get_app_manager, which returns the manager object out of application state. Nothing in that chain checks a credential. The endpoint takes a body naming a Hugging Face Space, downloads it, and installs it as a Python package. Installing a Python package executes the package's own build and setup code — so whoever picks the Space picks what the robot runs, with the robot's privileges.

On wireless units the daemon binds to 0.0.0.0, so the attack is adjacent-network: any host on the same Wi-Fi can do this. No credentials, no user interaction. A companion issue, CVE-2026-96456 (CVSS 6.3), covers a race condition in the Bluetooth service.

This is not the first one. The vendor has published GitHub advisories for CVE-2026-62661 (Bluetooth directory traversal leading to root, August) and CVE-2026-55419 (unrestricted file upload, June) — and that August advisory describes those as links in a chain from unauthenticated access to full root. As of publication we found no GitHub security advisory from Pollen Robotics for CVE-2026-96455 itself, so treat the fix status as unconfirmed rather than shipped.

Why AI hardware on your network matters for your business

Nobody reading this runs a robot farm. Plenty of you have a smart display in reception, a camera kit doing shelf counts, a voice device in the back office, or a demo unit somebody's kid picked out at a trade show. The Reachy Mini pattern applies to all of them.

The design flaw is the category, not the device. An AI gadget's whole value proposition is that it pulls and runs code from a hub — a Space, a skills store, a plugin registry. That is a package manager with a network listener, shipped to consumers, configured by a hobbyist. Treat every one of these as a machine that will eventually execute something you did not choose.

Three things to do this week, none of which require a security budget:

1. Put it on a separate VLAN or the guest SSID. Adjacent-network attacks need adjacency. Most consumer AI hardware needs outbound internet and nothing else — it does not need to see your POS terminal, your NAS, or the laptop with the QuickBooks file.
2. Inventory what listens. Walk your office Wi-Fi with nmap -sV or your router's client list and write down every device with an open port. If you cannot name the vendor and the firmware version, it does not belong on the production network.
3. Check whether the vendor publishes advisories at all. Pollen Robotics does, via GitHub — that's a point in its favor, and more than most consumer AI hardware offers. A vendor with no security contact and no advisory feed is a vendor that will never tell you when this happens.

The trade we'd make: we do not tell clients to rip out useful hardware over a LAN-adjacent CVE. We tell them the blast radius has to be a segment they can afford to lose. That is a one-evening network change, and it survives the next bug in the next device, which is the actual point.

Sources: pollen-robotics/reachy_mini source, CVE-2026-96455, GHSA-vg3x-4hxm-3gxm.