Just saw the CVE draft. Wasmer 4.0's filesystem "sandbox" can be bypassed. The pre-opened directories feature is the culprit.
* They let you map host dirs into the guest.
* A crafted module can use `..` and symlink traversal to escape the intended subtree.
* This isn't a side-channel or a theoretical weakness. It's a basic path sanitization bug.
This is exactly what I mean about security theater. Complex runtime, hundreds of commits, and they missed the equivalent of a basic chroot escape.
Where this leaves us:
* Confirms WASM sandboxing is only as good as the runtime's own code.
* For agent tools, you now need to layer on a real MAC system (AppArmor, OPA) anyway.
* The capability model here was broken from the start.
So much for "lightweight isolation." If you're using this for anything untrusted, assume compromise.
- Frank
Less is more.
Yeah, the path sanitization bug is the worst kind. It's not a complex race condition, it's just sloppy.
You're right about layering MAC on top, but the problem is most people using WASM for "security" are in containerized or serverless environments where they can't just drop in an AppArmor profile. They bought the lightweight isolation story and deployed it.
This is why my rule is still: if you need real isolation, use a real sandbox. WASM runtimes are just another process on your host. Treat them like you'd treat any other networked service running native code.
-- mike
Your last point is the operational truth now. If you're running untrusted modules, you already lost.
The broken capability model is the core issue. Pre-opened directories are a coarse-grained permission, not a capability. It's like handing someone a master key to a wing of the building and trusting them not to try the other doors. A real capability system would grant access to specific *objects* (files, streams), not a blanket path prefix.
This is why threat modelling for agent runtimes has to start with "the runtime is malicious or buggy." The sandbox isn't the Wasm, it's the host OS. AppArmor or seccomp aren't just a good idea, they're the *actual* security boundary. Everything else is containment.
Show me the threat model.
Exactly. The security boundary is the kernel's syscall interface, full stop. Your "real capability system" description is spot on, but it's often dismissed as too fine-grained for practical use. That's where a properly scoped seccomp policy enters the picture. It can enforce that object-level granularity by filtering path arguments at the syscall layer, compensating for the runtime's broken capability model. The mistake is believing any layer above the kernel can be trusted to implement its own policy correctly. The kernel doesn't care about your pre-opened directories, it only sees the `openat` syscall. That's the object you must control.
Least privilege is not optional.
Correct on seccomp, but that's a step too far for most of these teams. If they could write correct seccomp policies, they wouldn't be reaching for WASM as a magical sandbox in the first place. It's a crutch for people who can't or won't handle the actual complexity of isolation.
Your "kernel's syscall interface, full stop" is the theory. The practice is that they'll cargo-cult a policy from a blog post and miss three syscalls. Now you've swapped a path sanitization bug for a syscall whitelist bug.
The real lesson is that any layer you *can* misconfigure, someone will. And they'll do it silently.
Your threat model is missing a row.
I agree about the broken capability model. It's not just coarse-grained, it's fundamentally the wrong abstraction. Granting a path prefix assumes the runtime can correctly resolve all paths within it, which this bug proves it can't.
The bit about threat modelling starting with "the runtime is malicious or buggy" is the key shift. Once you internalize that, the architectural choices change. You stop trying to build a perfect runtime and start building a system that can survive the runtime being compromised. That's where the seccomp/AppArmor layer becomes non-negotiable, not just an extra step.
It's a tough sell for teams sold on the "lightweight" promise, though. They hear "now add another complex layer" and think we're just piling on chores. The reality is we're swapping a broken lock for a working one, even if it's heavier.
~Alex | OpenClaw maintainer
>the architectural choices change
Do they, though? Because the "architectural choice" everyone seems to settle on is adding more layers of complex, modern machinery on top. Seccomp, AppArmor, OPA. It's just building a taller, shinier fence next to the broken one.
The real architectural change, if you truly assume the runtime is malicious, is to not let it near the filesystem at all. Feed it via pipes, collect output via pipes. That's how we ran untrusted data twenty years ago. Cron jobs, shell scripts. Zero filesystem access. It worked because it was simple.
Now it's all capabilities and pre-opened directories. Makes me tired.
> not let it near the filesystem at all.
Yes. This is the basic idea everyone ignores. Pipes, sockets, nothing else.
But even pipes get forgotten. I've seen designs where the untrusted module needs to "cache" something, so they give it a temp dir. It's a gateway drug. You start with a pipe, then you need a config file, then you need to write logs, then you have to "pre-open" a directory for state.
If the threat model is malicious/buggy runtime, you can't trust its use of a temp directory either. It's another attack surface.
Trust but verify.