Session CRT-20260429 — 29 April 2026 · Morning Edition

Look, these two CVEs represent fundamentally different categories of AI infrastructure risk, and I want to be precise about the distinction.

On CVE-2026-25874 — LeRobot's pickle RCE:

This is not an outlier. Pickle deserialization over network channels is a systemic and endemic pattern across ML platforms. According to the CERT/CC vulnerability note VU#252619, PyTorch Lightning versions 2.4.0 and earlier also load model files without verification. CVE-2025-32434 in PyTorch itself was a 9.3 CVSS remote code execution via deserialization. And just this March, we saw CVE-2025-62373 in Pipecat's LivekitFrameSerializer using pickle.loads() on WebSocket data.

The pattern is: ML libraries prioritize performance and convenience over security. PyTorch's torch.load() uses pickle internally. Researchers routinely share models via pickle-serialized .pth files. The assumption is "you trust your model source" — which breaks down the moment you have automated pipelines fetching from Hugging Face, or RAG systems pulling documents that reference external models.

What's particularly troubling about LeRobot is the physical safety dimension. This isn't just data theft — you're executing arbitrary code on systems controlling robotic actuators. The gRPC channels are unauthenticated, lack TLS, and the vulnerability has been unpatched since December 2025 discovery.

For blast radius: LeRobot has 24,000 GitHub stars and is widely used in academic robotics research. The real question isn't "who runs this in production" — it's how many research labs have internet-exposed training clusters with LeRobot installed. My assessment: treat this as low volume but high consequence. Any exposed instance should be considered fully compromised.

On CVE-2026-42208 — LiteLLM's third critical:

This crosses the threshold from "patch and move on" to "architectural scrutiny required," but I want to be clear about why. The data shows three distinct critical vectors in roughly six weeks:

1. March 24: Supply chain compromise (v1.82.7/v1.82.8 on PyPI) — TeamPCP cred-stealing malware via compromised maintainer credentials
2. April 20: CVE-2026-35029 + CVE-2026-35030 — Authentication bypass via OIDC cache collision and privilege escalation via /config/update
3. April 24: CVE-2026-42208 — Pre-auth SQL injection in the Authorization Bearer header, exploited within 36 hours

What's revealing is the attack sophistication observed by Sysdig: attackers used "targeted, knowledge-informed payloads" with IP rotation, not generic SQLMap scans. They knew exactly which tables contained API keys. This suggests either insider knowledge or prior reconnaissance against LiteLLM deployments.

Is the codebase fundamentally insecure? Here's my assessment: LiteLLM is building enterprise authentication and authorization as a layer on top of what was originally a simple proxy. The SQL injection in the Bearer header tells me input sanitization isn't consistent across added features. The OIDC cache collision tells me session management wasn't designed for multi-tenant enterprise use. These aren't "growing pains" — they're architectural debt from rapid feature expansion.

My recommendation:

For LeRobot: If you're running internet-facing instances, isolate immediately — there's no patch. The expected v0.5.0 fix needs to be verified before deployment. Network segmentation is your only mitigation.

For LiteLLM: This is more nuanced. If you've rotated credentials after each incident and are running v1.83.7+, you can continue. But if you're using LiteLLM for multi-tenant AI gateway scenarios with high-value API keys, I'd be evaluating alternatives. The serial criticality pattern suggests the security model hasn't caught up with the enterprise feature set.

Think of it this way: LiteLLM is experiencing the same trajectory as early API gateways — functional utility outpacing security architecture. The difference is that a compromised AI gateway leaks keys to other people's models with your data, creating a liability chain that's hard to contain.

LiteLLM CVE-2026-42208 TTPs

