SalesBleed: Một lead công khai, ba lỗ hổng Agentforce, không một lượt nhấp

Vào ngày 24 tháng 9 năm 2026, Zenity Labs đã công bố nghiên cứu mà họ gọi là SalesBleed: ba lỗ hổng trong Salesforce Agentforce, nền tảng của nhà cung cấp CRM để xây dựng và triển khai các tác nhân AI, cho phép kẻ lạ lấy hồ sơ khách hàng ra khỏi org Salesforce của một công ty rồi sau đó dùng chính tác nhân của công ty đó để lừa đảo nhân viên của mình. Hai trong ba lỗ hổng không cần bất kỳ cú nhấp chuột nào từ bất kỳ ai bên trong công ty. Rủi ro phơi nhiễm áp dụng cho các tenant Agentforce chấp nhận các bài gửi Web-to-Lead, và với mọi tác nhân mà tenant đã công bố vào Slack. Dark Reading đưa tin rằng không có mã định danh CVE nào được gán, và Salesforce nói với tờ báo rằng họ không có bằng chứng về việc khai thác nhắm vào bất kỳ khách hàng nào. Toàn bộ hồ sơ, cùng với xếp hạng độ tin cậy và trạng thái tổn hại do chính kho lưu trữ đưa ra, nằm trong Orca AI Incident Archive, nơi ghi lại từng sự cố tác nhân được ghi nhận dựa trên các nguồn được trích dẫn của nó.

Một biểu mẫu thu thập khách hàng tiềm năng công khai trở thành kênh dữ liệu như thế nào

Web-to-Lead là cơ chế chính thức của Salesforce để thu thập lead, và theo thiết kế, nó không được xác thực — nó tồn tại để bất kỳ ai trên internet cũng có thể gửi một biểu mẫu và nội dung sẽ được đưa vào CRM của khách hàng. Bài đăng đầu tiên của Zenity, được ghi công cho Alex Apostolov và các đồng nghiệp, mở đầu bằng chính điều đó như toàn bộ điều kiện đầu vào: không có tài khoản nào để đình chỉ, không có phiên nào để thu hồi, không có sự kiện đăng nhập nào để phát hiện. Kẻ tấn công không bao giờ chạm vào tenant.

Chuỗi mà các nhà nghiên cứu mô tả diễn ra theo năm bước:

• Kẻ tấn công gửi một lead qua endpoint Web-to-Lead công khai, với một prompt injection ẩn trong một trong các trường của lead đó. Nó trông giống như một yêu cầu hỏi thông thường.

• Lead cứ nằm đó cho đến khi một nhân viên hỏi agent của mình một điều gì đó hoàn toàn bình thường — ví dụ của Zenity là "kiểm tra các lead mới nhất của tôi và giúp tôi với lead mới nhất."

• Tác nhân đọc bản ghi bị đầu độc và làm theo các hướng dẫn bên trong đó, sử dụng công cụ Query Records mà tác nhân con General CRM mặc định đã có sẵn để truy vấn bảng Accounts. Zenity nói rõ rằng không cần leo thang đặc quyền: cùng tác nhân con đó được cung cấp quyền đọc đối với cả Leads và Accounts, và đó là các mặc định chứ không phải cấu hình sai.

• Nó ghi các giá trị mà nó đã truy xuất — trong ví dụ của các nhà nghiên cứu là tên công ty và quy mô thương vụ — vào tên miền con của một tên máy chủ do kẻ tấn công kiểm soát, rồi in kết quả trả lại cho người dùng dưới dạng thẻ hình ảnh HTML.

• Giao diện trò chuyện hiển thị các nguồn hình ảnh bên ngoài mà không qua bước làm sạch hay xác nhận, nên ứng dụng khách sẽ phân giải tên máy chủ. Dữ liệu thoát ra ngoài nằm trong chính truy vấn DNS.

Bước cuối cùng đó là phần đáng để chậm lại. Vì payload di chuyển trong truy vấn DNS, yêu cầu HTTP theo sau là không liên quan — nó có thể thất bại, hết thời gian chờ hoặc bị chặn hoàn toàn, và dữ liệu đã rời đi rồi. Zenity lưu ý rằng cách này vượt qua các kiểm soát lưu lượng HTTP ra ngoài. Một nhãn DNS đơn bị giới hạn ở 63 ký tự và tên đầy đủ ở 253 ký tự, vì vậy một lần gửi chỉ làm rò rỉ một phần nhỏ; các nhà nghiên cứu mô tả việc rút cạn toàn bộ bảng Accounts từng tài khoản một thông qua các yêu cầu lặp lại, đó là nguồn gốc của từ "bleed" trong tên gọi.

Có một lối thoát thứ hai thậm chí cần ít hơn: đối với các agent được xuất bản vào Slack, không cần thẻ hình ảnh. Slack biến URL thô thành bản xem trước và thu thập nội dung liên kết để tạo một bản, nên việc in URL ra là đủ để kích hoạt cùng một tra cứu DNS. SecurityWeek trích dẫn tóm tắt của Zenity về hành vi thu được: Slack khởi tạo các yêu cầu mang dữ liệu CRM đến hạ tầng do kẻ tấn công kiểm soát ngay khi các liên kết xuất hiện.

Zenity thận trọng về ý nghĩa của "zero-click" ở đây, và sự phân biệt này rất quan trọng. Nhân viên chỉ làm đúng một việc: hỏi agent của chính họ một câu hỏi bình thường về lead của chính họ. Họ không mở tệp đính kèm, không theo liên kết, cũng không tương tác với bất cứ thứ gì kẻ tấn công đã gửi. Mọi thứ sau câu hỏi đó đều diễn ra tự động. Lead độc hại cũng nằm trong bảng Leads như bất kỳ bản ghi nào khác, nên nó có thể kích hoạt lại mỗi khi một nhân viên xem xét nó — và kẻ tấn công muốn có kênh rộng hơn chỉ cần gửi thêm lead. SecurityWeek ghi nhận một chi tiết khiến thất bại còn rõ nét hơn: Agentforce báo cáo rằng nội dung đã bị chặn bởi chính sách bảo mật của tổ chức, mặc dù dữ liệu CRM đã đến được máy chủ của kẻ tấn công.

Tại sao bộ lọc Trusted URLs không giữ được

Trusted URLs là cơ chế kiểm soát của Salesforce được thiết kế để chặn chính xác điều này — nó giới hạn các đích bên ngoài mà Agentforce có thể truy cập và loại bỏ các liên kết và hình ảnh trỏ đến những tên miền chưa được ai phê duyệt. Zenity đã phát hiện hai trường hợp biên mà khi kết hợp lại, đã vượt qua nó một cách trót lọt.

Đầu tiên là tên miền cấp cao nhất. Công cụ che giấu chỉ nhận ra một danh sách TLD cố định, và .fun — tên miền được nền tảng kiểm thử ngoài băng app.interactsh.com sử dụng — không nằm trong danh sách đó. Một tên máy chủ kết thúc bằng TLD không được nhận diện có thể sẽ không được ghi nhận là tên máy chủ nào cả. Thứ hai là điểm kết thúc của URL: công cụ che giấu và giao diện hiển thị câu trả lời không thống nhất về các ký tự kết thúc, và dấu ngoặc nhọn cùng dấu ngoặc vuông nằm trong khoảng chênh lệch đó. Một chuỗi như https://random_string.oast.fun/{email} không phải là URI hợp lệ theo RFC 3986, nhưng nó vẫn tạo ra truy vấn DNS mà cuộc tấn công cần. Công cụ che giấu thấy một thứ không phải URL sai định dạng và bỏ qua nó; trình duyệt lại sẵn sàng tải nó về như một nguồn hình ảnh.

Một chi tiết cấu trúc đã khiến việc vượt qua có thể tinh chỉnh được. Việc che/xóa thông tin diễn ra sau khi agent đã tạo ra đầu ra, như một tiến trình riêng mà mô hình không biết gì về nó. Zenity phát hiện đầu ra thô của agent và phiên bản đã được che thông tin cùng xuất hiện trong các phản hồi gửi tới máy khách, điều này cho phép các nhà nghiên cứu so sánh hai bản và loại bỏ bất kỳ dị thường nào mà bộ lọc đang bắt được — chẳng hạn dấu ngoặc vuông trong một tên miền con — cho đến khi injection ổn định từ đầu đến cuối.

Dark Reading đưa tin rằng tính năng che giấu URL của Salesforce cho đến nay vẫn dựa vào việc khớp biểu thức chính quy để quyết định liệu một chuỗi có trông giống URL hay không, và chính điều này đã cho phép các tên miền bị ẩn dưới những định dạng bất thường. Công ty cho biết họ đã thay thế cách đó bằng phân tích cú pháp URL tuân thủ đặc tả, đồng thời hợp nhất việc kiểm tra URL để toàn bộ lưu lượng của tác nhân liên quan đến URL giờ đây đều đi qua một cổng duy nhất.

Lỗ hổng thứ ba: lừa đảo dưới danh nghĩa của chính tác nhân

Phát hiện về Slack, được công bố cùng ngày trong một bài đăng thứ hai do João Donato và các đồng nghiệp thực hiện, liên quan đến danh tính chứ không phải dữ liệu. Các tác nhân Agentforce có thể được xuất bản trực tiếp vào Slack, và các khả năng của chúng đến dưới dạng tác nhân phụ; Zenity lưu ý rằng mẫu Slack Knowledge bao gồm tất cả các hành động của nó, có thể được thêm chỉ với hai cú nhấp chuột.

Hầu hết các hành động ghi trên Slack mà các nhà nghiên cứu kiểm tra đều mang hai biện pháp bảo vệ: một bước xác nhận trước khi gửi, và thông tin ghi công người gọi cho người nhận biết yêu cầu của người dùng nào đã tạo ra tin nhắn. Gửi tin nhắn trực tiếp trên Slack đã làm cả hai. Trả lời một chuỗi trên Slack không làm cả hai. Sau khi Agentforce quyết định gọi hành động đó, tin nhắn được gửi đi mà không được phê duyệt và không có thông tin ghi công — nó mang danh tính của tác nhân và không có gì chỉ ngược về người đã yêu cầu nó.

Điều đó tạo ra hai đường tấn công. Một kẻ nội bộ độc hại vốn đã có thể trò chuyện với agent có thể đăng nội dung lừa đảo vào đúng chuỗi thảo luận rồi rời đi mà không để lại dấu vết nào truy ngược về mình, vì người nhận đọc nó như một tin nhắn từ agent. Kẻ tấn công bên ngoài cũng đạt kết quả tương tự qua thao tác chèn Web-to-Lead: lead bị đầu độc bảo agent trả lời vào các kênh Slack, và nó làm vậy mà không hỏi nhân viên đã kích hoạt nó. Việc vượt qua cơ chế che giấu URL từ bài đăng đầu tiên là thứ giúp liên kết lừa đảo sống sót qua quá trình lọc; sau đó Zenity phát hiện rằng các liên kết cũng có thể bị ẩn sau văn bản markdown trông vô hại. Cả Zenity và Salesforce đều mô tả hậu quả bằng cùng một cách: nhân viên nhận tin nhắn từ một hệ thống đáng tin cậy vốn đã đang vận hành bên trong nơi làm việc của họ, thay vì từ một người gửi bên ngoài xa lạ, và bất kỳ ai theo liên kết rồi giao nộp thông tin đăng nhập sẽ làm lộ email, Slack, kho mã nguồn và bất cứ thứ gì khác mà danh tính đó có thể truy cập.

Những gì đã được xác lập, và những gì chưa.

Bốn điều đã được xác định rõ qua các nguồn được xem xét ở đây. Zenity đã trình diễn các chuỗi tấn công và công bố video bằng chứng khái niệm. Salesforce thừa nhận phân tích này và mô tả những thay đổi mà họ đã thực hiện — trong các tuyên bố với Dark Reading và với SecurityWeek. Không có CVE nào được gán cho bất kỳ lỗ hổng nào trong ba lỗ hổng, điều mà Dark Reading cho là do các bản sửa lỗi được thực hiện ở phía Salesforce của một dịch vụ được lưu trữ chứ không phải trong phần mềm mà khách hàng vận hành. Và Salesforce tuyên bố rằng hiện tại họ không có bằng chứng nào cho thấy bất kỳ phần nào trong số đó đã bị khai thác nhằm vào một khách hàng.

