Can One Email Hijack Manus and Reach Your Gmail?

October 4, 2026

Salt Labs hijacked Manus through one crafted email. Here is what ran, which connected-account tokens were exposed, what was fixed, and what remains unclear.

Research cutoff: October 4, 2026. This article analyzes Salt Labs' controlled test of the Manus AI agent, Salt's disclosure statement, current coverage, and current agent-security guidance. Salt says the specific vulnerability has been fixed and is no longer reproducible.

Yes, one crafted email was enough to hijack Manus in Salt Labs' controlled test—but receiving the email alone did not automatically compromise the account. The message first had to reach a Gmail inbox connected to Manus, and the user then had to ask Manus to retrieve or check that email.

When Manus processed the message, it treated attacker-controlled text as instructions. The researchers hid JavaScript inside an unusual encoding called JSFuck and told the agent to decode it with Node.js. Manus ran the decoded code in its cloud sandbox before its security warning appeared. Salt Labs escalated that code execution to a reverse shell and found the Gmail OAuth token plus credentials for other connected services in the sandbox environment.

That was a serious security-boundary failure. It was not proof that an email could install malware on the user's laptop, that every Manus user was compromised, or that attackers exploited the flaw in the wild. Salt says the vulnerability was reported, confirmed through Meta's bug-bounty process, fixed, and no longer reproduced in later tests.

The lasting lesson is larger than this patched bug: when an AI agent can read untrusted email and also run code or hold powerful account tokens, a model warning is not a reliable last line of defense. Permissions and execution controls must stop the action before it happens.

Key Takeaways

What Happened to Manus?

Salt Labs' technical report describes a test account whose Gmail inbox was connected to Manus. Manus accessed messages through a custom Gmail Model Context Protocol, or MCP, integration running inside the user's cloud sandbox.

The researchers first tested an ordinary email. They then sent messages containing explicit instructions to execute commands. Manus recognized those obvious attempts, stopped processing, displayed a security warning, and asked for user approval.

That initial defense worked. The bypass appeared when the researchers changed how the hidden instruction was represented.

They placed a JavaScript payload in the email using JSFuck, an obfuscation format that can express JavaScript with a tiny set of punctuation characters. The email asked Manus to use Node.js to decode and display the message. According to Salt, Manus extracted the payload and invoked the Node.js runtime. Decoding was therefore also execution.

The researchers progressed through three controlled demonstrations:

  1. The encoded script printed a harmless test value.
  2. A later payload ran a system command in the sandbox.
  3. A final payload opened an outbound reverse shell to infrastructure controlled by the researchers.

After gaining the shell, Salt inspected the sandbox. The researchers say it could reach Manus's Gmail MCP interface and the Gmail OAuth token associated with the test user. They also found credentials for other connected integrations, including Google Drive or GitHub, exposed through environment variables when those services were connected.

That combination matters more than code execution alone. A disposable sandbox limits what hostile code can do to the underlying host. But a sandbox that also holds account tokens can become a bridge to the user's email, files, or repositories.

What Is Confirmed

The attack began with untrusted email content

The payload was delivered in a normal email to the test account. The attacker did not need the test user's password and did not need the user to click a link or download an attachment.

The chain was not entirely passive, however. Salt's disclosure statement says two events were required: the malicious message arrived, and the user asked Manus to check the inbox. That distinction makes “one-email hijack” accurate as a delivery description but not equivalent to “every unopened email instantly compromises Manus.”

Obvious malicious instructions were blocked

Salt's tests show that Manus did have a functioning safety control. Direct requests to execute shell commands triggered a warning and an approval request. Base64 and several other encoding approaches were also blocked.

The failure was not that Manus recognized nothing. The failure was that the control did not cover the later tool-execution path.

The JSFuck payload ran before the warning

Salt reports that Manus used Node.js to decode the obfuscated payload. In JavaScript, evaluating the encoded expression executes it. The agent then warned that it had detected a dangerous payload and needed approval—but the decoding step had already run the code.

This is the most important sequencing fact in the report. Detection after execution is useful for investigation. It is not prevention.

The researchers reached a reverse shell in the cloud sandbox

Salt says the final controlled payload created an outbound connection to the researchers' system, giving them a shell inside the Manus environment. That is remote code execution in a provider-hosted sandbox.

It does not mean the researchers obtained a shell on the user's laptop or phone. The report describes the cloud execution environment Manus used for the task.

Connected-account tokens increased the potential impact

Once inside the sandbox, Salt says the researchers observed access to the Gmail MCP interface and the authenticated user's OAuth token. They also found environment credentials for other services that a user had connected.

The report therefore supports a potential path from a malicious email to connected email, storage, or code-repository data. The severity came from the privileges placed inside the same environment that processed hostile content.

