CVE-2026-25874: unauthenticated RCE in Hugging Face's LeRobot puts pickle deserialization back on a robot's control plane

Resecurity's disclosure of CVE-2026-25874, covered by The Hacker News in April 2026, describes a vulnerability that's uncomfortably simple to explain and uncomfortably serious to have shipped: Hugging Face's LeRobot — a widely used robotics and policy library — deserializes attacker-controlled data with Python's pickle.loads(), over a gRPC channel that requires no authentication and runs without TLS. Reported CVSS scores vary by source — 9.3 in some, 9.8 in others — but every source agrees on the category: critical, unauthenticated, remote code execution.

Where the vulnerability actually sits

LeRobot's async-inference architecture includes a PolicyServer component that communicates over gRPC through calls like SendPolicyInstructions, SendObservations, and GetActions. These are the plumbing by which a robot or client sends observations to a policy server and receives back the actions the policy decides on — the basic loop of a robotics control system. The problem is that data arriving through these calls gets passed to pickle.loads(), and as with every other pickle-deserialization vulnerability, that function doesn't just parse data, it can execute arbitrary code embedded in the stream as a side effect of parsing it.

Two things compound the severity here beyond the pickle issue itself. First, the gRPC channel is unauthenticated — there's no check that the caller sending SendObservations or SendPolicyInstructions traffic is a legitimate robot, client, or operator. Second, the channel runs without TLS, meaning no confidentiality or integrity guarantee on the wire even before you get to the deserialization problem. The combination means anyone who can reach the PolicyServer's gRPC port over the network can send a crafted pickle payload and get code execution, with no credentials, no prior access, and no ability for the deserializing side to distinguish attacker traffic from a legitimate robot or client.

Affected versions run up to and including LeRobot 0.5.1, with a fix in later releases.

Why "just don't use pickle for untrusted input" keeps not happening

This is not a novel category of bug. Pickle's execute-on-load behavior is documented, well-known security guidance says don't deserialize untrusted pickle data, and yet it keeps reappearing at the center of AI/ML tooling vulnerabilities — the nullifAI models found on Hugging Face used the same underlying property, just through a different exposure path (a downloaded model file rather than a network call). What LeRobot's case adds is the network dimension: this isn't a file a user has to choose to download and load, it's data arriving continuously over an open network service as part of the system's normal operating loop. There's no equivalent of "only load models from trusted sources" available to a service that has to accept observations from whatever's talking to it on the wire.

Why RCE in a robotics control-plane library is a different risk category

Most unauthenticated RCE findings, however severe, resolve to compromising a server: an attacker gets a shell on a machine, and the consequences — data theft, lateral movement, ransomware — play out in familiar territory. LeRobot's PolicyServer sits in a different kind of loop. It's the component deciding what actions a physical system takes based on what it observes. An attacker who achieves code execution on a policy server in this architecture isn't just compromising a computer; they're positioned to influence or fully control the decision-making layer between a robot's sensors and its actuators.

That distinction matters because the failure modes on the other side of that RCE are physical, not just informational. A compromised web server leaks data or gets used as a pivot point. A compromised policy server in a robotics deployment can be made to issue arbitrary actions to physical actuators — the specific consequences depend entirely on what the robot is attached to and what it's capable of moving, gripping, or applying force to. As AI-driven robotics moves from research labs into warehouses, manufacturing lines, and other physical environments, the population of systems where "RCE on the control software" translates into "attacker-controlled physical actuation" is growing, and the security bar for the libraries sitting in that path needs to reflect that they're not just software anymore — they're the layer between a network packet and something that moves in the real world. An unauthenticated, unencrypted deserialization vulnerability in that exact layer is about as close to a worst-case combination as this category gets.

What to check this week

• Identify whether you're running LeRobot 0.5.1 or earlier anywhere in your environment, including research, prototyping, and pilot deployments — robotics tooling often ships in less formally tracked environments than production web services, which makes inventory the first real gap to close.
• Upgrade to a fixed release before exposing any PolicyServer instance to a network, even an internal one; "internal network" is not a substitute for authentication when the payload is arbitrary code execution.
• Treat any gRPC or RPC service that deserializes with pickle as untrusted-input-unsafe by default, whether or not you built it, and require an explicit authentication and TLS layer in front of it rather than assuming the framework provides one.
• Segment robotics control-plane networks from general-purpose network access, since a control-plane RCE in this category has physical-world consequences that standard IT incident response isn't built around.

How Safeguard helps

Safeguard's AI-BOM and AI-SPM discovery identifies where libraries like LeRobot are deployed across your environment — including research and pilot systems that tend to fall outside standard asset inventories — and flags known-vulnerable versions like the pre-fix LeRobot releases affected by CVE-2026-25874. Because pickle deserialization is a recurring root cause across this incident family, Safeguard's model-artifact and dependency scanning is built to recognize pickle-based deserialization paths as a category worth flagging on its own, not just waiting for a named CVE to catch up. Combined with reachability analysis that distinguishes a vulnerable dependency sitting unused from one actually exposed on a network path, and continuous monitoring that re-checks deployed inventory as new disclosures land, the goal is to catch exposures like an internet- or network-reachable PolicyServer before an unauthenticated caller finds it first.