Last month the Bytecode Alliance published security advisories for Wasmtime: the largest set of advisories the project has ever published at once, triple the total number issued in all of 2025. The accompanying patch releases (Wasmtime versions 43.0.1, 42.0.2, 36.0.7, and 24.0.7) address 12 vulnerabilities surfaced with the help of a frontier AI model.
Wasmtime is one of the most rigorously engineered runtimes in open source: written in Rust, continuously fuzz-tested, backed by multiple organizations who treat it as security-critical infrastructure. What this release demonstrates is that surfacing vulnerabilities in even the most hardened codebases is no longer the hard part. Finding them quickly and at scale is now within reach of any well-resourced team with access to a capable model.
The hard part is what happens next. Teams have to review each finding, triage severity and blast radius, and patch across active versions, while coordinating disclosure with production embedders before vulnerabilities become public. That work still requires deep expertise, sustained investment, and the kind of trust that only comes from years of doing it right. It shouldn't come as a surprise that, according to a technical blog from Anthropic Red Team, over 99% of vulnerabilities uncovered through similar research have not yet been patched.
At Cosmonic, we're privileged to be part of the Bytecode Alliance, and proud to be part of a community with the commitment to swift releases and advisories like the ones we saw in April.
What happened
Over a three-week sprint, a multi-agent harness built around a frontier AI model—deployed by researchers from Mozilla, UCSD, Akamai, and F5—systematically analyzed security-sensitive code in Wasmtime’s Cranelift and Winch compiler backends and its unsafe Rust runtime. The effort surfaced 11 of the 12 advisories in this release. Patched builds are available as Wasmtime 43.0.1, 42.0.2, 36.0.7, and 24.0.7.
The technique at the center of this release is worth understanding on its own terms. Researchers used the model to hunt for security vulnerabilities by asserting that a bug existed within a specific file and directing it to find one. Given that minimal context, the model was able to identify the vulnerability. From there, the same technique was applied iteratively, with the model continuing to surface issues in related areas of the codebase.
Unlike fuzzing, which generates randomized inputs to probe for crashes and unexpected behavior, this technique works through semantic analysis of code logic at a depth and speed that previously required deep human expertise and extensive time. Once a researcher finds the first crack, the model can mine the same seam until it runs dry.
The result: 12 advisories (two critical, six moderate, four low) covering Wasmtime’s compiler backends and runtime unsafe code.
The new security frontier
Mozilla published a detailed account of a parallel effort: Anthropic's Red Team applied similar AI-assisted analysis to Firefox's JavaScript engine. They found 22 high-severity CVEs and 90 additional bugs, all included in Firefox 148. Mozilla's conclusion is worth quoting directly:
"The findings overlapped with issues traditionally found through fuzzing, but also identified distinct classes of logic errors that fuzzers had not previously uncovered."
Firefox is one of the most extensively fuzz-tested, audited codebases on the planet. Both Firefox and Wasmtime, along with countless other projects named and unnamed, were found to contain real, exploitable issues that decades of conventional practice had missed. It is clear that AI-assisted analysis can now surface distinct classes of logic errors that conventional methods consistently miss, even in longstanding and well-scrutinized codebases.
Anthropic's own frontier AI security research surfaced vulnerabilities across OpenBSD, FreeBSD, FFmpeg, and the Linux kernel, including a 27-year-old TCP implementation bug and a 17-year-old remote code execution flaw that decades of fuzzing had missed entirely. The Linux kernel alone is now seeing 5-10 CVE reports per day, up from 2-3 per week two years ago—an acceleration that security teams across the ecosystem are only beginning to process.
The most directly relevant finding for this community may be that the model identified a guest-to-host memory corruption vulnerability in a production VMM written in Rust. Even memory-safe implementations of security-critical isolation boundaries are now within reach of this analysis.
Proactive security culture
The scale of this disclosure might look alarming on the surface. Twelve security advisories in a single release from a project known for its security posture? What's going on?
The answer is that finding bugs and handling them responsibly are two different capabilities, and the Wasmtime project has spent years building both.
Wasmtime is written in Rust, which eliminates entire classes of memory safety vulnerabilities before a line of business logic is written. But the project has never relied on Rust alone. Wasmtime maintains one of the most comprehensive fuzzing architectures in open source: continuous 24/7 fuzzing through Google's OSS-Fuzz program, coverage-guided fuzz targets across the compiler and runtime, pseudo-random valid WebAssembly module generation via wasm-smith, and differential testing against reference implementations. The VeriWasm project (a collaboration between UCSD, Stanford, and Fastly) provides formal translation validation that compiled programs cannot escape the sandbox.
This infrastructure exists because the Bytecode Alliance has always treated Wasmtime as security-critical software. Writing it carefully is necessary, but Wasmtime must also be interrogated continuously.
The frontier AI model found things the fuzzers didn't, and found them quickly. That may be startling or uncomfortable at first, but proactive security culture always assumes that more bugs exist, and evaluates better tools to find them. As capabilities like these become more widely available, we can be certain that many more vulnerabilities will be discovered across countless projects, many of which may not have Wasmtime's testing infrastructure, Rust's memory safety guarantees, or the Bytecode Alliance's multi-organization security bench.
The question will become whether the people responsible for code are in a position to do something about it when vulnerabilities are surfaced. Projects that treat bug reports as nuisances, that have deferred security reviews, that rely on obscurity—they are about to have a very difficult time. The barrier to finding significant vulnerabilities in production software is about to fall, and it is not going back up. The case for preparation has never been clearer.
Cosmonic and the sandbox boundary
At Cosmonic, we've spent years making the case that the WebAssembly sandbox is a foundational security primitive: a critical boundary that code cannot escape without explicit capability grants. That boundary matters more every day.
When a vulnerability exists in a component running on wasmCloud and Cosmonic Control, the blast radius is structurally constrained. The component cannot access the filesystem, the network, or other components except through explicitly declared, policy-enforced interfaces. A zero-day in application logic is serious; a zero-day that can pivot to the host or to adjacent services is catastrophic. The sandbox changes that calculus.
This is the argument we've made in depth in our white paper, 8 Principles of Secure Platform Engineering with WebAssembly. The principles—secure by design, minimal footprint, shift left, continuous verification—were written before LLM-assisted vulnerability discovery emerged as the powerful tool that it is today. Those principles are even more critical now.
That same guarantee applies to the AI workloads teams are deploying today. Cosmonic Control sandboxes MCP servers as WebAssembly components, so even AI agents running third-party tools operate within explicit capability boundaries, and cannot pivot beyond what they were granted, regardless of what instructions the agent receives.
Looking ahead
The researchers who ran this analysis, the engineers at the Bytecode Alliance who reviewed and fixed each issue, and the production embedders who deployed patches before public disclosure all deserve thanks for this swift and massive response.
If you're thinking about what your organization's security posture looks like in a world where AI-assisted vulnerability research is a routine capability, start with the white paper, or reach out directly.
Further reading
- Wasmtime Security Advisories, April 2026 — Bytecode Alliance
- Hardening Firefox with Anthropic's Red Team — Mozilla Blog
- AI-Assisted Vulnerability Discovery — Anthropic Red Team
- The surge in Linux kernel CVEs — LWN.net
- Security and Correctness in Wasmtime — Nick Fitzgerald
- 8 Principles of Secure Platform Engineering — Cosmonic
- Sandboxing AIOps and Agentic AI Security - Cosmonic