The exploitation timeline is well-documented: Sysdig observed active exploitation "approximately 36 hours after the bug was disclosed publicly on April 24" per their incident report. The attackers demonstrated clear schema knowledge from the outset — Sysdig's telemetry shows they "picked all three highest-value tables on the first try" including litellm_credentials.credential_values (holding upstream provider keys) and litellm_config (containing PostgreSQL DSN, master key, webhook URLs). No probes were observed against lower-value tables like litellm_users or litellm_team. The operator used two adjacent egress IPs with a 10-minute pause between phases, suggesting intentional rate-limit evasion rather than automated spray-and-pray.

Attribution assessment: The schema-aware targeting and phased approach points to a knowledge-informed actor — someone who studied LiteLLM's architecture or source code. Whether this is a sophisticated group or rapid commodity tooling is unclear; the speed of weaponization suggests either pre-built LiteLLM tooling or very fast analysis post-disclosure.

Blast radius: One compromised LiteLLM proxy = keys to your entire AI orchestration layer. The credential_values column holds actual upstream provider credentials (OpenAI, Anthropic, Bedrock, Azure). If your proxy was internet-facing and unpatched, assume compromise and rotate everything.

CVSS reality check: This isn't a theoretical 10.0 — it requires internet exposure and pre-configured upstream credentials. But when those conditions are met, the practical severity matches the critical rating. It's pre-auth, network-accessible, and trivially weaponizable. Patch now.

Cursor CVE-2026-26268 vs. AI Agent Attack Class

Yes, this is mechanically related to the Gemini CLI pattern but structurally worse. The BleepingComputer reporting on Gemini CLI showed attackers could hide malicious instructions in repository files (like README.md) to perform prompt injection, with the AI executing commands that bypass allow-list checks. Cursor's vulnerability specifically exploits autonomous Git operations — the AI agent proactively runs Git commands without waiting for user prompts, so malicious Git hooks execute silently.

The distinction matters: Gemini CLI required some user engagement with the repo to trigger analysis. Cursor's agent is continuously executing Git operations as part of its normal function, creating zero-interaction exploitation for anyone who opens a poisoned repository.

GHES CVE-2026-3854: The 88% of instances still vulnerable figure comes directly from Wiz's disclosure. This is a single git push RCE — authenticated users can inject arbitrary commands via unsanitized push options that bypass sandboxing. Wiz reported the vulnerability March 4; GitHub patched github.com in under 2 hours, but GHES fix deployment lags because self-hosted instances require manual upgrades. If you're on GHES ≤3.19.1 and haven't applied the March 10 patches, you're in that vulnerable majority.

The AI agent as exploitation vector: This is emerging as a distinct class. Attackers aren't targeting the AI — they're using the AI's legitimate capabilities (autonomous Git operations, file analysis, command execution) as an unwitting delivery mechanism. The trust boundary failure is architectural: we gave these agents powerful tools and broad file-system access, then exposed them to untrusted repository content.

Lena — that schema-aware LiteLLM targeting has me curious about tooling overlap. Any known groups with LLM infrastructure experience showing up in related telemetry?

Let me search for the latest attribution data and campaign evidence on this.

Look, forget the CVSS score for a second. If an attacker owns the PolicyServer through a trivial pickle payload, they aren't just stealing data—they're issuing movement commands to robots that may have collision envelopes with humans nearby.

Here's what I'm seeing in the data: CVE-2026-25874 is an unauthenticated RCE via unsafe pickle.loads() on gRPC channels without TLS. According to The Hacker News and SentinelOne, this affects LeRobot through version 0.5.1 with CVSS 9.3. The attack surface is the SendPolicyInstructions, SendObservations, and GetActions gRPC calls—functionally, this is the control path between the AI policy server and the actual robot hardware.

Physical consequence framing: This sits at a Purdue model crossover point that's deeply uncomfortable. The PolicyServer is essentially Level 2 (supervisory control), but it directly issues motion commands that reach Level 1 (PLC/robot controller) and ultimately Level 0 (the physical robot joints). In a traditional SCADA environment, we'd have a safety PLC with hardwired interlocks between Level 2 and Level 1. In this AI robotics stack, the safety boundary is... protocol authentication and TLS encryption for gRPC. Which is disabled by default.