Điều chưa được làm rõ là bất cứ điều gì liên quan đến quy mô. Không có nguồn nào được xem xét ở đây nêu rõ có bao nhiêu tenant Agentforce đã chạy các cấu hình mặc định bị ảnh hưởng, liệu có dữ liệu khách hàng nào thực sự rời khỏi môi trường của khách hàng hay không, hoặc liệu có ai ngoài Zenity Labs và Salesforce đã kiểm tra vấn đề này hay không. Các hãng tin độc lập — Dark Reading, SecurityWeek, Infosecurity Magazine và The Register — đều đưa tin về các phát hiện và đăng phản hồi của Salesforce, nhưng không bài đưa tin nào trong số đó cho biết họ đã tự tái hiện cuộc tấn công. Không có cuộc điều tra kỹ thuật độc lập thứ hai nào về SalesBleed và bài viết này không hàm ý có một cuộc điều tra như vậy.

Các nguồn của chính hồ sơ cũng không thống nhất về một chi tiết, theo cách đáng được nêu rõ thay vì làm mờ đi. Thông cáo báo chí của Zenity, được phân phối qua Business Wire vào ngày 24 tháng 9, nói rằng Salesforce đã xử lý các lỗ hổng vượt qua Trusted URLs cụ thể do Zenity báo cáo “trong khoảng hai tuần”. Dòng thời gian từng ngày trong bài viết kỹ thuật của Zenity kéo dài từ ngày 1 tháng 6, khi báo cáo được gửi, đến ngày 18 và 19 tháng 8, khi bản vá được xác nhận — gần mười một tuần. Cả hai tường thuật đều đến từ cùng một tổ chức.

Salesforce đã thay đổi những gì và khi nào

Quá trình tiết lộ kéo dài và, theo phía Zenity, diễn ra thân thiện. Các phát hiện đã được gửi tới Salesforce qua email vào ngày 1 tháng 6 năm 2026; Salesforce đã xác nhận chúng vào ngày hôm sau và cho biết đang xử lý các bản sửa lỗi; hai đội đã có một cuộc gọi kỹ thuật vào ngày 16 tháng 6; Salesforce đã đóng các hồ sơ tiết lộ vào ngày 17 tháng 6, lưu ý rằng nhóm kỹ thuật vẫn đang xử lý. Vào ngày 18 tháng 8, Salesforce đã xác nhận các bản sửa lỗi, và vào ngày 19 tháng 8, Zenity đã xác minh cụ thể việc vượt qua Trusted URLs. Việc ghi nhận nguồn trên hành động Slack đã được xác nhận là đã sửa vào ngày 20 tháng 8. Việc yêu cầu xác nhận theo mặc định mất nhiều thời gian hơn: vào ngày 25 tháng 8, Salesforce cho biết vẫn đang xử lý, vào ngày 10 tháng 9, công ty đưa ra ngày 21 tháng 9 làm mục tiêu, và vào ngày 21 tháng 9, Zenity đã kiểm tra và xác nhận cả ba.

Những thay đổi mà Salesforce mô tả rất cụ thể. Cài đặt mặc định cho một số hành động Agentforce nhất định trong Slack giờ đây yêu cầu người dùng xác nhận trước khi gửi tin nhắn, và công ty cho biết họ đang liên hệ trực tiếp với khách hàng để xem xét cấu hình của họ. Về Trusted URLs, việc đối sánh regex đã bị loại bỏ để thay bằng phân tích cú pháp tuân thủ đặc tả, và việc kiểm tra URL đã được hợp nhất vào một cổng duy nhất thay vì được xử lý tại nhiều điểm trong một quy trình làm việc.

