Skip to main content
← Back

Deny-by-Default Hosts, a Rust WebAssembly Toolchain Trap, and a RISC-V Sandbox

On the October 14, 2026 wasmCloud community call, Bailey Hayes warned that the next host release turns its newest policy controls (guest memory, socket egress, and hostPath volumes) to deny by default. She also explained a Rust WebAssembly guest-toolchain bug that makes some WASI P3 components trap on Wasmtime 48. Aditya Salunkhe then proposed a host component plugin that gives every workload its own RISC-V Linux sandbox, and the call turned into a discussion of why open standards win.

Key Takeaways​

  • The next release is stricter by default. Bailey marked the breaking changes with a ! in the commit log: feat(runtime)!: enforce guest memory and socket egress by default and feat(wash-runtime)!: refuse hostPath volumes outside the allowlist. These controls shipped in count mode first so people could try them. Each denial returns a specific error message
  • Some Rust WASI P3 guests trap on the current release. Components built with wit-bindgen 0.58 or earlier, WASI P3, and HTTP compat together contain an invalid component-model ABI sequence, which Wasmtime 48 now rejects. wasmCloud's tests missed it because every fixture is rebuilt with the latest tools in the same CI run as the host
  • The fix is to rebuild, not to patch at load time. Bailey closed PR #5669, which repaired legacy guests' bytecode as they loaded, because rewriting bytecode in the runtime is brittle and not safe enough. Instead, Eric Gregory's PR #5671 makes the host log recognize the trap and print the remediation: upgrade your tools and recompile
  • Docs for running against an external NATS. Issue #5676 asks for an example using a self-hosted NATS from the Helm chart, Synadia NGS, or both. Enterprise users ask about this often, and the setup will also go in the repo's deploy/ folder
  • The Python SDK is closer than planned, and the Bytecode Alliance is holding a four-hour, online-only Plumber Summit at the end of the month. Expected updates cover the component model, debugging, StarlingMonkey, componentize-py, and possibly componentize-go
  • New awesome-wasmcloud plugin ideas. Aditya Salunkhe filed issues for AMQP, MQTT, Sentry, Temporal, and Linux sandbox host component plugins. Bailey confirmed that wasi:http is the right interface for the Temporal plugin's gRPC calls. It supports HTTP/1, HTTP/2, and HTTP/3
  • A sandbox for your sandbox. The proposed Linux sandbox plugin wraps Vpod, which runs a full RISC-V Linux system inside one WASI 0.2 component. It needs volumes for host component plugins (#5674) first

Chapters​

Meeting Notes​

Roadmap Follow-Up​

Bailey Hayes opened a short call by walking through the wasmCloud Roadmap board from the previous week's Q4 planning session, where she had added a few issues based on ideas from the community Slack. The question enterprises most often send her privately is how to run wasmCloud against an external NATS. Issue #5676 asks for docs on wasmcloud.com and a setup example in the repo's deploy/ folder, covering a self-hosted NATS from the Helm chart, Synadia NGS, or both. Synadia contributed NATS to the CNCF and employs its core maintainers, and Bailey said most enterprises she talks to use Synadia's product.

The Python SDK spike on componentize-py is now likely to be ready for work sooner than Bailey estimated a week earlier. She also announced a Bytecode Alliance Plumber Summit: a four-hour, online-only session at the end of the month for the maintainers who do the behind-the-scenes work. It will have project updates on the component model, debugging beyond GDB, newer StarlingMonkey releases, componentize-py, and possibly componentize-go, and it will end with games. A blog post with the exact dates was about to be published. Smaller items went straight into the TypeScript repo, such as an example of using Postgres from TypeScript. The goal is for the Rust, TypeScript, Go, and eventually Python repos to have the same set of examples, and Bailey said these issues make good first contributions.

Breaking Changes: Deny by Default​

Bailey's threat-model work is heading for the main repo, partly so contributors' LLMs follow the security boundaries in the wash runtime. The next release turns several new capability controls from count mode to enforce: guest memory limits, socket egress, and hostPath volumes. The commit log marks these with a !, the Conventional Commits sign for a breaking change. They first shipped in count mode so people could try them before opting in to enforcement. Now they are on by default, in keeping with the project's goal of deny-by-default security. The unit tests check that each denial produces a clear error message, so upgrades that hit a new limit should be easy to diagnose.

A Rust Guest-Toolchain Bug in WASI P3​

A second, already-released issue affects Rust components. WASI P3 added native async to the component model and rebased the WASI APIs onto async. Much of that work was done before LLMs were good at finding soundness bugs, and there were few binary-level tests of the bytecode that guest toolchains produce. wit-bindgen before 0.59 cancels a read on its inter-task wakeup stream while that stream is still in a waitable set. That is invalid component-model ABI, and both wit-bindgen and Wasmtime 48 now reject it. wasmCloud moved to Wasmtime 48 in its last minor release. Its tests missed the problem because every fixture is rebuilt with the latest toolchain in the same CI run, so no test ran older guests against the stricter runtime.

The bug only affects components built with wit-bindgen, WASI P3, and HTTP compat together, which none of wasmCloud's examples do. That morning, Eric Gregory had landed detection for it. When a workload hits the trap, the host log names the known issue and the fix, and the release notes and FAQ describe it as well. Bailey had also tried an automatic fix, PR #5669, which swapped the bad instruction sequence at load time. She closed it. The project decided not to rewrite bytecode in the runtime to work around guest-toolchain bugs, because doing so is brittle and not safe enough. The remediation is to upgrade your tools and recompile.

awesome-wasmcloud: Temporal and a Linux Sandbox​

Colin Murphy, whom Bailey rarely sees on camera, said he calls in regularly. Aditya Salunkhe then shared five issues he had filed on awesome-wasmcloud for host component plugins: AMQP 0-9-1 (RabbitMQ), MQTT, Sentry error reporting, a Temporal activity worker, and a Linux sandbox. He warned that he wrote them with Claude's help and had only partly checked them. He had also filed a Kafka issue, but it turned out to be unnecessary because Cosmonic already maintains a Kafka host component plugin. The Temporal plugin needs only four calls from Temporal's gRPC API, which would let Temporal SDK code run inside a wasmCloud workload. Bailey confirmed that wasi:http is the right interface for gRPC. It supports HTTP/1, HTTP/2, and HTTP/3, so a component gets the best protocol for whatever it talks to. Shreya Deshannavar has started on the Temporal plugin.

The Linux sandbox plugin, Aditya's "sandbox for your sandbox," is built on Vpod. Vpod emulates a complete RISC-V Linux system, with a real kernel, Alpine, bash, Python, and apk, inside a single WASI 0.2 component. A host component plugin would wrap it in a small async P3 wrapper, so each workload can open its own named sandboxes, run commands, and move files in and out. Bailey suggested upstreaming WASI P3 support to Vpod, or using wasm-tools component new with the P3 adapter to turn a P2 component into a P3 one. She prefers going P3-native, because async, cancellation, and back pressure then come for free. Aditya said the interface needs a wrapper either way. Bailey said the design is safe because a host component plugin is already isolated from the workloads that call it. The plugin needs one more feature first: volume mounts for host component plugins, which Aditya proposed in an RFC (#5674). Bailey said the mounts belong on the bindings API and asked him to tell her when it is ready for review.

Why RISC-V Matters​

Victor Adossi explained why something like Vpod is possible. RISC-V is an open instruction set, so anyone can build faithful emulators and reference implementations, which is hard to do for x86 and Arm. Chip makers such as Espressif are moving from proprietary designs to RISC-V to avoid licensing costs. RISC-V's standards body is based in Switzerland and deliberately keeps any one company from steering it. Victor argued that this could become a route to running every program as WebAssembly. Instead of adding a Wasm target to every toolchain, you compile to RISC-V, which other people are already pushing forward, and run the result in a Wasm emulator. He also described his own RISC-V board with 32 GB of LPDDR5, which runs small models through a vendor fork of llama.cpp. Bailey noted that upstream llama.cpp has been merging work to compile to WebAssembly and WASI WebGPU, so the fork's maintainers might find upstream receptive.

Bailey said the RISC-V story mirrors WebAssembly's. She keeps seeing proposals to add a WebAssembly target to every Linux command, and they don't get standardized because what people want is the sandbox. Standards feel slow, but once something is standardized it can go into every toolchain, everyone is willing to build on it, and adoption keeps growing on its own. That is happening for RISC-V, and for WebAssembly and WASI.

Liam Randall closed the call and said a pull request with the previous week's meeting notes was on its way.

WebAssembly News and Updates​

In webassembly news this week, Wasmtime 48 began rejecting an invalid component-model ABI sequence emitted by older wit-bindgen guests. Most wasmCloud users will only notice this stricter check if they built WASI P3 Rust components with HTTP compat on wit-bindgen 0.58 or earlier. The Bytecode Alliance announced an online Plumber Summit for the maintainers behind the component model, debugging, StarlingMonkey, and componentize-py. Outside the core toolchain, Vpod runs a complete RISC-V Linux system inside a WASI 0.2 component, and llama.cpp has been merging work that compiles it to WebAssembly and WASI WebGPU.

What is wasmCloud?​

wasmCloud is a CNCF project for building applications out of WebAssembly components and running them across cloud, edge, and Kubernetes clusters. The Wasm component model lets you write business logic in Rust, Go, Python, TypeScript, C#, Java, and more. The platform supplies capabilities like HTTP, messaging, key-value storage, blob storage, and observability through standard interfaces and a pluggable host plugin architecture backed by Wasmtime. wash is the developer shell for building, running, deploying, and debugging. The runtime operator schedules Wasm workloads on Kubernetes the same way you schedule containers, with WASI Preview 3 support on by default. Together they give you a production platform for WebAssembly on Kubernetes and at the edge.

Topic Deep Dive: When a Rust WebAssembly Component Stops Working​

Rust WebAssembly components carry their toolchain's bugs with them, because the bytecode that wit-bindgen emits is baked into the .wasm file at build time. When a runtime gets stricter, as Wasmtime 48 did about how async guests cancel stream reads, a component that worked yesterday can trap today even though its source never changed. wasmCloud's CI rebuilt every test fixture with the newest tools. That kept the fixtures free of known CVEs, but it meant no test ran an old component against the new runtime.

wasmCloud had two options. It could detect the bad sequence and rewrite it at load time, as the closed PR #5669 did, or it could refuse the component and explain why. It chose the second. Rewriting untrusted bytecode inside the host widens the sandbox's attack surface and is likely to break when the next toolchain changes. Instead, the host recognizes the trap and logs the remediation. If you build async components with wit-bindgen, WASI P3, and HTTP compat, rebuild them with wit-bindgen 0.59 or later. See Rust language support, debugging components, and troubleshooting for the build and diagnosis steps.

Who Should Watch This​

Operators planning their next wasmCloud upgrade should watch the breaking-changes section at 5:33. Rust developers shipping WASI P3 components need the guest-toolchain explanation at 7:40. Platform builders looking for a first contribution should start with Aditya Salunkhe's awesome-wasmcloud plugin proposals at 13:38 and the RISC-V Linux sandbox at 16:10.

Up Next​

Expect the host release that turns on enforcement for guest memory, socket egress, and hostPath volumes, the Bytecode Alliance Plumber Summit blog post with confirmed dates, and a review of the volumes-for-host-component-plugins RFC once Aditya marks it ready.

Next call: wasmCloud 2.11: Wasm Runtime Autoscaling at 42,000 Workloads per Core, and TypeScript via Perry

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →