Salt Labs披露已修复的Manus邮件注入问题：安全提醒是否早于动作，值得单独检查

Salt Security于2026年10月1日发布Salt Labs研究公告，披露此前在Manus中验证的邮件间接提示注入问题。研究者称，测试中警告出现时相关动作已经执行，可能波及用户连接的服务。公告同时明确，该问题已得到修复，后续复现未成功。这里的新闻事件是研究披露，不能写成目前仍可用同样方式入侵；本文也不提供攻击复现步骤。

AI生成概念示意图，非真实产品照片、软件界面或事件现场。

独立分析：识别到了什么，还要看何时发生

一项安全检查发现了异常，和它及时阻止了不合适的动作，是两个需要分别验证的结果。对能够调用工具的助手而言，时间顺序会影响防护是否有效。检查报告若只列出“已告警”，可能没有说明告警前后环境发生了什么。

以下是虚构的防御验收场景，不针对真实服务进行攻击。团队可以在隔离演示环境里放入一封带有明显测试标记的邮件，约定助手只需要总结邮件内容。随后观察邮件中的额外要求是否被当成材料描述，还是错误地进入待执行任务。

验收重点不是诱导出某个危险结果，而是确认执行边界：哪些输入只能被阅读，哪些动作必须来自用户明确任务，以及工具调用前能否核对这两者的关系。所有材料与账户都使用演示版本，避免把真实连接服务卷入测试。

把提醒、暂停与执行记录连起来

一条完整记录应能看见输入到达、助手提出动作、检查作出决定和工具实际执行的先后顺序。如果系统决定暂停，后面就应能够验证相应动作尚未发生；如果已经发生，则需要记录真实状态，而不能只用一条提醒掩盖。

本文建议把“只审阅内容”和“允许修改外部状态”的任务分开设计验收。两者可能使用同一个模型，却不应自动拥有相同动作范围。团队可以从任务目的反推所需工具，减少与当前任务无关的连接。

人类复核也需要看到具体对象和动作。一个抽象的“是否继续”按钮很难支持判断；若能显示准备对哪项资源做什么、依据哪条用户要求，复核者才更容易发现来源内容越过了任务边界。

修复之后，保留能够回看的验证办法

某个具体问题修复，并不意味着以后无需检查相似的信任边界。可以把这次披露转化为内部验收问题，保留演示材料、预期状态与观察办法。当工具、权限或连接方式改变时，再核对受影响的部分。

对于普通使用者，更实际的习惯是让任务目标保持具体，并在涉及对外动作时看清目标与内容。若助手出现与原任务无关的操作，应先核对当前状态和授权范围，而不是因为它同时给出了警告就假定没有任何变化。

这份披露值得留下的区别是：研究发生时间、公开披露时间和修复状态各自回答不同问题。报道时把这三者写清，既能讨论设计上的教训，也能避免让读者误以为已解决的问题仍是正在发生的入侵。

来源与核验

Salt Labs披露已修复Manus邮件注入问题：厂商发布的原始公告（2026-10-01）。

本文于北京时间2026年10月2日核验。后续分析与假设场景为原创讨论，不代表厂商承诺或独立实测。