SalesBleed: Agentforce từng có thể làm rò dữ liệu CRM mà không cần người dùng nhấp

Tóm tắt: Zenity Labs công bố chuỗi lỗi SalesBleed: chỉ dẫn độc hại được cài vào biểu mẫu Web-to-Lead công khai có thể chờ đến khi nhân viên dùng Agentforce, rồi khiến agent đọc dữ liệu CRM và gửi ra ngoài qua DNS. Chuỗi lỗi cụ thể đã được Salesforce vá, nhưng cơ chế tấn công vẫn là bài học lớn cho mọi doanh nghiệp nối AI Agent với dữ liệu và công cụ thật.

Ngày 24/09/2026, Zenity Labs công bố nghiên cứu SalesBleed về Agentforce của Salesforce. Theo nhóm nghiên cứu, kẻ tấn công không cần đăng nhập vào hệ thống của nạn nhân. Điểm vào là biểu mẫu Web-to-Lead công khai, vốn được dùng để đưa thông tin khách hàng tiềm năng vào CRM.

Kẻ tấn công có thể giấu một chỉ dẫn độc hại trong trường dữ liệu của lead. Chỉ dẫn này nằm yên cho đến khi một nhân viên yêu cầu Agentforce thực hiện tác vụ bình thường như “kiểm tra lead mới nhất”. Agent đọc dữ liệu do bên ngoài gửi vào, làm theo chỉ dẫn ẩn, truy vấn bảng Accounts và ghép dữ liệu nhạy cảm vào tên miền do kẻ tấn công kiểm soát.

Điều quan trọng: Zenity xác nhận Salesforce đã khắc phục chuỗi lỗi cụ thể. Bản vá cho đường rò dữ liệu được xác nhận trong tháng 8/2026; các sửa đổi liên quan Agentforce trong Slack được xác nhận hoàn tất ngày 21/09/2026. Vì vậy, đây không phải thông báo rằng Agentforce hiện vẫn còn nguyên lỗ hổng.

Chuỗi tấn công hoạt động như thế nào?

1. Đưa lệnh vào CRM: kẻ tấn công gửi một lead qua biểu mẫu Web-to-Lead công khai, trong đó có prompt injection ẩn.
2. Kích hoạt bằng công việc bình thường: nhân viên hỏi agent về lead mới; không cần mở tệp hay nhấp liên kết.
3. Dùng quyền sẵn có: agent có quyền đọc cả bảng Leads và Accounts, nên chỉ dẫn độc hại không cần nâng quyền mới.
4. Đóng gói dữ liệu vào URL: dữ liệu như tên công ty hoặc giá trị thương vụ được đưa vào subdomain.
5. Rò qua DNS: giao diện tải ảnh hoặc Slack tạo preview cho URL, phát sinh truy vấn DNS tới máy chủ do kẻ tấn công kiểm soát.

Zenity gọi đây là “zero-click” vì người dùng không nhấp vào nội dung do kẻ tấn công gửi. Người dùng vẫn thực hiện một hành động bình thường — yêu cầu agent xem lead — nhưng mọi bước sau đó diễn ra tự động.

Vì sao lớp Trusted URLs không chặn được?

Agentforce có cơ chế Trusted URLs nhằm loại URL không được tin cậy khỏi câu trả lời. Zenity cho biết nhóm nghiên cứu đã kết hợp hai điểm lệch: bộ lọc không nhận diện một số tên miền cấp cao, và bộ lọc với trình duyệt hiểu khác nhau về ký tự kết thúc URL.

Chuỗi trông không hợp lệ với bộ lọc vẫn có thể được giao diện hiểu đủ để phát sinh yêu cầu tải ảnh. Dữ liệu đã rời hệ thống ngay ở bước phân giải DNS; kể cả yêu cầu HTTP sau đó bị chặn hoặc thất bại, việc rò dữ liệu vẫn có thể đã xảy ra.

