# When Your AI Assistant Becomes the Attack Surface: LLM Poisoning in OpenClaw
A networking misconfiguration in OpenClaw — the AI gateway framework running agentic workflows for organizations across healthcare, IT services, and operations — opens a path for adversaries to corrupt the LLM's context in real time. Researchers are calling it "Finding Nemo(Claw)," and the pun is the friendliest thing about it.
The core issue isn't exotic: unauthenticated or improperly validated network endpoints in OpenClaw's architecture allow external content to be injected into active LLM sessions. The result is what researchers classify as runtime LLM poisoning — the model thinks it's receiving trusted system context, but an adversary has slipped something else into the pipeline.
---
## Not Your Grandmother's SQL Injection
LLM poisoning occupies a strange middle ground in the vulnerability taxonomy. It's not quite prompt injection (which typically requires user-controlled input reaching the model through normal channels), and it's not training data poisoning (which requires upstream access to the model's learning pipeline). Runtime context poisoning via a networking flaw is its own category — and it's one defenders have been slow to think clearly about.
Here's how it works in the OpenClaw case: the framework routes LLM requests through a network layer that, under certain conditions, can be intercepted or directly addressed without proper authentication. An attacker positioned on the same network segment — or exploiting a misconfigured binding on an exposed port — can inject arbitrary content into the LLM's context window. The model receives this content as if it came from a legitimate source: the system prompt, a prior assistant turn, tool output, or memory retrieval.
From that position, the attack surface is significant. Adversaries can:
The last point deserves emphasis. Most LLM security research treats poisoning as a single-session problem. In agentic frameworks like OpenClaw, where agents maintain memory, write to shared stores, and pass context between instances, a successful poisoning event can be considerably more durable.
---
## The Trust Boundary Problem, Restated
The deeper issue here isn't OpenClaw-specific — it's a design philosophy that the AI framework community has not fully reckoned with.
Traditional software security is built on the assumption that trust boundaries are explicit and enforced. Input from the network is untrusted. Input from authenticated internal services may be trusted, depending on context. The model is a function: you give it input, it produces output, and what matters for security is controlling that input.
LLMs break this model in a subtle way. Modern foundation models are trained to be helpful, to follow instructions, and to treat certain structural cues (system messages, tool outputs, prior conversation turns) as authoritative signals about how to behave. When a networking vulnerability collapses the boundary between "content the model should trust" and "content anyone on the network can write," the model has no way to detect the difference.
It will follow the injected instructions. That's not a bug in the model — it's the model doing exactly what it was designed to do.
OpenClaw deployments that run with elevated agent permissions are the worst-case scenario here. An agent that can read files, execute shell commands, send messages, or access external APIs represents a significant blast radius if its context can be externally manipulated. The networking issue transforms OpenClaw from an AI assistant into a remotely-programmable action executor.
---
## Scope and Exposure
OpenClaw is deployed as a multi-instance framework — organizations typically run it with several simultaneous agent instances, often as systemd services, handling different functional domains. This architecture means a single vulnerable network endpoint doesn't just expose one session; it potentially exposes all running instances sharing the same network segment or gateway.
Environments where this risk is most acute:
The networking fix matters, but it's a necessary rather than sufficient response. The underlying architectural question — how much trust should an LLM framework place in network-delivered context, and how should it validate that trust — doesn't go away with a patch.
---
## What Defenders Need to Do Right Now
If you're running OpenClaw, the immediate priority is understanding your network exposure:
1. Audit which ports OpenClaw's gateway and any associated services bind to, and whether those bindings are restricted to localhost or exposed to broader network segments
2. Verify authentication requirements on all endpoints that feed content into active LLM sessions — including health-check endpoints, memory retrieval APIs, and tool output channels
3. Review agent permissions aggressively — any agent that doesn't need shell access, file writes, or external API calls shouldn't have them, regardless of this specific vulnerability
4. Inspect persistent memory stores (vector databases, session logs, shared context files) for signs of anomalous content that could indicate prior poisoning
5. Enable logging at the LLM gateway layer if you haven't — you need visibility into what context your agents are actually receiving, not just what you intended to send them
Longer term, this is a prompt for conversations about LLM application architecture that many teams are overdue to have. The practice of letting agents maintain persistent memory with minimal validation, and of treating all content that arrives via internal network paths as trusted, needs to be reconsidered.
---
## HackWire Analysis
This vulnerability lands at a moment when agentic AI deployments are scaling faster than the security frameworks to govern them. OpenClaw isn't unique in having this problem — it's among the first to have it documented publicly, which may say more about disclosure rates in the AI tooling space than about OpenClaw's relative security posture.
The pattern here echoes something the security community learned slowly and painfully with SSRF: network-adjacent services that look internal aren't automatically trusted, and frameworks that treat them as such get burned. LLM frameworks are repeating that lesson, with the added complication that the "payload" being manipulated isn't just data — it's the instruction set for an AI system that may have significant real-world action capabilities.
What's missing from most coverage of this class of issue is the memory persistence angle. Single-session poisoning is bad; cross-session poisoning that propagates through shared vector stores or agent memory is potentially catastrophic in enterprise deployments. Organizations running multi-agent orchestration with persistent memory should treat any networking vulnerability in their LLM gateway as a potential persistence mechanism for attackers, not just a session-level compromise.
The "Finding Nemo" branding will get this research attention, and it deserves it. But the fix isn't just patching a port binding. It's building LLM applications with the same paranoid skepticism about network-delivered content that well-run web applications apply to user input. The AI security community hasn't internalized that norm yet. Incidents like this one will teach it.
— HackWire Editorial
---
## Related Coverage