// hackerlogs
login+ register
Prompt InjectionAgentic AIThreat BriefHigh

The Manus Warning Fired After the Mail Had Already Run.

Salt Labs' 1 October post says a Manus inbox task ran untrusted mail before the warning. Connected tokens were already in that sandbox. No fix build is named.

The short answer

Salt Labs published the full Manus account on 1 October 2026. Reading mail could run untrusted email in that user's sandbox before the warning. A plain shell instruction was stopped. An obfuscated script was not. The sandbox held the Gmail token and any connected Drive or GitHub token. Meta had fixed it. Salt's retest failed. No build is named.

Key takeaways

  • The primary is Salt Labs on 1 October. Dark Reading had the exclusive on 24 September. The fix was already claimed. The full post is the operator record.
  • A direct shell instruction in email was held for approval. An uncommon JavaScript obfuscation ran in the sandbox first. The warning came after that run.
  • The sandbox held the user's Gmail OAuth token through the Gmail MCP. Drive and GitHub tokens were present when those accounts were connected.
  • Salt says Manus did not answer the report. Meta's bug bounty triaged it and fixed it. A later Salt attempt failed. No build number is published.
  • Rotate connected tokens you cannot date after the fix. A warning that fires after the tool call is not a block.

Salt Labs published the full account on 1 October. The primary is How We Hijacked an AI Agent With a Single Email. A person asked Manus to read mail. Untrusted email became code inside that person's cloud sandbox before the security warning. The Gmail OAuth token was already there. Drive and GitHub tokens were there when those accounts were connected. Dark Reading had the exclusive on 24 September. Meta's fix was already claimed then. The 1 October post is the operator record, and it still has no build number.

Hacker News on 1 October led with Pi 1.0, a Cloudflare decision-model launch, and a 2025 OpenID paper on agent identity. US X trends were football, a cosmetics tag, and a sneaker ticker. None of those is this control.

High Indirect injection from inbox to a sandbox that already holds connected-account tokens. High because the token is the blast radius, not because Salt says the Manus bug is still open.

Three panels for the Manus inbox failure: untrusted mail ran before the warning, a seven-day gap from the 24 September exclusive to the 1 October write-up with no build number, and the operator move to rotate tokens and fail closed.

What Salt Labs actually showed.#

Manus runs a user's task in a cloud sandbox. For Gmail, Salt says that sandbox calls a Gmail MCP with the user's OAuth token. The user in the test only asked the agent to show recent mail. The attacker only had to have a message waiting in that inbox.

A direct instruction to run a shell command was caught. Manus stopped, showed a warning, and asked for approval. Salt's reading of that stop is the important half. The agent had already treated the email as instructions, not as text to quote. Ordinary encodings were caught the same way: decode, then block.

The miss was an uncommon JavaScript obfuscation, which Salt Labs and Dark Reading both name. The agent ran that script in the sandbox. The warning for it arrived after the run. Salt then showed the same path could reach the tokens stored for the integration. This brief does not repeat the script.

The press release the same day is narrower and consistent. The chain needed two events: the message in the inbox, and the user asking Manus to check mail. No stolen password. No clicked link. Salt says the research was earlier this year, that a report to Manus got no response, and that Meta's bug bounty triaged, confirmed, and fixed it. A later attempt failed. Meta and Manus remain separate companies. A purchase that was being prepared did not go through.

The fix clock and the impact clock.#

The fix clock is Meta's patch, and it is undated. Dark Reading on 24 September already said Meta had patched the issue. Salt's 1 October post and the same-day release add that a later reproduction failed. Neither page prints a build, a changelog, or the hour the patch shipped. Seven days is the gap between the exclusive and the full write-up. It is not the gap between bug and fix. That earlier gap is unpublished.

The impact clock is the token. Salt says the sandbox held the Gmail OAuth token for the connected user, and that Drive and GitHub credentials were in the environment when those services were connected. Closing the bug does not expire a token that was already in that process. Salt does not say those tokens were used outside the lab. It also does not give you a timestamp that proves yours was minted after the fix.

  1. Salt says the research was earlier this year. It reported the issue to Manus and got no response, then filed through Meta's bug bounty.
  2. Dark Reading exclusive. Meta has triaged, confirmed, and patched. No build number. Manus and Meta are asked for comment.
  3. Salt Labs publishes the full write-up. A later reproduction failed. The warning-after-execution order is the operator fact. Still no fix date.

What this is not.#

It is not a claim that Manus is still exploitable. Salt says the later attempt failed. Do not brief it as an open bug. Do not brief the missing build as proof the fix is fictional.

It is not a sandbox escape onto Manus's provider. Salt says a user inside their own sandbox is not the boundary they crossed. An attacker reaching someone else's sandbox through mail is the boundary. Salt leaves escape from that sandbox for later research.

It is not a stolen password or a phishing click. The user asked the agent to read mail. That request is the intended product path.

It is also not evidence of a named victim outside the lab. Salt's account is a controlled test on a connected inbox. Absence of a named customer breach is not a reason to skip rotation if those tokens were present while the path was open.

What to do.#

  1. If Gmail, Drive, or GitHub was connected to Manus before you can prove Meta's fix, rotate those tokens and revoke the old grants at the provider. Installing nothing new on your side expires nothing that already left.
  2. Do not accept a post-run warning as the control. The tool call from untrusted mail has to fail before it runs. A dialog after the script is a record of the miss.
  3. Keep the OAuth token out of the sandbox that reads mail. Inject it only for the named API host, for that call, from a broker the mail content cannot read back.
  4. Test the action, not the string. Salt says a plain shell instruction and ordinary encodings were stopped, and one uncommon obfuscation was not. A filter that only catches the obvious instruction will pass the next encoding.
  5. Ask who answers a vulnerability report before you connect a mailbox. Salt says Manus did not answer, and the fix arrived through Meta's bounty while a purchase was being prepared. The two companies stayed separate. The reply path is part of the control.

The fix clock stopped, by Salt's account, before the 24 September exclusive, on a build nobody has numbered. The impact clock is any connected token you cannot place after that fix. The 1 October post is the day the order of operations became the primary, not the day the bug closed.

Frequently asked

Is the Manus email path still exploitable?

Salt Labs says no. The 1 October post and the same-day release say Meta confirmed and fixed the issue, and that a later attempt to reproduce it failed. Salt does not publish the fix date or a version string. Treat the closed-bug claim as theirs, and still rotate tokens that sat in a mailbox-reading sandbox while the gap was open.

Did the guardrail fail to notice the email?

It noticed a plain shell instruction and stopped for approval. It also raised a warning on the obfuscated script. Salt's point is the order. The obfuscated script had already run. A detector that speaks after an agent has acted does not protect a system with no person in between.

Is this a breakout from the Manus sandbox onto the provider?

Salt draws the opposite bound. The cloud sandbox is where that user's own Gmail task is supposed to run. The boundary that failed is an outsider reaching that sandbox through email, then reading tokens the integration had already placed there. Salt sets sandbox escape aside as later work.

Do we have to disconnect every mail-reading agent?

Disconnect when the agent can execute mail and the token for a connected account lives in that same environment. If you keep the integration, inject the token only for the named API host, and make a tool call that originates in untrusted mail fail closed before it runs.

Sources

Related