Đây là khác biệt quan trọng giữa kiểm soát nội dung và kiểm soát hành động. Một bộ lọc có thể thông báo rằng URL bị chặn, nhưng nếu thành phần phía sau đã xử lý hoặc tải tài nguyên trước thời điểm chặn, kết quả hiển thị không phản ánh đúng điều hệ thống đã làm.

Năm kiểm soát rút ra cho AI Agent doanh nghiệp

1. Coi dữ liệu từ bên ngoài là lệnh không đáng tin

Email, form lead, ticket hỗ trợ, tài liệu tải lên và tin nhắn khách hàng đều có thể chứa chỉ dẫn nhắm vào agent. Nội dung đó cần được tách khỏi chỉ dẫn hệ thống và không được tự động nâng thành mục tiêu hành động.

2. Tách quyền đọc dữ liệu công khai và dữ liệu nhạy cảm

Một agent xử lý lead không nên mặc nhiên có quyền đọc toàn bộ Accounts, Contacts hoặc giá trị thương vụ. Quyền quá rộng biến prompt injection thành sự cố dữ liệu dù kẻ tấn công không hề nâng quyền.

3. Kiểm soát đường dữ liệu đi ra ngoài

Không chỉ giám sát HTTP. DNS, tải ảnh, preview liên kết, webhook và các connector đều có thể trở thành đường rò. Hệ thống cần chính sách egress theo miền đích, loại dữ liệu và hành động.

4. Đặt phê duyệt và gắn danh tính cho hành động ghi

Trong chuỗi phishing qua Slack, nguy cơ tăng khi agent có thể trả lời thread mà không cần xác nhận và thiếu thông tin người kích hoạt. Salesforce đã thay đổi mặc định này, nhưng doanh nghiệp vẫn cần kiểm tra cấu hình vì quyền xác nhận có thể bị tắt.

5. Kiểm thử cả chuỗi, không chỉ kiểm thử mô hình

Lỗi xuất hiện từ sự kết hợp giữa dữ liệu đầu vào, quyền truy vấn, bộ lọc URL, trình render và DNS. Đánh giá riêng từng thành phần có thể bỏ lỡ rủi ro chỉ xuất hiện khi toàn bộ chuỗi vận hành cùng nhau.

Fact và nhận định cần tách biệt

Fact đã xác minh: Zenity công bố hai biến thể rò dữ liệu không cần nhấp và một đường phishing qua Slack; SecurityWeek tổng hợp thành ba lỗ hổng. Zenity báo cáo cho Salesforce ngày 01/06/2026 và xác nhận chuỗi lỗi đã được vá trước khi công bố rộng rãi.

Nhận định của Học viện AI: bài học không nằm ở việc né một sản phẩm cụ thể, mà ở cách thiết kế agent. Khi cùng một danh tính được phép đọc dữ liệu bên ngoài, đọc dữ liệu nhạy cảm và tạo đầu ra có kết nối mạng, ba năng lực này tạo thành một “tam giác nguy hiểm”.

Doanh nghiệp có thể đối chiếu thêm 7 AI Agent Salesforce đóng gói theo vai việc, cách Splunk quản trị quyền cho AI Agent qua MCP và quan điểm bên phát triển phải chịu trách nhiệm khi AI Agent gây hại. Ba bài cùng cho thấy quy mô triển khai càng lớn, quyền công cụ và bằng chứng kiểm soát càng phải rõ.

Nếu doanh nghiệp đang nối AI Agent với CRM, email, Slack hoặc dữ liệu nội bộ, hãy nhận proposal thiết kế phân quyền và kiểm soát theo quy trình thật.

Nguồn tham khảo

• Zenity Labs — SalesBleed: 0-Click Data Exfiltration in Agentforce, 24/09/2026.
• Zenity Labs — Hijacking Agentforce in Slack, 24/09/2026.
• SecurityWeek, 25/09/2026.