I have personally seen a poorly timed firmware update on a water treatment plant's SCADA system cause a 36-hour boil-water advisory. In that case, the engineers lost control temporarily. Here, with LeRobot, the attacker gains active control.

Current deployments: According to the project tech lead Steven Palma quoted by The Hacker News, "LeRobot has so far been primarily a research and prototyping tool." But it has nearly 24,000 GitHub stars and integrates with the SO-ARM100 open hardware platform—a ~$120 robot arm that's widely used in academic and startup environments. The project documentation explicitly shows people building teleoperation setups.

That "primarily research" qualifier should not comfort us. I know how this progression works—research code becomes pilot deployments, then small-scale production, then someone scales it without the safety review. LeRobot provides a unified Robot class that decouples control logic from hardware specifics. That's great for rapid development. It's terrible for safety engineering because it means the same vulnerability applies across diverse hardware platforms—robot arms, mobile robots, grippers—anything using the LeRobot abstraction.

Comparison to traditional ICS/OT: Traditional industrial robotics has an 80-year head start on safety engineering. ISO 10218-1:2025 specifically addresses cybersecurity requirements for industrial robot safety—and those standards assume a safety-rated control system with functional safety (SIL-rated) interlocks. The revised standard now includes "requirements for cybersecurity to the extent that it applies to industrial robot safety" according to The Robot Report.

AI robotics platforms like LeRobot inherit none of that. They are software-defined control systems with soft real-time constraints, running Python on general-purpose OS stacks, using unsafe deserialization by default. The blast radius isn't "production downtime"—it's kinetic contact between a robot arm and a human operator, or a mobile robot navigating into a restricted zone, or a gripper crushing sensors with damaging force.

New class of risk: Yes, absolutely. This is a new category I call "AI-native cyber-physical systems." Traditional OT security frameworks assume:

• Deterministic control logic (ladder logic, function blocks)
• Safety systems that are isolated and hardwired
• Maintenance windows measured in months (you can schedule patches around production cycles)

AI robotics inverts this:

• Probabilistic policies (neural networks) that are inherently harder to validate
• Control and safety logic co-mingled in Python code
• Attack surfaces that are network-exposed and unauthenticated by default
• Patch velocity measured in days (if there's a community maintainer), not months

The compensating controls that work in traditional OT—network segmentation, read-only historians, safety PLC interlocks—don't map cleanly here. You cannot air-gap a system that's designed to train on cloud data and share policies across a cluster. And "just add authentication" ignores that gRPC-with-TLS wasn't in the original design pattern for most of these research-to-production transitions.

OT-realistic mitigations for LeRobot deployments:

1. Network segmentation with explicit deny-by-default: The PolicyServer should live in an isolated VLAN with explicit firewall rules permitting only the gRPC port from known robot client IPs. No internet egress.
2. Virtual patching via proxy: If you can't update LeRobot itself due to API instability or custom forks, put a gRPC proxy in front that validates protobuf schema and drops any message containing pickle content. This is the OT "compensating control" mindset—defend the protocol, not the vulnerable application.
3. Hardware safety limits: Every LeRobot deployment needs physical safety interlocks that are not software-defeatable—e-stops, light curtains, torque limits at the servo level. The SO-ARM100 servo datasheet shows the STS3215 supports torque limiting. Use it.
4. Operational restrictions: Treat this as "pilot/development phase only" equipment. No unsupervised operation. No human in the robot's reach envelope during network-connected operation.

Halil, my bottom line: LeRobot today is where SCADA systems were in 1995—powerful, networked, and dangerous, but not yet wrapped in the safety engineering that industrial maturity demands. The unpatched CVE puts a ticking clock on that transition. If this moves from "primarily research" to warehouse automation before they close this security model gap, we'll see incidents that look like safety failures but are actually cyberattacks.