Một email là đủ: khi guardrail phát hiện được tấn công nhưng vẫn không chặn đượ
Tóm tắt
Salt Labs, bộ phận nghiên cứu của Salt Security, đã biến nền tảng agentic AI Manus thành một đường dẫn tới remote code execution chỉ bằng một email.
Nạn nhân không cần bấm link, không tải file đính kèm, không nhập mật khẩu. Toàn bộ cuộc tấn công cần đúng hai sự kiện:
Email chứa chỉ thị ẩn được gửi tới hộp thư Gmail mà người dùng đã kết nối với Manus.
Người dùng, ở một thời điểm nào đó sau đó, nhờ Manus kiểm tra hộp thư. Từ đó, nhóm nghiên cứu đạt được thực thi mã trong sandbox của Manus, dựng reverse shell, và tìm thấy token của các dịch vụ bên thứ ba mà người dùng đã kết nối: Gmail, Google Drive và GitHub.
Chi tiết đáng chú ý nhất không phải việc vượt qua guardrail. Manus có guardrail, và guardrail đó đã phát hiện hoạt động độc hại. Nó hiện cảnh báo bảo mật. Vấn đề là cảnh báo xuất hiện sau khi mã đã chạy.
Hành động ưu tiên:
Lập danh sách các agent AI đang được nhân viên kết nối vào email, cloud storage và repository của tổ chức, kèm scope của từng OAuth token.
Coi mọi nội dung agent đọc được là input không tin cậy, giống như cách bạn đối xử với email đến từ Internet.
Manus hoạt động thế nào
Manus là nền tảng agentic AI đa dụng, cho phép người dùng kết nối tài khoản bên thứ ba như Gmail, Google Drive và GitHub để agent hành động thay mình.
Khi người dùng gửi một tác vụ liên quan tới Gmail, Manus cấp một sandbox trên cloud riêng cho phiên đó và chạy tác vụ trong sandbox, thông qua tooling kiểu MCP, dùng access token Gmail của người dùng.
Điểm thiết kế quan trọng nhất, và Salt Labs nêu rõ đây là theo thiết kế: dữ liệu nhạy cảm, bao gồm access token, được lưu trong sandbox của người dùng. Nghĩa là nếu kẻ tấn công thực thi được mã trong sandbox đó, họ ở cùng chỗ với token.
Salt Labs cũng nói rõ họ không nghiên cứu việc thoát sandbox. Toàn bộ thiệt hại mô tả dưới đây nằm trong phạm vi một sandbox, nhưng sandbox đó chứa token sống của mọi dịch vụ người dùng đã nối.
Chuỗi tấn công
Gửi email chứa chỉ thị ẩn tới hộp thư Gmail đã kết nối. Bước này không cần nạn nhân làm gì, vì ai cũng gửi được email cho người khác.
Người dùng nhờ Manus kiểm tra hộp thư. Đây là tác vụ hoàn toàn bình thường, cũng là lý do người ta kết nối Gmail với agent ngay từ đầu.
Manus đọc email và coi nội dung là chỉ thị. Đây chính là indirect prompt injection: mô hình không phân biệt được đâu là yêu cầu của người dùng, đâu là nội dung dữ liệu nó đang xử lý.
Payload được chuyển vào Node.js runtime và thực thi.
Thực thi mã trong sandbox, rồi dựng reverse shell về máy của nhóm nghiên cứu.
Hành trình vượt guardrail
Phần này là nội dung giá trị nhất của nghiên cứu, vì nó cho thấy guardrail hoạt động tới đâu rồi hỏng ở đâu.
Chỉ thị dạng plain text bị chặn. Khi email yêu cầu Manus chạy lệnh shell một cách trực tiếp, Manus hiện cảnh báo bảo mật và hỏi người dùng phê duyệt trước khi tiếp tục. Guardrail làm đúng việc của nó.
Base64 và vài kiểu mã hóa khác cũng bị phát hiện và chặn trước khi thực thi.
JSFuck thì lọt. JSFuck là kiểu mã hóa JavaScript chỉ dùng vài ký tự ([, ], (, ), +, !), tạo ra chuỗi dài và hoàn toàn không giống mã nguồn bình thường. Guardrail không nhận ra, Manus tự giải mã, và đoạn mã được chuyển vào runtime để chạy.
Cảnh báo vẫn hiện, nhưng hiện sau. Đây là hình ảnh quan trọng nhất của toàn bộ nghiên cứu: Manus vẫn phát hiện được hoạt động đáng nghi và báo cho người dùng, nhưng bước giải mã đã chạy mã trước đó rồi. Salt Labs gọi đây là "sự thiếu nhất quán nghiêm trọng giữa phát hiện và thực thi chính sách".
Bán kính thiệt hại
Có mã thực thi trong sandbox, nhóm nghiên cứu tiếp cận được:
Gmail MCP interface, bao gồm OAuth token của nạn nhân. Tức là đọc, gửi và xử lý thư với quyền của chính nạn nhân.
Credential và token của các dịch vụ đã kết nối, nằm trong biến môi trường của sandbox. Salt Labs nêu Google Drive và GitHub làm ví dụ. Đường đi của cuộc tấn công, theo mô tả của Salt Labs, chạy từ email → mô hình → tool → runtime → hệ điều hành → token được lưu → tài khoản bên thứ ba. Bán kính thiệt hại lớn vì một môi trường duy nhất giữ token sống cho mọi dịch vụ đã kết nối.
Với một nhân viên nối Manus vào Gmail công việc, Drive chứa tài liệu nội bộ và GitHub của tổ chức, một email là đủ để chạm tới cả ba.
Vấn đề kiến trúc: phát hiện mà không chặn được
Luận điểm trung tâm của Salt Labs đáng trích nguyên văn ý: trong hệ thống tự hành, không có người ngồi xem alert trước khi hành động xảy ra. Một biện pháp kiểm soát kích hoạt muộn thì coi như chưa kích hoạt.
Điều này khác căn bản với mô hình bảo mật truyền thống. Một alert EDR hiện lúc 3 giờ sáng vẫn có giá trị, vì phân tích viên sẽ xử lý vào buổi sáng và thường còn kịp. Nhưng với agent, chuỗi hành động diễn ra trong vài giây và không chờ ai phê duyệt. Phát hiện sau khi hành động có tác động lớn đã thực thi thì không ngăn được gì.
Vấn đề thứ hai là guardrail đang canh sai tầng. Phần lớn công cụ bảo mật AI hiện nay tập trung vào prompt và hành vi mô hình. Nhưng agent không gây thiệt hại trong hội thoại, nó gây thiệt hại qua tool, API và tài khoản. Một guardrail chỉ quan sát hội thoại giống như camera đặt ở sảnh trong khi cửa kho hàng mở ở phía sau.
Nhận định
Lỗi cụ thể đã vá, mô hình thì chưa. Salt Labs nói rõ điều này và mình đồng ý: đây là vấn đề kiến trúc của mọi agent đọc input không tin cậy và có quyền hành động trên hệ thống đã kết nối. Việc Manus đã sửa không làm giảm giá trị của bài học, vì kiến trúc tương tự đang được triển khai ở hàng loạt sản phẩm khác.
JSFuck lọt trong khi Base64 bị chặn là minh chứng cho giới hạn của pattern matching. Guardrail dạng khớp mẫu luôn chạy sau kẻ tấn công: nó chỉ biết những cách che giấu đã từng thấy. Với một không gian mã hóa JavaScript gần như vô hạn, cuộc đua này không có đích. Đây là lý do khuyến nghị "thêm guardrail tốt hơn" không giải quyết được gốc vấn đề.
Việc lưu token của mọi dịch vụ trong một sandbox là điểm thiết kế cần xem lại. Salt Labs không khai thác sandbox escape, nên thiệt hại được đo trong phạm vi một sandbox. Nhưng chính phạm vi đó đã đủ lớn. Nguyên tắc least privilege ở đây có nghĩa là token cho tác vụ Gmail không nên nằm cùng chỗ với token GitHub, và token nên có scope hẹp theo tác vụ thay vì theo tài khoản.
Câu chuyện công bố lỗ hổng cũng đáng chú ý. Salt Labs báo cho Manus nhưng Manus không phản hồi. Nhóm sau đó gửi lỗ hổng qua bug bounty của Meta, vì thời điểm đó Meta đang chuẩn bị mua lại Manus. Meta tiếp nhận, xác nhận và xử lý; thương vụ sau đó không diễn ra và hai công ty vẫn độc lập. Tình huống này nói lên một vấn đề thực tế của ngành: nhiều công ty AI tăng trưởng rất nhanh nhưng chưa có quy trình nhận báo cáo lỗ hổng, và người nghiên cứu phải tìm đường vòng.
Khuyến nghị cuối của Salt Labs có yếu tố bán sản phẩm. Phần kết của họ nói về nhu cầu "hiển thị và kiểm soát toàn bộ đường đi agentic, từ mô hình qua MCP server và API tới hệ thống đích", đúng với sản phẩm họ bán. Điều đó không làm luận điểm sai, nhưng nên đọc với ý thức đó.
Liên hệ Việt Nam
Doanh nghiệp Việt đang nối agent AI vào hệ thống rất nhanh. Các công cụ agentic thường được nhân viên tự đăng ký và tự kết nối tài khoản, không qua rà soát của bộ phận bảo mật. Đây là shadow IT với quyền truy cập cao hơn shadow IT truyền thống.
OAuth token cấp cho agent thường có scope rất rộng. Người dùng bấm "Allow" cho toàn bộ quyền đọc và ghi Gmail hoặc toàn bộ repository mà không đọc chi tiết, vì scope hẹp thì agent hay báo lỗi.
Không có quy trình thu hồi. Khi nhân viên nghỉ việc hoặc đổi công cụ, token cấp cho agent cũ thường không bị rà soát. Danh sách ứng dụng đã kết nối trong Google Workspace hay GitHub hiếm khi được kiểm tra định kỳ.
Email là kênh input mặc định. Mọi tổ chức đều nhận email từ bên ngoài, nên tác vụ "agent đọc hộp thư giúp tôi" vừa phổ biến vừa là bề mặt tấn công sẵn có mà không cần kẻ tấn công xâm nhập trước.
Khuyến nghị
Kiểm kê agent và scope. Rà soát danh sách ứng dụng bên thứ ba đã được cấp quyền trong Google Workspace, Microsoft 365 và GitHub của tổ chức, xác định agent nào đang giữ token gì, và thu hồi những gì không còn cần thiết.
Giới hạn quyền theo tác vụ, không theo tài khoản. Nếu agent chỉ cần đọc thư, đừng cấp quyền gửi. Nếu chỉ cần một repository, đừng cấp quyền toàn tổ chức. Đây là biện pháp giảm bán kính thiệt hại hiệu quả nhất và không phụ thuộc vào việc phát hiện tấn công.
Chặn hành động nhạy cảm trước khi chạy, không phát hiện sau. Với bất kỳ hệ thống agentic nào tổ chức tự xây, các hành động như thực thi mã, gọi mạng ra ngoài, hoặc ghi dữ liệu phải đi qua cổng phê duyệt trước khi thực thi, chứ không phải cảnh báo sau đó.
Coi mọi nội dung agent đọc là input không tin cậy: email, trang web, file tài liệu, nội dung issue và pull request. Kẻ tấn công không cần truy cập vào hệ thống của bạn, chỉ cần đưa được văn bản vào nơi agent sẽ đọc.
Thiết kế với giả định guardrail sẽ bị vượt. Guardrail là một lớp, không phải biện pháp duy nhất. Nếu toàn bộ an toàn của hệ thống phụ thuộc vào việc bộ lọc nhận ra mọi cách che giấu, hệ thống đó đã có vấn đề thiết kế.
Giám sát hành vi của agent ở tầng hành động: kết nối ra ngoài từ môi trường thực thi của agent, truy cập biến môi trường hoặc file credential, và các lệnh gọi API vượt ra ngoài phạm vi tác vụ người dùng yêu cầu.
Tài liệu tham khảo
Salt Labs (Salt Security Research Team) — How We Hijacked an AI Agent With a Single Email (01/10/2026): https://salt.security/blog/how-we-hijacked-an-ai-agent-with-a-single-email
Salt Labs — When a Security Guardrail Detects the Attack and Still Can't Stop It (01/10/2026): https://salt.security/blog/when-a-security-guardrail-detects-the-attack-and-still-cant-stop-it
Salt Security — thông cáo báo chí, bao gồm phát ngôn của Yaniv Balmas và chi tiết công bố lỗ hổng (01/10/2026): https://www.prnewswire.com/news-releases/salt-labs-research-a-single-email-could-hijack-an-ai-agent-and-reach-a-users-connected-accounts-302895317.html
IT Security Guru — Malicious Email Could Hijack AI Agent and Access Connected Accounts (02/10/2026): https://www.itsecurityguru.org/2026/10/02/malicious-email-could-hijack-ai-agent-and-access-connected-accounts/
