Meta Rushed to Fix 'VM Escape' Vulnerabilities Before Muse's Launch, 404 Media Reports
Internal posts seen by 404 Media describe a weeks-long scramble over KVM escape flaws that could have let a Muse user reach Meta's own databases, a scramble that reached Mark Zuckerberg.
By Icarus4 min read
In the weeks before Muse’s September 8 launch, Meta engineers found security flaws that could have let a Muse user break out of their isolated virtual machine and reach Meta’s own sensitive databases, according to internal posts reviewed by 404 Media. The issues were serious enough to reach Mark Zuckerberg, and security teams worked nights and weekends to patch them before launch.
The short version
- At least one pre-launch vulnerability could have let a Muse user escape their per-user virtual machine and access Meta’s internal databases and services.
- An internal post by Meta executives describes a “sudden spike in reported KVM escapes” and a multi-team hardening push that began August 27.
- An anonymous Meta source says teams were pushed to ship hotfixes without delaying the launch, producing what they called “half-baked protections.”
- Meta’s own bug bounty treats a Muse VM escape as the highest-severity risk, worth up to $300,000.
The internal scramble
The reporting, published October 5 by 404 Media’s Jason Koebler, rests on internal posts and security documentation at Meta, plus an anonymous Meta source. The centerpiece is an internal post dated September 18, ten days after Muse launched, from three executives: Surupa Biswas, Meta’s vice president of core infrastructure; Francois Richard, vice president of engineering; and Josh Barry, senior director of engineering, addressed to the company’s core infrastructure team.
The post described a “sudden spike in reported KVM escapes” and a multi-team “service hardening push” that began August 27 and lasted a “handful of weeks and weekends.” The work, in the executives’ words, focused on reducing “the surface area accessible to Hatch agents” (Hatch is Muse’s internal codename, used throughout Meta’s codebase) and constraining which network destinations those agents and their hosts could reach.
Why a VM escape is Meta’s worst-case scenario
Each Muse instance runs on a dedicated per-user virtual machine, using Linux’s kernel-based virtual machine (KVM) technology. That VM is supposed to be isolated from Meta’s own critical infrastructure. A “KVM escape” means code running inside a user’s VM breaks through that boundary and can interact with the host system, other users’ VMs, or — in Meta’s setup — production services.
Meta treats that possibility as the most serious security risk the product carries. Its bug bounty program offers up to $300,000 to any researcher who finds a bug enabling a VM escape, the highest payout the company lists. The top risk category is “Compromise of Meta production and users beyond Muse,” defined as “reaching Meta production services or internal networks from Muse,” which is exactly what at least one of the pre-launch vulnerabilities could have allowed, according to 404 Media’s source.
Security researcher Patrick Wardle, who found a macOS zero-day in Muse, told 404 Media the design itself is the problem: “This issue is that Hatch makes the virtualization boundary a production security boundary… one KVM escape away, is plain irresponsible.” His point is that Muse users effectively have root privileges inside a VM that sits within Meta’s production environment with limited access to internal services — so a single failure in KVM, or a misconfiguration in an internally reachable service, could turn arbitrary user code into production access.
Launch-day pressure
According to the anonymous source, the vulnerabilities were severe enough that they were raised to Zuckerberg, and several security teams worked nights and weekends in the lead-up to launch. At least one flaw was tied to a Linux KVM exploit identified in July; several others were in the underlying virtualization software Meta uses for Muse.
The same source told 404 Media that security teams felt pressure to push hotfixes as fast as possible without delaying Muse’s launch. They described the result as “half-baked protections being rushed out to enable the launch,” adding: “Many senior engineers believe it’s inevitable we’re going to have a massive data breach as a result of Hatch.”
Meta’s response and the post-launch record
A Meta spokesperson told 404 Media: “Muse is the first personal AI agent built for everyone and we’re proud of the work we’ve done to make it safe, secure and private, with built-in protections and user controls that put people in charge of how they use it. We’ve strengthened Muse through extensive dogfooding, agentic red teaming and our bug bounty program — and that work continues.”
404 Media notes that a pre-launch security push of this kind is not unusual for a major product. The backdrop here is different: outside researchers have found a string of security problems since Muse’s launch. Wardle’s macOS zero-day let any local process redirect Muse’s voice transcription and capture its authentication token; Meta shipped a hotfix within hours. And 404 Media reports that another Muse user was able to get the agent to export his Instagram followers, as well as his followers’ followers, which should not have been possible. Meta’s security teams investigated, according to the source.
The pre-launch record, as reported, is this: Meta discovered, before Muse ever reached users, that the isolation boundary it treats as its highest-severity risk could be crossed, and shipped anyway on schedule. The hardening push reduced the exposed surface, Meta says, and the work continues, but so does the stream of independent findings from researchers poking at the same boundary.
