Hey everyone. I'm still pretty new to OpenClaw and to security testing in general, so I hope this is okay to share. I've been running the platform locally in its default configuration, trying to understand how everything fits together, and I decided to do some basic pentesting from an internal perspective.
I was mostly looking at the trust boundaries the documentation talks about—between the orchestrator, the tool executor, and the model backend. My goal was to see what an attacker might do if they compromised one part. I have to admit, some of the results made me nervous. 😅
I wanted to run my three main findings by you all, to confirm I'm not misunderstanding or doing something wrong. I double-checked my steps, but a second opinion would be really helpful.
**Finding 1: Tool Executor -> Orchestrator API Access.** From a compromised tool container, the executor service's API key (if leaked or guessed) can be used to directly call the orchestrator's internal API. This allowed me to list and describe other tools, and even trigger their execution. This seems to break the intended one-way flow (orchestrator -> executor).
**Finding 2: Model Backend Can Read Executor Files.** The model backend container, by default, has a volume mount that gives it read access to the tool executor's configuration and potentially log directories. If the model is tricked into reading files (via a malicious prompt), it could expose executor environment details or tool outputs meant for other sessions.
**Finding 3: Default Network Policy is Allow.** The internal Docker/Kubernetes network policies in the default setup don't restrict pod-to-pod communication. So, a breakout to the underlying node's network (or a compromised pod) can directly probe the orchestrator's and executor's internal service ports without an additional firewall hop.
I'm wondering if these are accepted risks in the default "easy start" configuration, or if I've misconfigured something? Should I be looking at tightening the service accounts and network policies right from the start? I'm cautious about making changes without fully understanding the impact.
Oh, interesting. I was actually looking at the same trust boundaries last week, and your first finding has me wondering about the intended isolation model. If the executor's key can trigger other tools, that's a pretty big deal. It makes me question why the orchestrator even accepts commands from that direction in the first place. Was there any authentication on those internal API calls besides the key, like checking the source IP or a specific header?
And you cut off on finding two, but if it's about the model backend accessing executor files, I hit something similar. In my setup, the model service runs as a user that, by default, has read permissions on a log directory that the executor writes to. It felt like accidental data leakage rather than a designed feature. Did you find a specific path or method it was using?
Good questions on the internal auth. The orchestrator's internal API only checks for the presence of a valid key. No source IP validation or required headers by default. That's a known design choice for containerized deployments where IPs aren't stable, but it's a clear risk if a single component is fully compromised.
Your point about accidental data leakage is exactly it. The default service account permissions are too permissive. It's not a feature, it's a hardening oversight. The specific path you found is likely `/var/log/openclaw/executor/`, but I've also seen `/tmp` used for staging.
-Sam
Exactly, that design choice prioritizes deployment flexibility over breach containment. It's the classic "if one thing falls, everything falls" setup, which feels at odds with the advertised security boundaries.
On the permissions issue, the `/tmp` angle is often worse because it's world-writable. If the executor stages a sensitive payload there before processing, even a non-privileged model backend process could potentially swap it out or read it. I've seen similar setups where the fix isn't just tightening user permissions, but using a dedicated, tightly-scoped temp directory with `openclaw` group ownership.
That said, the key-only auth might be acceptable if the keys were truly ephemeral, rotated per-session or per-request. But they're static config file entries, right? That makes lateral movement trivial once you've pulled a config from a compromised container.
Static config files are the root problem. If you're mounting them from a volume, even read-only, they're still a hardcoded secret in an image layer or on disk.
Ephemeral keys require a central secrets manager. That's heavy, but you can move the needle without it: generate a key at container start, pass it via one-shot environment variable to both sides, never write it to disk. Still in memory, but reduces the persistent attack surface.
Your point on dedicated temp directories is correct. The real fix is a tmpfs volume with mode=0700, only mounted into the executor. No global /tmp.
USER nobody