WebAssembly Hardening Articles

Plugin ecosystems that accept Wasm binaries via pull request face a distinct threat: a PR that looks like a new feature may contain a plugin that requests excessive capabilities or embeds a malicious host function call. Reviewing Wasm binary PRs requires capability diffing, static analysis of imports/exports, and a signing gate before any plugin is deployed.

WebAssembly's component model and Wasmtime's epoch-based interruption enable replacing a running Wasm module with a patched version without restarting the host process. This is directly applicable to CVE patching of Wasm-based plugins, edge functions, and policy engines — eliminating the downtime that normally accompanies a security patch.

The WebAssembly GC proposal (shipped Chrome 119, Firefox 120, Wasmtime 2025) changes memory ownership from linear buffer semantics to garbage-collected object graphs. Multi-tenant Wasm runtimes that sandbox multiple users on shared infrastructure face new isolation challenges from finalizer side-channels, reference type aliasing, and GC root visibility.

Asyncify (Emscripten's coroutine transformation for Wasm) restructures binary layout, enlarges stack frames, and adds unwind/rewind control flow paths; the transformation changes the attack surface of a Wasm module in ways that standard security analysis of the pre-transformed source does not capture.

Wasmtime, WasmEdge, wasmer, wazero, and V8's Wasm engine each have their own CVE histories; as the CVE surge affects runtime dependencies, organisations embedding Wasm runtimes must track runtime-specific advisories, pin runtime versions with digest verification, and automate update triggers when runtime CVEs are published.

NJS (NGINX JavaScript) runs as a privileged extension of the NGINX worker process with full access to request context and no sandbox boundary; compare the security model of NJS scripting against Wasm filter isolation for untrusted or complex routing logic.

The shared-everything threads proposal extends Wasm shared memory to GC objects, breaking the per-thread memory isolation that existing sandboxes rely on; new handle-based access control and synchronisation audit requirements for runtimes enabling this feature.

Wasm's deterministic execution and module signing produce verifiable audit records that prove a specific model inference function executed on specific inputs; build tamper-evident AI decision logs for regulated use cases using Wasm execution attestation.

Wasmtime's epoch interruption system allows hosts to safely terminate long-running or malicious Wasm modules without undefined behaviour; configure per-module deadlines, cooperative yield points, and production timeout policy to prevent resource exhaustion and enable DoS-resistant plugin execution.

WebAssembly provides capability-controlled sandboxing for LLM agent tool plugins, preventing tool calls from escaping their permission boundary; compare Wasm-based isolation with process-based alternatives and implement a secure plugin host using Extism or Wasmtime.

The Wasm multi-memory proposal enables multiple separate linear memories within a single module; use dedicated memories for cryptographic keys and PII to limit blast radius on buffer overflows and prevent cross-memory pointer leakage.

CVE-2026-3910 (V8 inappropriate implementation in WebAssembly) and CVE-2026-2796 (JIT miscompilation in the JavaScript/WebAssembly component) are the latest in a series of browser WASM sandbox escapes. Server-side WASM runtimes — Wasmtime, WasmEdge, wazero — face structurally similar JIT and type-confusion risks. This article analyses what browser WASM exploits reveal about the trust model for server-side WASM, and what production operators should do differently.

The Wasm coredump spec dumps full linear memory on trap, exposing secrets, PII, and cryptographic material; disable coredumps in production runtimes, scope them to non-sensitive workloads, and implement post-process scrubbing pipelines where debugging requires coredump access.

ContainerSSH's authentication and config webhook is a critical-path HTTP service — every SSH connection waits for it. Running this webhook as a WebAssembly function on Cloudflare Workers or Fastly Compute moves authentication to the network edge, reducing latency, eliminating a central server bottleneck, and sandboxing the policy logic in a WASM runtime. This article covers the ContainerSSH webhook contract, implementing it as a WASM edge function with OIDC token validation, and the security model of edge-deployed auth.

Copa's scanner plugin interface accepts vulnerability reports via stdin as JSON, making it possible to write custom scanner adapters that feed non-Trivy data sources into Copa's patching engine. Compiling these adapters as WebAssembly components enables sandboxed, portable plugin execution — the plugin cannot access the host filesystem or network beyond what Copa explicitly grants. This article covers the Copa plugin JSON contract, building a WASM scanner adapter, and the security model for sandboxed Copa plugins.

Envoy's WASM filter SDK allows running API security logic — rate limiting, input validation, JWT inspection, schema enforcement — as WebAssembly modules in the proxy sidecar. WASM isolation means a bug in the security filter cannot corrupt Envoy's memory or affect other filters. This article implements rate limiting and input validation filters in Rust, covers the CVE patterns specific to WASM Envoy filters, and explains the capability model that limits filter blast radius.

The WebAssembly Component Model introduces a new package unit — the .wasm component — with its own registry (warg), composition model, and security surface. This article covers signing WASM components with cosign, attaching SLSA provenance to WASM artifacts, verifying component identity at runtime, and hardening warg registry deployments against dependency confusion and typosquatting.

WASM modules deployed at the edge (Fermyon Spin, Fastly Compute, Cloudflare Workers) need secret access without bundling credentials into the WASM binary. WASI keyvalue provides a standardised secret access interface that the runtime implements — the WASM module never holds the raw secret, only requests it via capability. This article implements secret access patterns for each major WASM edge platform and explains why WASM's capability model prevents accidental secret leakage.

Deploying authorization logic as WASM filters in Envoy and at CDN edge (Cloudflare Workers, Fastly Compute) moves enforcement to the request path without a round-trip to a central PDP. This article covers implementing JWT validation, SPIFFE SVID verification, and OPA policy evaluation as Envoy WASM filters; edge-native OIDC token inspection; and the security tradeoffs of distributed vs centralized enforcement.

A Wasmtime JIT bug that escapes the WASM sandbox doesn't give the attacker root on the cluster — it gives them code execution within the Wasmtime process, which runs inside a Kubernetes pod with a service account token, mounted secrets, and network access. The post-escape pivot paths are identical to any other compromised pod: service account token abuse, lateral movement via network, and secrets harvesting. WASM-in-Kubernetes needs all standard pod hardening.

WebAssembly's memory.copy, memory.fill, and bulk memory operations are bounds-checked by the runtime, but host-to-WASM buffer exchange, shared memory with threads, and guest-controlled copy lengths can still produce out-of-bounds access, Spectre-style cross-module leakage, and host memory corruption if the host-side copy API is not carefully implemented. This article covers the WASM memory model, bulk memory instruction safety, shared memory threading risks, and safe host-guest buffer transfer patterns.

As WASM adoption grows, so does the need for secure WASM module distribution — with the same supply chain controls applied to container images: signing, attestation, vulnerability scanning, and access control. This article covers the warg (WebAssembly Registry) protocol security model, using OCI registries to distribute WASM modules, scanning WASM binaries with cargo-vet and custom tooling, and enforcing signed WASM before execution in Wasmtime and Spin.

Platform engineering tools increasingly use WASM as an extension mechanism — Backstage plugins, kubectl plugins, Helm plugins, and CI/CD systems can all run WASM. The WASM sandbox provides isolation, but the host API surface, WASI capabilities granted, and plugin supply chain remain attack vectors. This article covers the WASM extension security model, capability restriction using WASI component interfaces, plugin signing, and sandboxing third-party platform plugins.

WASM applications making HTTPS calls are protected by the TLS of the underlying runtime — which may or may not support post-quantum key exchange. Applications that implement their own TLS (via rustls, ring, or WebCrypto) control their own PQC readiness. This article implements ML-KEM (FIPS 203) + X25519 hybrid key exchange in WASM using the ml-kem crate, explains the WebCrypto API limitations for PQC, and covers the Fermyon Spin and Cloudflare Workers network client patterns.

WASM serverless functions running on Cloudflare Workers, Fastly Compute, and Fermyon Spin need access to cloud resources — but storing static credentials in WASM binaries or environment variables is dangerous. This article covers OIDC-based cloud access from WASM serverless environments, service binding patterns, Cloudflare Workers Service Bindings for R2/KV/D1, and the security model for WASM functions accessing cloud IAM.

The WebAssembly specification is formally defined, but the specification is not the security boundary — the runtime implementation is. Wasmtime has formal verification efforts, a Bytecode Alliance security disclosure process, and a CVE history that shows what correct runtime security looks like. An AI-generated WASM interpreter built in a weekend has none of these properties. For WASM, security is implementation correctness all the way down.

WASI Preview 2 replaces POSIX-style ambient filesystem and network access with explicit capability grants per component. A WASM component that isn't granted a filesystem capability cannot access files — not because the OS denies it, but because the syscall doesn't exist in its interface. This article analyzes what WASI P2 actually prevents, what it doesn't, and where kernel-level controls remain essential.

Cloudflare Turnstile, DataDome, Akamai BotManager, and PerimeterX ship obfuscated WebAssembly modules to browsers as bot detection challenges. The WASM module collects browser fingerprints, runs integrity checks, and generates a token. Reverse engineers have fully documented how to extract and replay these tokens. The real protection isn't the WASM obfuscation — it's the server-side token validation and the signals the WASM module can only collect from a real browser environment.

WebCrypto doesn't support ML-KEM — but WASM compiled from liboqs fills the gap for browser applications needing post-quantum key exchange today. This guide implements hybrid X25519+ML-KEM-768 key encapsulation in a browser application using WASM, integrates with WebCrypto for AES-GCM encryption, and covers key material handling to prevent leakage from WASM linear memory.

WebAssembly runtimes promise isolation without sharing a kernel — each module runs in a sandboxed linear memory region enforced by the runtime, not the OS. CVE-2023-26114 (Wasmtime heap escape) showed what happens when the runtime itself has a bug. And when WASM runs inside a container, it inherits all the shared-kernel risks it was supposed to avoid.

Transformers.js, MLC-LLM (WASM backend), and ONNX Runtime Web deploy model weights to the browser or edge device where they are accessible to the runtime environment. Model extraction attacks — query-based extraction, weight file download, and WASM memory dump — can steal the full model with commercial value in the billions. WASM's linear memory model makes this easier than stealing server-side model weights.

A vulnerability in a WASM runtime directly undermines the sandbox guarantees your application relies on. Wasmtime sandbox escapes, V8 JIT compiler vulnerabilities, and WasmEdge memory safety bugs have all appeared as CVEs. This guide covers how each WASM runtime handles security disclosures, how to track runtime CVEs, and the emergency response process when a critical sandbox-escape vulnerability is published.

Running MCP tool implementations as WebAssembly modules via Extism or Fermyon Spin isolates each tool in its own sandbox with explicit capability grants. A compromised or buggy tool implementation cannot read the host filesystem, call unintended APIs, or affect other tools — it can only use the capabilities its WASM module was explicitly granted. This trades some performance for a dramatically reduced blast radius per tool.

WASM security scanning requires a two-layer approach: static analysis of the source language (Rust Clippy security lints, cargo-audit, semgrep) catches vulnerabilities before compilation, and binary-level analysis of the compiled WASM module (wasm-objdump, wasm-decompile, twiggy) verifies the output has expected properties. This guide builds a complete WASM security scanning pipeline for Rust and C compiled to WASM.

Spectre-class transient-execution attacks remain reachable from Wasm guests on shared hosts. Wasmtime, V8 Liftoff, and SpiderMonkey have all shipped concrete mitigations — masked indexed loads, fuel-based timing limits, separated heaps. This is what they actually do, when they help, and how to configure them in production.

Security model and hardening for Wasmtime's Pulley portable interpreter on platforms without Cranelift JIT: bytecode validation, resource limits, attack surface vs JIT.

Running WebAssembly at the CDN edge compresses your threat surface — no OS, no persistent disk, ephemeral instances — but the security model has sharp edges: Durable Object state leakage, secret management mistakes, supply chain exposure in npm dependencies, and observability gaps that blind you to edge-side attacks.

SaaS platforms, plugin systems, and data pipelines that let users upload WASM modules need more than the default sandbox. This guide covers pre-execution validation, strict import allowlisting, per-tenant resource isolation, output validation, and multi-layer defence for user-provided WASM execution.

WASI Preview 2 stabilised the Component Model and capability-based I/O. WASIp3 introduces async/await with capability-safe concurrency. This guide covers the security implications of each WASI generation, upcoming proposals (wasi-crypto, wasi-nn, wasi-keyvalue), and how WASI's capability model evolves toward zero-ambient-authority WASM systems.

Gateway WASM plugins process all traffic flowing through the gateway — request headers, auth tokens, and bodies. This guide covers supply chain security for gateway plugins, capability restrictions, sandboxed execution with resource limits, per-tenant plugin isolation, and audit logging for plugin-based security decisions.

Security engineers use wasm-decompile, Ghidra, and Binary Ninja to audit WASM modules for hardcoded credentials, unsafe imports, and vulnerable patterns. This guide covers WASM analysis tooling for defenders, supply chain binary diffing, and realistic IP-protection options for proprietary WASM code.

Traditional POSIX I/O grants processes ambient authority over any path they have filesystem permission to access. cap-std eliminates that by replacing ambient functions with capability objects — every file operation is relative to a pre-opened Dir handle, making path traversal structurally impossible and WASM plugin sandboxing composable without root.

Running financial calculations in JavaScript exposes them to prototype pollution, DOM-based XSS exfiltration, and supply chain attacks via npm. WASM provides a memory-isolated execution environment for interest rate models, risk calculations, and KYC scoring that JavaScript's shared heap cannot. This guide covers implementing financial calculation sandboxes in WASM, preventing data exfiltration, and integrating with banking applications.

The WASM Component Model enables building applications from composed components — but capability flow between components, confused deputy attacks, and supply chain risks in composed graphs require explicit security design. This guide covers WIT interface auditing, transitive capability control, and secure composition with wasm-compose.

WASM doesn't guarantee constant-time execution — JIT optimisations can introduce timing variations that break cryptographic security. This guide covers evaluating WASM crypto libraries for timing safety, using WASI Crypto for hardware-accelerated operations, key zeroisation in linear memory, and RNG security.

Untrusted WASM modules can block a host thread forever with a single infinite loop. Fuel metering and epoch interruption give you hard, auditable CPU budgets — per call, per tenant, and per billing cycle.

Coverage-guided fuzzing finds both runtime vulnerabilities in Wasmtime/V8 and application bugs in WASM modules. This guide covers wasm-smith for structured WASM generation, cargo-fuzz for Rust WASM modules, differential fuzzing across runtimes, and building a continuous fuzzing pipeline.

Host functions are the attack surface between the WASM sandbox and the host system. A poorly designed host API gives untrusted WASM code a path to host-level capabilities. This guide covers minimal host API design, input validation in host functions, preventing TOCTOU across the boundary, and auditing host function exposure.

Shipping WASM modules instead of full firmware images reduces OTA update risk — the WASM sandbox contains execution, memory-safe Rust prevents memory corruption bugs, and modules can be signed and verified before loading. This guide covers secure OTA distribution, runtime verification, rollback mechanisms, and resource constraints for WASM on embedded targets.

AI tools discover C/C++ memory corruption bugs at scale — the classes of vulnerabilities that dominate container escape CVEs. WASM's memory safety model eliminates these classes by design. Understand where WASM isolation is strictly stronger than containers, where it is weaker, and how to combine both.

Understand how JIT spraying and speculative execution attacks target WASM runtimes, and harden Wasmtime, V8, and SpiderMonkey against Spectre, JIT code injection, and side-channel leakage.

WASM sidecars in Kubernetes offer smaller attack surface than language-runtime sidecars — no shell, no package manager, no OS CVEs beyond the runtime itself. This guide covers WASM-based admission webhooks, policy sidecars, traffic inspection with wasm-filter, and security properties compared to traditional sidecar proxies.

Wasmtime's AOT precompilation and module caching dramatically reduce cold-start latency — but cached native code is a high-value attack target. This guide covers securing the Wasmtime cache directory, binding cached artefacts to source module hashes, detecting cache poisoning, and safe precompilation pipelines.

Loading an untrusted .wasm binary without explicit validation gates hands an attacker a structured sandbox escape surface. This article covers pre-load integrity checks, Wasmtime's multi-layer validator, import allowlisting, export surface auditing, and supply-chain verification before instantiation.

OCI-based WASM signing works for container registries, but many WASM use cases distribute modules via HTTP, npm, or direct file transfer. This guide covers COSE (CBOR Object Signing) for WASM, signing WASM modules published to npm, Sigstore bundle format for non-OCI distribution, and verifying signatures in Wasmtime before instantiation.

WASM enables safe, user-space packet processing for network security applications — without eBPF's kernel privilege requirements. This guide covers WASM-based packet filters with libpcap, network security functions in WasmEdge, comparing WASM vs eBPF for security use cases, and safe packet dissection in WASM.

OPA's WASM compilation target enables portable policy evaluation, but WASM also enables entirely custom policy engines in any language. This guide covers OPA Rego-to-WASM, Cedar policy engine in WASM, Styra DAS, and building custom authorisation logic as a WASM module for embedding in applications and gateways.

WASM deployments using RSA or ECDH key exchange are vulnerable to harvest-now-decrypt-later attacks. This guide covers compiling NIST-standardised PQC algorithms (ML-KEM, ML-DSA) to WASM, WASI Crypto's PQC roadmap, performance implications of PQC in constrained WASM environments, and migration strategies for WASM-based TLS and signing.

WebAssembly 2.0 reference types let WASM code hold opaque handles to host objects. Insecure host bindings risk type confusion, use-after-free, and capability escalation across security boundaries. Build safe externref bindings with lifetime tracking, type tagging, and capability scoping.

WASM's deterministic execution, memory safety, and sandboxing make it attractive for regulated environments — but FDA, ISO 26262, and IEC 62443 impose requirements around verification, validation, and safety certification. This guide covers WASM in safety-critical systems, formal verification approaches, and regulatory compliance considerations.

Remote parties can't trust a WASM execution result unless they can verify the runtime is unmodified and running the expected module. This guide covers runtime attestation using TPM measurements, TEE integration with confidential containers, module hash verification, and building attestable WASM execution services.

eBPF and Falco are blind inside WASM sandboxes — security visibility requires WASM-level instrumentation. This guide covers Wasmtime linker-based host function wrapping, component-model monitoring components, OpenTelemetry from WASM, and detecting anomalous execution patterns through instrumented runtimes.

A WASM module compiled from Rust carries dozens of crate dependencies — none visible from the binary alone. This guide covers SBOM generation for WASM modules with syft and cargo-sbom, attaching provenance attestations as OCI referrers, verifying module lineage before deployment, and WASM-specific supply chain policy enforcement.

The WASM sandbox prevents direct syscalls — but the runtime process still needs OS access, and a sandbox escape leads to unrestricted syscall access. Applying a seccomp profile to the WASM runtime process limits the blast radius of runtime vulnerabilities, complementing the WASM sandbox with a kernel-level enforcement layer.

A complete WASM security testing programme combines static analysis of WASM bytecode, dynamic testing with resource monitoring, differential testing across runtimes, host boundary fuzzing, and supply chain verification. This guide provides a structured methodology and toolchain for security engineers deploying WASM in production.

WASM components communicate only through typed WIT interfaces — there is no shared memory between components. This architectural property eliminates entire classes of lateral movement and memory disclosure attacks. This guide explains how to design secure shared-nothing WASM systems with wasmCloud and the Component Model.

WASM SIMD128 exposes subtle timing side channels that break constant-time guarantees in cryptographic code. Learn when SIMD is safe, when it leaks secrets, and how to harden SIMD-accelerated WASM workloads against speculative execution and memory disclosure attacks.

WASM smart contracts in CosmWasm and NEAR inherit WASM sandboxing but introduce blockchain-specific risks: integer overflow in token math, reentrancy via cross-contract calls, and unsafe upgrade patterns. This guide covers audit methodology, secure coding patterns, and testing for Rust-based WASM contracts.

WebKit's BBQ/OMG JIT tiers, conservative Spectre mitigations, iOS JIT restrictions, WKWebView bridge security, and mobile-specific WASM threats require a hardening strategy distinct from desktop V8 deployments.

The Axios attack needed fast, portable scanning tools deployable anywhere. WASM-compiled security scanners run on any platform without installation, with WASI capability sandboxing, and verifiable reproducible builds — the ideal CI supply chain tool format.

CVE-2026-34971 allows WASM guest code to read/write arbitrary host memory on aarch64 via a Cranelift code generation bug. Affects AWS Graviton, Apple M-series, and ARM edge devices. Patch to Wasmtime 43.0.1+, audit aarch64 deployments, and harden against compiler-level sandbox escapes.

CVE-2026-34941 leaks one byte of host memory per string transcoding call in Wasmtime's component model. Affects all architectures. Repeated calls enable multi-byte information disclosure from host memory adjacent to WASM linear memory.

Harden the cargo-component WASM component build pipeline against proc-macro execution, build.rs supply chain attacks, and the Bytecode Alliance's inconsistent CVE process for tooling.

The Axios RAT had unrestricted network and filesystem access via a postinstall hook. A WASM/WASI sandbox grants postinstall scripts only what they need — a build directory and no network — so a compromised package cannot reach C2 or exfiltrate credentials.

CISA's OT Zero Trust guidance requires application-layer capability enforcement. WASM + WASI provides a sandboxing model for OT edge plugins where each vendor module gets only the network socket or filesystem access it needs — no more.

CISA recommends protocol-aware OT monitoring. Compiling Modbus, DNP3, and EtherNet/IP parsers to WASM provides memory-isolated, fuzz-tested parsing — a corrupt protocol frame cannot escape the sandbox to compromise the monitoring tool.

Harden Wasmer-based WASM deployments by understanding its JIT compiler attack surface, the absence of a formal CVE process, and tracking silent fixes across Cranelift, LLVM, and Singlepass backends.

CVE-2026-27195 crashes the Wasmtime host process when a guest component's async call future is dropped before completion. Learn how to harden async component deployments with timeouts, isolation, and upgrade controls.

Understand the security model of jco-transpiled WASM components running in Node.js and Deno, including capability leakage risks, host function exposure, and jco's lack of a formal CVE process.

Secure WebAssembly ahead-of-time compilation pipelines by hardening the compiler toolchain, signing AOT artifacts, validating inputs, and isolating the compilation environment.

Analyze security implications of the WebAssembly exception handling v2 proposal—cross-trust-boundary exception propagation, try_table instruction risks, and tracking silent fixes in Wasmtime and V8.

Analyze security implications of the WebAssembly memory64 proposal—64-bit linear memory, integer overflow risks, pointer arithmetic, and tracking silent security fixes in Wasmtime and V8.

Analyze security implications of the WebAssembly tail calls proposal—stack frame elimination breaking depth limits and call-stack audit tools—with tracking of silent implementation fixes in Wasmtime and V8.

Harden Wasmtime deployments against CVE-2026-27572 wasi:http header DoS and CVE-2026-27204 resource exhaustion—configuring guest resource limits to prevent host process termination.

Extism provides a universal plugin system built on WebAssembly. The host/guest security model limits what plugins can access, but misconfigured host functions, overpermissive memory sharing, and unverified plugin binaries break the sandbox. Securing Extism means controlling what the host exposes, not just what WASM provides.

OPA compiles Rego policies to WebAssembly for embedding in applications, edge functions, and API gateways without a sidecar. The compiled bundle evaluates policies in a WASM sandbox, but the sandbox's security depends on correct bundle signing, input validation, and cache isolation.

WebAssembly's component model enables dynamic module composition — linking multiple WASM modules at runtime into a single application. This creates trust boundary questions: when modules import functions from each other, which module's security context applies, and how do you prevent a low-trust module from abusing a high-trust module's exports?

WebAssembly's linear memory model provides strong isolation between the WASM heap and the host, but it does not prevent within-sandbox buffer overflows, use-after-free, or stack smashing. Understanding what WASM's memory model protects and what it doesn't determines where additional defences are needed.

WASM binaries are produced by compiler toolchains — Emscripten, wasi-sdk, wasm-pack, cargo/rustc. Insecure compiler flags introduce vulnerabilities (stack overflow, missing bounds checks); unsigned build artefacts enable supply chain substitution; and toolchain dependency vulnerabilities propagate into every binary the toolchain produces.

Analyze WasmGC's new attack surface in multi-tenant WASM runtimes: GC object escape, type confusion in struct hierarchies, finalizer abuse, and cross-tenant reference leaks.

Browser-hosted WASM has a distinct attack surface from server-side WASM. CSP directives, cross-origin isolation for SharedArrayBuffer, and SRI hashes prevent XSS-based WASM injection and module substitution.

Production WASM modules often ship with name sections, debug symbols, and source maps that expose function names, variable names, and original source structure. Stripping them protects proprietary logic.

wasmCloud's actor model isolates components behind capability contracts. Security rests on NKEY-based actor identity, lattice authentication via NATS, and OCI-signed actor distribution.

WasmEdge runs AI inference workloads, plugins, and serverless functions inside a WASM sandbox. Securing the runtime requires capability-based access control, plugin isolation, socket permission limits, and supply chain verification of the modules being executed.

Fermyon Spin 2.x runs WASM components as serverless-style handlers. Each component's network, filesystem, and secret access requires explicit capability grants. Defaults are strict; misconfiguration opens broad access.

Security-side WASM (auth filters, policy engines, MCP plugins) must be sub-millisecond to deploy at request rate. Pre-compilation and snapshotting get you there.

WASM lets you ship logic to constrained devices without firmware updates. The runtime, the trust model, and the OTA pipeline all need careful design.

Plugin systems built on WASM have a recurring shape. Threat-modeling that shape catches the structural mistakes before deployment.

WASM threading via SharedArrayBuffer re-opens Spectre-class timing attacks. Cross-origin isolation, per-tenant memory isolation, and atomics hygiene are required before enabling threads.

Edge runtimes execute untrusted customer code in shared processes. The hardening contract is the platform's, but the customer code's behavior decides the blast radius.

WASM plugins run inline in the data path. A misconfigured plugin can exhaust memory, leak tenant data, or crash the proxy. The defaults need explicit caps.

ngx_wasm_module brings the proxy-wasm protocol to NGINX. Plugin authoring is similar to Envoy, but the worker model and hardening surface differ.

WASM is the easy case for reproducibility — no dynamic linking, no runtime variance. Most teams still ship non-reproducible builds. The fix is small.

WASI HTTP servers are a clean platform-neutral pattern. The hardening is at the application layer — body limits, header allowlists, response shaping, and panic semantics.

Preview 2 replaces Preview 1's coarse imports with explicit, scoped, capability-passing interfaces. The security story is the actual reason to migrate.

wasi:sockets/tcp and wasi:sockets/udp give WASM modules network access. The capability model is fine-grained — most embedders use it as a coarse on/off switch.

Running AI inference inside WASM is a new deployment pattern with novel isolation properties. The threat model differs from GPU-served inference.

When you compose multiple components, every wire is a capability decision. The security story of a composed application lives in the WIT between components.

Databases are growing WASM extension points. The threat model spans both WASM-runtime escape and database-internal lateral access — different from container UDFs.

Running many tenants' WASM modules in one runtime is the hard case. Per-tenant fairness, isolation guarantees, and the failure modes that violate both.

WASM modules ride OCI registries the same as containers. The supply-chain hygiene story is the same — and most orgs do not apply it to .wasm artifacts.

WASM on Kubernetes via runwasi and containerd shims runs alongside containers but with a different escape surface, different RBAC implications, and different supply-chain controls.

Scanning .wasm artifacts is different from scanning containers — no rootfs, no package manager. The dependency graph is in the bytecode.

Wasmtime's defaults are friendly, not safe. Untrusted modules need explicit limits on CPU, memory, syscall surface, and filesystem access.

Wazero is the pure-Go WASM runtime used by Tetragon, Cilium, k6, Trivy, and dapr. The defaults are friendly; production deployments need explicit caps.