Salt says the specific vulnerability was fixed

Salt says it initially reported the problem to Manus and received no response, then submitted it through Meta's bug-bounty program. According to Salt, Meta triaged and confirmed the issue, it was addressed, and later reproduction attempts failed.

Salt also clarifies that Meta's planned acquisition of Manus did not proceed and the companies remain separate. Manus should not be described as a Meta-owned product on the basis of this disclosure.

What Is Still Unclear

There is no public CVE or affected-version range

The disclosure does not identify a CVE, exact vulnerable build, first affected date, or patch version. A user cannot compare a visible version number with a published fixed-version boundary.

Salt's failed retests are evidence that the demonstrated chain was remediated. They are not the same as a complete independent audit of every Manus email-processing path.

The exact remediation is not public

The report does not say whether Manus removed Node.js from the decoding path, changed how email is labeled and parsed, isolated credentials, restricted network egress, added pre-execution policy checks, or combined several controls.

Those details matter because blocking one encoding is different from changing the architecture that allowed untrusted data to become executable code.

Public evidence does not show real-user exploitation

Salt demonstrates impact in a controlled account. It does not report that criminals used the flaw, that unrelated customers lost data, or that tokens from real victims were accessed.

Potential access and observed exploitation are different claims. The former is well supported by the test. The latter is not established by the public sources reviewed here.

The researchers do not publish a complete token-use demonstration

The report says the sandbox exposed Gmail and other integration tokens and that exploitation could extend to connected accounts. It does not document a full extraction-and-use sequence against real third-party data outside the controlled environment.

That was a sensible boundary for responsible research. It also means readers should not inflate “credentials were reachable” into proof that every connected account was fully copied.

Receiving a message was not the only trigger

The user asked Manus to retrieve the email. Salt does not claim that Gmail delivery by itself caused execution before the agent processed the message.

This makes the attack more serious than ordinary phishing because no link click or attachment was required, but less automatic than a true zero-interaction mail-server exploit.

Why a Warning Did Not Protect the User

The warning was attached to the model's interpretation of the task, while the risky behavior occurred in the tool path used to complete the task.

That creates a timing problem:

  1. Manus received untrusted email content.
  2. The model decided it should decode the content.
  3. The execution environment ran the decoder.
  4. The decoder executed the embedded JavaScript.
  5. The safety layer recognized danger and warned the user.

By step five, the security boundary had already been crossed.

A human-approval dialog is meaningful only when the sensitive operation is still pending. If the system performs a preparatory action that is itself capable of executing code, the approval gate sits too late in the sequence.

This is also why prompt filtering alone is brittle. The direct instruction and Base64 cases were recognized. The less familiar representation reached a different tool path. Attackers do not need every bypass to work; they need one path the detector and executor interpret differently.

What Connected-Service Users Should Do

Salt says the demonstrated Manus issue is fixed, so this is not a recommendation to panic or assume compromise. It is a reason to review agent permissions with the same care given to browser extensions, service accounts, and automation platforms.

Inventory every connected account

List the services the agent can reach: email, cloud storage, repositories, calendars, messaging, customer records, financial tools, and internal APIs. Do not rely on remembering which “Connect” buttons were clicked months ago.

Remove integrations that are not needed now

An inactive connector can still enlarge the consequences of a future flaw. Disconnect services that are not necessary for current work. Reconnect intentionally when the benefit justifies the access.

Narrow scopes and use separate accounts

Prefer read-only access when writing is unnecessary. Give an email assistant a dedicated mailbox rather than a personal or executive inbox when practical. Give a repository assistant access only to the specific repositories it needs.

Separation does not prevent prompt injection, but it limits what a successful injection can reach.

Review and revoke stale tokens

Use the security settings of Google, GitHub, and other connected providers to review authorized applications and active sessions. Revoke tokens that are unused, unexpected, or broader than the current task requires.

The public report does not instruct all Manus users to rotate credentials, and it does not establish theft from real accounts. Rotation is a risk-based response for users who had sensitive connectors enabled during an uncertain affected period, especially if account logs show unexpected activity.

Treat external content as hostile input

Email, documents, web pages, issue comments, and API responses can all carry instructions an agent may mistake for part of its task. Do not give an autonomous workflow standing authority to run code, send messages, or read unrelated secrets merely because its normal input “looks like data.”

Put approval before the consequence

A useful confirmation should show the exact action, destination, data, and account before execution. “The agent detected something suspicious” after a process has run is an alert, not an approval control.

What Agent Builders Should Change

OWASP's AI Agent Security Cheat Sheet recommends least-privilege tools, independent policy enforcement, input validation, and human approval for high-risk actions. The Manus case shows why those controls must extend below the model interface.

Parse untrusted content without tools

