All posts
Unproven Execution

Manus Agent: Decode Step Reaches Code Before Approval

Salt Labs showed how one JSFuck-encoded email makes the Manus agent decode and run attacker code in Node.js before its injection warning fires

Securityv0 Intelligence Team OWASP: ASI05 sv0 finding: unproven_execution
manus salt-labs prompt-injection unproven-execution mcp oauth

The Incident

On October 1, 2026, Salt Labs disclosed that a single email could hijack Manus — the agentic AI platform originally built by Butterfly Effect, briefly held by Meta, and now operating independently after China’s NDRC ordered the acquisition unwound on April 27, 2026 and Meta began splitting operations and data in June 2026. The research team connected a test Gmail account to Manus via the platform’s Gmail integration and asked Manus to read the latest message. A plain-text injection in the email tripped Manus’s guardrail: the agent surfaced a warning that the message contained malicious instructions and asked the user to approve further action. Salt then re-sent the same payload encoded in JSFuck — a JavaScript obfuscation that writes any program using only a handful of punctuation characters — along with a line of text asking the reader to decode it. Manus launched Node.js to perform the decode, and the decoded program executed as a side effect of the decode step. Only after the code ran did the injection warning appear. The researchers escalated to a reverse shell inside the agent’s per-task cloud sandbox, which held the Gmail OAuth token the user had granted; Salt notes that credentials for Google Drive and GitHub would also be reachable where a user had connected them, though those were not demonstrated.

The demonstration used a researcher-owned test account, and no third-party victim or in-the-wild exploitation has been reported. Salt says it first reported the finding to Manus, received no reply, and then filed through Meta’s bug-bounty programme; Salt reports that Meta triaged, confirmed, and patched the issue, and that its own later reproduction attempts no longer succeeded. Neither Manus nor Meta has published an advisory. Separately, Manus 2.0 launched on September 28, 2026 — three days before Salt’s public disclosure — adding automations that start an agent run from a new email, Slack message, calendar event, or Notion update. That trigger surface removes the user’s “please check my inbox” step from the authority path the Salt attack walked.

MITRE ATT&CK coverage:

  • T1566 — Phishing (delivery into agent context)
  • T1027 — Obfuscated Files or Information
  • T1059.007 — Command and Scripting Interpreter: JavaScript
  • T1528 — Steal Application Access Token

The Authority Path That Failed

The identity carrying execution authority was the Manus agent’s per-task cloud sandbox. Its held scope was a Node.js interpreter, a shell, outbound network access, and the Gmail OAuth token (and whichever other OAuth grants the user had connected). The scope the user authorized was narrow — read and summarize the latest email — but the scope the sandbox held was the full set of capabilities Manus provisions for every task. The injection guardrail inspected message content as text and prompted for approval when it saw an instruction. The decoder path never passed that gate: Manus treated “decode this string with Node” as part of its own tool use rather than as content requiring authorization, and the obfuscated payload executed before any approval dialog surfaced. The warning that eventually arrived was an audit record, not a control.

The first trust anchor to fail was the location of the approval check. SecurityV0’s reference pattern — the Langflow CSV Agent + Python REPL — attaches a code-execution tool to an agent’s manifest with no operator sign-off; Manus’s failure is the same shape viewed from a different angle. The code-execution capability, the standing OAuth credentials, and the untrusted inbound channel all shared one sandbox, with no execution-authorization step between them. That gap was discoverable before the attack: an inventory of the agent’s tool manifest, cross-referenced with reachable inbound channels and co-resident machine credentials, would have surfaced a path from “unauthenticated email” to “arbitrary code with a live OAuth token” without needing to see the JSFuck payload at all. Manus 2.0’s event-triggered automations compress the same path further by removing the user’s manual read from the chain.

SecurityV0 Perspective

For a Manus deployment running the Gmail integration against a sandbox that attaches Node.js, SecurityV0 would raise unproven_execution against the agent runtime. The finding attaches because the sandbox resolves a code-execution capability without a corresponding operator-authored authorization record for the specific user task, and because the input channel feeding that sandbox (inbound mail) is one the operator never signed off as a code-execution source. The parallel to the Langflow Python REPL reference is direct: a dangerous capability wired into the agent’s default tool surface, with the authorization check placed after the capability runs. The secondary angle is nhi_compromise — the Gmail OAuth token lived inside the same sandbox that could execute arbitrary code from an untrusted channel, so successful execution yielded machine-identity reach whether or not the user ever approved it.

The evidence pack would carry the Manus task configuration (which integrations are attached, which OAuth scopes they consume), the per-task sandbox tool manifest (Node.js presence, shell presence, outbound network reachability), the trigger set (manual chat, inbound email, Slack event, calendar event), and the sequence between first inbound content and first approval dialog. Pre-exfiltration, that pack answers: does any task configuration reach a code-execution capability from an inbound channel before the user has approved it? Post-exfiltration, it answers: for a specific task instance, which inbound message produced which Node.js invocations against which OAuth-bound integration, and whether an approval dialog ever intervened before the code ran.

What To Do

  • Treat the agent’s tool manifest as an authorization artifact, not a default. For every agent, enumerate the capabilities the sandbox resolves at task start (interpreter present, shell present, outbound network, filesystem write). Require an operator-authored record for each code-execution capability, scoped to the task shape it is authorized for; do not accept “it ships with Node by default” as an authorization.
  • Place the approval gate before the capability runs, not before the warning renders. Audit the agent’s control flow for any path where a tool call executes while a separate validator decides whether to warn. If the two run concurrently, the warning is a log; the gate must be synchronous with the capability. For Manus deployments, treat the single-email path as patched by Salt’s bug-bounty report only, and verify your own task traces no longer show Node.js invocations preceding injection warnings.
  • Separate OAuth-token-bearing contexts from code-execution contexts. Where the agent runtime cannot be re-architected, run the OAuth-mediated read (fetch message, extract text) in a sandbox that does not attach an interpreter, and run any required post-processing in a second sandbox that holds no standing credentials. Pass artifacts between them explicitly; do not co-resident them because the vendor’s default sandbox does.
  • Map every inbound channel to the capabilities it can reach. List each trigger an agent accepts (chat, inbound email, Slack, calendar, Notion, webhook) and the tool manifest reachable from each. Treat any trigger that reaches a code-execution capability without a user-authored approval as unproven_execution. The Manus 2.0 shift from manual chat to event-triggered automations widens this surface — new triggers must be audited against the same manifest, not grandfathered.
  • Keep a per-task record of trigger, tool-call, and OAuth-use that answers both the pre- and post-incident question. For every task instance, capture the triggering message’s provenance, the ordered sequence of tool invocations, the OAuth scopes exercised by each, and the position of any approval or warning dialog in that sequence. Retention must outlast your forensic cutover: a trace that stops at the warning does not tell you what the capability did before the warning fired.

Sources

All posts