Lời kết của Zenity về bản sửa lỗi Slack là một lưu ý thận trọng chứ không phải là tín hiệu hoàn toàn an toàn. Yêu cầu xác nhận chỉ là một cài đặt và chỉ mất một cú nhấp để tắt; sau khi tắt, cùng con đường tấn công lại có thể được sử dụng. Các nhà nghiên cứu khuyên các tổ chức đang xây dựng tác nhân nên theo dõi cách cấu hình các hành động ghi thay vì cho rằng mặc định vẫn được giữ nguyên.

Tại sao các nhà nghiên cứu nói rằng nó tổng quát hóa

Dù các chi tiết mang tính đặc thù của Salesforce, Zenity mô tả SalesBleed như một trường hợp của một khuôn mẫu. Bản tóm tắt của chính họ là bất kỳ tác nhân nào đọc các bản ghi do nguồn bên ngoài gửi vào, hiển thị liên kết hoặc hình ảnh trở lại cho người dùng, và đồng thời có quyền truy cập công cụ vào dữ liệu nhạy cảm đều có cùng ba thành phần ở cùng một vị trí. Các nhà nghiên cứu gọi sự kết hợp này là một phiên bản của bộ ba gây chết người — dữ liệu riêng tư, nội dung không đáng tin cậy và một kênh gửi ra hội tụ trong một danh tính.

Mô thức này đã có tiền lệ. Dark Reading đưa tin rằng một năm trước SalesBleed, các nhà nghiên cứu tại Noma Security đã sử dụng cùng tuyến Web-to-lead để tiếp cận dữ liệu Salesforce, và Salesforce đã phản ứng bằng cách siết chặt các quy tắc URL của mình — việc che giấu dựa trên regex mà sau đó Zenity đã lách qua. Một phát ngôn viên của Salesforce thừa nhận với Dark Reading rằng phản ứng trước đó là một bản vá nhanh chóng chứ không phải một giải pháp toàn diện, và cho biết lần này nhằm mục đích vững chắc hơn.

"Chúng tôi đã tìm ra nhiều cách để vượt qua ranh giới bảo mật được thiết kế nhằm ngăn Agentforce gửi dữ liệu doanh nghiệp đến những đích không được chấp thuận," Michael Bargury, đồng sáng lập kiêm giám đốc công nghệ của Zenity, cho biết trong thông cáo. "Các ranh giới cứng vẫn là một trong những công cụ mạnh nhất chúng ta có để kiểm soát các tác nhân AI, nhưng chúng vẫn chỉ là phần mềm. Khi những biện pháp kiểm soát đó thất bại, chúng ta chỉ còn lại một tác nhân có quyền truy cập đặc quyền với mức tự chủ cao và không có giới hạn." Tamir Ishay Sharbat, giám đốc nghiên cứu bảo mật của Zenity, đã nêu quan điểm rộng hơn với Dark Reading: tác nhân càng được trao nhiều quyền lực thì càng nguy hiểm, và một tác nhân có thể tự nhắn tin qua nhiều kênh đồng thời đọc hợp đồng, khách hàng tiềm năng hoặc các khoản phải trả là sự kết hợp sẽ bị lợi dụng. Bargury bổ sung mối lo thứ hai với cùng ấn phẩm — rằng các tác nhân đang được xây dựng như những hộp đen, với bản tóm tắt thay vì nhật ký, khiến việc xác định tác nhân đã làm gì hoặc tại sao trở nên khó khăn.

Điều có thể chuyển bản ghi này từ trình diễn sang sự cố không phải là một kỹ thuật mới mà là một mẩu bằng chứng: một tiết lộ từ khách hàng, một CVE, hoặc một tuyên bố từ Salesforce hoặc Zenity rằng các chuỗi đã được quan sát thấy đang được sử dụng. Không có điều nào trong số đó tồn tại trong các nguồn được xem xét ở đây. Cho đến khi có một điều như vậy, SalesBleed vẫn đứng như những gì kho lưu trữ ghi nhận về nó — một lỗ hổng có mức độ nghiêm trọng cao, được ghi nhận theo tiêu chuẩn độ tin cậy A bởi những người đã phát hiện ra nó và được nhà cung cấp xác nhận là đã được khắc phục, không có ghi nhận tác hại thực tế nào.