Use a quarantined component with no shell, network, secrets, or action tools to extract text from email and documents. Pass structured, labeled data forward rather than concatenating raw content into an instruction stream.

Never execute a decoder just to inspect content

Decoding should produce inert bytes or text. It should not evaluate expressions, import modules, launch interpreters, or invoke a general-purpose runtime on attacker-controlled input.

Keep credentials outside the agent sandbox

The model should select a connector and a narrow operation. A trusted service outside the sandbox should verify policy and attach a short-lived credential only when the operation is allowed. Broad OAuth tokens should not be readable as ordinary environment variables by every process the agent can start.

Default outbound network access to deny

A reverse shell requires an outbound connection. Restrict destinations and protocols to the minimum necessary for the task. Log denied requests and make new destinations a deliberate policy change.

Bind approval to the exact action

Approval for “process this email” should not authorize “run Node.js,” “open a socket,” or “read a cloud-storage token.” The enforcement layer should verify the tool, parameters, data source, destination, and account after the model proposes an action but before the action runs.

Test order of operations

Security testing should record when data was parsed, decoded, executed, transmitted, and blocked. A clean final response or visible warning does not prove that nothing already happened in the background.

Where OpenVeil Fits—and Where It Does Not

OpenVeil is a privacy-focused hosted AI workspace for adults. It is relevant when someone wants conversational writing, analysis, brainstorming, or question answering without granting an autonomous agent standing access to Gmail, Google Drive, GitHub, a shell, or other external accounts.

OpenVeil keeps normal chat history in the browser and does not create a normal server-side chat-history record. Its documented prompts, uploads, media, selected local history, and outputs are not used for foundation-model training. Active requests still require processing by OpenVeil and necessary providers.

That narrower boundary avoids the specific connector-and-shell combination at the center of the Manus demonstration. It does not make OpenVeil a security product. OpenVeil is not:

If your work genuinely needs an autonomous agent to read inboxes, execute code, or act across connected services, evaluate that agent's permissions, credential isolation, egress controls, approval sequence, audit logs, and incident response. If you mainly need a private-feeling place to think and draft without those powers, trying OpenVeil is the more natural comparison.

Frequently Asked Questions

Can a malicious email still hijack Manus today?

Salt says the specific vulnerability it demonstrated has been resolved and was no longer reproducible in later tests. The public disclosure does not include a version number or independent post-fix audit, so it cannot prove that every possible indirect-prompt-injection path is eliminated.

Was this a zero-click attack?

Not in the strictest sense. The victim did not click a link or open an attachment, but the chain required the user to ask Manus to check or retrieve the malicious message. Email delivery alone was not described as the execution trigger.

Did the attacker control the user's computer?

The researchers obtained code execution and a reverse shell inside the Manus cloud sandbox used for the task. The report does not say they compromised the user's laptop or phone.

Were Gmail messages or Google Drive files stolen?

Salt found the Gmail integration token and credentials for other connected services in the controlled sandbox, establishing potential access. The public report does not document theft from unrelated real users or an in-the-wild campaign.

Why did Manus warn the user if the attack worked?

The warning arrived after Manus had invoked Node.js and executed the decoded payload. The system detected danger too late in the operation to prevent the first execution.

Is JSFuck itself malware?

No. JSFuck is a way to represent valid JavaScript using a very small character set. It can encode harmless or malicious code. The security failure was evaluating attacker-controlled code in a privileged execution path, not the character format by itself.

Would a stronger prompt solve this problem?

No prompt can safely replace execution controls. Better instructions and classifiers may block more attacks, but untrusted content must still be isolated from shells, tokens, networks, and consequential tools by deterministic controls outside the model.

Does browser-local chat history prevent prompt injection?

No. History location and tool authority are separate boundaries. Browser-local history can reduce server-side conversation storage, but it does not secure an autonomous email connector or sandbox.

Bottom Line

Salt Labs showed a concrete failure chain: a malicious email became instructions, an unfamiliar encoding sent those instructions through Node.js, code ran before the warning appeared, and the resulting shell could reach credentials for connected services.

The demonstrated Manus flaw is patched, and there is no public evidence of mass exploitation or real-user data theft. The architectural warning remains: an AI agent that reads hostile content should not also have unrestricted interpreters, outbound network access, and broadly reusable account tokens in the same execution environment.

The practical choice is not simply “trust the guardrail” or “never use agents.” It is to match authority to the task. Keep untrusted parsing powerless, keep credentials outside the sandbox, enforce permissions before tool calls, and avoid granting autonomous account access when ordinary conversation is enough.

Sources

This article provides general information, not legal, incident-response, or cybersecurity advice. If you suspect unauthorized account access, preserve relevant logs and work with the affected provider or a qualified security professional.

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.