SalesBleed: один публичный лид, три изъяна Agentforce, ноль кликов

24 сентября 2026 года Zenity Labsопубликовала исследование, которое называет SalesBleed: три уязвимости в Salesforce Agentforce— платформе CRM-вендора для создания и развёртывания ИИ-агентов, — которые позволяют постороннему извлечь записи клиентов из Salesforce-орга компании, а затем использовать собственный агент этой компании для фишинга её сотрудников. Две из трёх не требуют ни одного клика от кого-либо внутри компании. Уязвимость затрагивает тенантов Agentforce, принимающих заявки Web-to-Lead, а также любого агента, которого тенант опубликовал в Slack. Dark Reading сообщает, что идентификаторы CVE не присвоены, а Salesforce заявила изданию, что у неё нет доказательств эксплуатации против какого-либо клиента. Полная запись со степенью уверенности и статусом вреда, присвоенными самим архивом, находится в Orca AI Incident Archive, где каждый задокументированный инцидент с агентами фиксируется вместе с указанными источниками.

Как публичная форма сбора лидов становится каналом данных

Web-to-Lead — официальный механизм Salesforce для сбора лидов, и по своей архитектуре он не требует аутентификации: он существует для того, чтобы любой пользователь интернета мог отправить форму, а её содержимое попало в CRM клиента. Первый пост Zenity, авторство которого приписано Алексу Апостолову и коллегам, начинается с того, что это и есть всё условие входа: нет аккаунта, который нужно приостановить, нет сессии, которую нужно отозвать, нет события входа, которое нужно обнаружить. Злоумышленник вообще не касается тенанта.

Цепочка, которую описывают исследователи, состоит из пяти шагов:

• Злоумышленник отправляет лид через публичную конечную точку Web-to-Lead, встроив в одно из её полей скрытую prompt-инъекцию. Это выглядит как обычный запрос.

• Лид лежит там, пока сотрудник не попросит своего агента сделать что-то совершенно обычное — пример от Zenity: «проверь мои последние лиды и помоги мне с самым новым».

• Агент читает отравленную запись и следует инструкциям внутри неё, используя инструмент Query Records, который есть у штатного General CRM субагента и уже применяется для запроса таблицы Accounts. Zenity прямо указывает, что повышение привилегий не требовалось: тот же субагент поставляется с доступом на чтение к обеим таблицам — Leads и Accounts, — а это настройки по умолчанию, а не ошибки конфигурации.

• Он записывает полученные значения — название компании и размер сделки в примере исследователей — в поддомен имени хоста, контролируемого злоумышленником, и выводит результат обратно пользователю в виде HTML-тега изображения.

• Интерфейс чата отображает внешние источники изображений без санитизации или этапа подтверждения, поэтому клиент разрешает имя хоста. Данные уходят внутри DNS-запроса.

Именно на последнем шаге стоит замедлиться. Поскольку полезная нагрузка передаётся в DNS-запросе, последующий HTTP-запрос не имеет значения — он может завершиться ошибкой, превысить тайм-аут или быть полностью заблокирован, а данные уже ушли. {{1}}Zenity отмечает, что это работает даже при контроле исходящего HTTP-трафика.{{/1}} Один DNS-лейбл ограничен 63 символами, а полное имя — 253, поэтому при одной отправке утекает лишь фрагмент; исследователи описывают выкачивание всей таблицы Accounts по одной учётной записи за раз через повторяющиеся запросы — отсюда и «bleed» в названии.{{2}}

Есть второй канал утечки, требующий ещё меньшего: для агентов, опубликованных в Slack, тег изображения не нужен. Slack превращает необработанные URL в превью и сканирует ссылку, чтобы построить его, поэтому вывода URL достаточно, чтобы запустить тот же DNS-запрос. SecurityWeek цитирует резюме Zenity о поведении, к которому это приводит: Slack инициирует запросы, несущие данные CRM, к инфраструктуре, контролируемой злоумышленником, как только ссылки появляются.

Zenity осторожно относится к тому, что здесь означает «zero-click», и это различие важно. Сотрудник делает ровно одну вещь: задаёт своему агенту обычный вопрос о собственных лидах. Он не открывает вложение, не переходит по ссылке и не взаимодействует ни с чем, что отправил злоумышленник. Всё после этого вопроса происходит автоматически. Вредоносный лид также остаётся в таблице Leads, как и любая другая запись, поэтому он может сработать снова каждый раз, когда сотрудник просматривает её, — а злоумышленник, которому нужен более широкий канал, может просто отправить больше лидов. SecurityWeek фиксирует деталь, которая делает провал ещё более резким: Agentforce сообщил, что содержимое было заблокировано политиками безопасности организации, хотя данные CRM уже достигли сервера злоумышленника.

Почему фильтр Trusted URLs не сработал

Доверенные URL — это механизм контроля Salesforce, предназначенный именно для этого: он ограничивает внешние адресаты, к которым может обращаться Agentforce, и удаляет ссылки и изображения, указывающие на домены, которые никто не утвердил. Zenity обнаружила два граничных случая, которые в сочетании позволили обойти его напрямую.

Первым был домен верхнего уровня. Редактор распознавал только фиксированный список TLD, и .fun — домен, используемый платформой внеполосного тестирования app.interactsh.com, — в нём отсутствовал. Имя хоста, оканчивающееся на нераспознанный TLD, могло вообще не распознаваться как имя хоста. Вторым был вопрос о том, где заканчивается URL: редактор и интерфейс, отображающий ответ, расходились в отношении символов завершения, и фигурные и квадратные скобки оказывались в этом промежутке. Строка вида https://random_string.oast.fun/{email} не является допустимым URI по RFC 3986, но всё равно порождает DNS-запрос, необходимый атаке. Редактор видел некорректный не-URL и не трогал его; браузер был готов загрузить его как источник изображения.

Одна структурная деталь сделала обход настраиваемым. Редактирование выполняется после того, как агент сгенерировал свой вывод, как отдельный процесс, о котором модель ничего не знает. Zenity обнаружила, что необработанный вывод агента и отредактированная версия оба присутствуют в ответах, отправленных клиенту, что позволило исследователям сравнить их и удалить все аномалии, которые отлавливал фильтр — например, квадратные скобки в поддомене — до тех пор, пока внедрение не стало стабильным от начала до конца.

Dark Reading сообщает, что функция Salesforce по маскированию URL до сих пор полагалась на сопоставление с регулярными выражениями, чтобы определить, похожа ли строка на URL, — именно это позволяло скрывать домены в неожиданных форматах. Компания заявляет, что заменила этот подход на синтаксический разбор URL в соответствии со спецификацией и объединила проверку URL, так что теперь весь связанный с URL трафик агентов проходит через единый шлюз.

Третий изъян: фишинг под собственным именем агента

Открытие, связанное со Slack, опубликованное в тот же день во втором посте, приписываемом Жуану Донату и коллегам, касается идентичности, а не данных. Агентов Agentforce можно публиковать непосредственно в Slack, а их возможности поступают в виде субагентов; Zenity отмечает, что шаблон Slack Knowledge, включая все его действия, можно добавить двумя щелчками.

Большинство действий записи в Slack, которые изучили исследователи, имели две защиты: этап подтверждения перед отправкой и указание инициатора, сообщающее получателям, чей запрос пользователя вызвал сообщение. Отправить личное сообщение в Slack делало и то и другое. Ответить в ветке Slack не делало ни того, ни другого. Как только Agentforce решал вызвать это действие, сообщение отправлялось без одобрения и без указания инициатора — оно несло идентичность агента и ничего, что указывало бы на того, кто его запросил.

Это породило два пути атаки. Злонамеренный инсайдер, который уже может общаться с агентом, способен разместить фишинговое сообщение в нужной ветке и уйти, не оставив следов, указывающих на него, поскольку получатели воспринимают это как сообщение от агента. Внешний злоумышленник добивается того же результата через инъекцию Web-to-Lead: отравленный лид указывает агенту отвечать в каналы Slack, и тот делает это, не спрашивая сотрудника, запустившего его. Именно обход редактирования URL из первого поста позволяет фишинговой ссылке пройти фильтрацию; позже Zenity обнаружила, что ссылки можно также скрывать за безобидно выглядящим текстом Markdown. Zenity и Salesforce одинаково описывают последствие: сотрудники получают сообщение от доверенной системы, уже работающей в их рабочей среде, а не от незнакомого внешнего отправителя, и любой, кто переходит по ссылке и передаёт учётные данные, подвергает раскрытию электронную почту, Slack, репозитории исходного кода и всё остальное, до чего может добраться эта учётная запись.

Что установлено, а что — нет

Четыре обстоятельства установлены по рассмотренным здесь источникам. Zenity продемонстрировала цепочки атак и опубликовала видеоролик с доказательством концепции. Salesforce признает анализ и описывает внесенные изменения — в заявлениях для Dark Reading и SecurityWeek. Ни одной из трех уязвимостей не был присвоен CVE; Dark Reading объясняет это тем, что исправления были сделаны на стороне Salesforce как поставщика хостинговой услуги, а не в программном обеспечении, которое используют клиенты. И Salesforce заявляет, что на данный момент у компании нет доказательств того, что что-либо из этого эксплуатировалось против какого-либо клиента.

Что остаётся невыясненным — это всё, что касается масштаба. Ни один из рассмотренных здесь источников не указывает, сколько арендаторов Agentforce использовали затронутые настройки по умолчанию, действительно ли какие-либо данные клиентов покидали среду клиента и искал ли это кто-либо за пределами Zenity Labs и Salesforce. Независимые издания — Dark Reading, SecurityWeek, Infosecurity Magazine и The Register — каждое сообщило о находках и привело ответ Salesforce, но ни в одной из этих публикаций не сообщается о собственном воспроизведении атаки. Второго независимого технического расследования SalesBleed не существует, и данная статья не подразумевает его наличия.

Источники, на которые опирается сам материал, тоже расходятся в одной детали — и это расхождение стоит назвать, а не сглаживать. В пресс-релизе Zenity, распространённом через Business Wire 24 сентября, говорится, что Salesforce устранила конкретные обходы Trusted URLs, о которых сообщила Zenity, «примерно за две недели». Хронология по дням в технической публикации Zenity охватывает период с 1 июня, когда был отправлен отчёт, по 18 и 19 августа, когда исправление было подтверждено, — ближе к одиннадцати неделям. Оба описания исходят от одной и той же организации.

Что Salesforce изменила и когда

{{1}}Раскрытие информации затянулось и, по словам Zenity, прошло в дружелюбной обстановке.{{/1}} {{2}}Результаты были отправлены в Salesforce по электронной почте 1 июня 2026 года; Salesforce подтвердила их на следующий день и сообщила, что работает над исправлениями; две команды провели технический звонок 16 июня; Salesforce закрыла раскрытия 17 июня, отметив, что инженерный отдел всё ещё работает.{{/2}} {{3}}18 августа Salesforce подтвердила исправления, а 19 августа Zenity отдельно проверила обход Trusted URLs.{{/3}} {{4}}Исправление атрибуции для действия в Slack было подтверждено 20 августа.{{/4}} {{5}}Введение обязательного подтверждения по умолчанию заняло больше времени: 25 августа Salesforce сообщила, что всё ещё работает над этим, 10 сентября она назвала целевой датой 21 сентября, а 21 сентября Zenity протестировала и подтвердила все три.{{/5}}

Описываемые Salesforce изменения конкретны. Настройки по умолчанию для некоторых действий Agentforce в Slack теперь требуют подтверждения пользователя перед отправкой сообщения, и компания говорит, что напрямую связывается с клиентами для проверки их конфигураций. В Trusted URLs сопоставление с регулярными выражениями убрано в пользу разбора, соответствующего спецификации, а проверка URL была объединена в один шлюз, вместо того чтобы выполняться в нескольких точках рабочего процесса.

Заключительное замечание Zenity к исправлению Slack — это скорее оговорка, чем сигнал «всё чисто». Требование подтверждения — это настройка, и на её отключение хватает одного клика; как только она отключена, тот же путь атаки снова становится доступен. Совет исследователей организациям, разрабатывающим агентов, — следить за тем, как настроены действия записи, а не полагаться на то, что настройки по умолчанию сохранятся.

Почему исследователи говорят, что это обобщается

Насколько бы специфичными для Salesforce ни были детали, Zenity представляет SalesBleed как частный случай паттерна. В собственном резюме компании говорится, что любой агент, который читает записи, поступающие из внешних источников, отображает пользователю ссылки или изображения, а также имеет доступ к инструментам с чувствительными данными, содержит те же три компонента в одном и том же месте. Исследователи называют такое сочетание вариантом «смертельной трифекты» — приватные данные, недоверенный контент и исходящий канал, сходящиеся в одной идентичности.

У этой схемы уже есть предыстория. Dark Reading сообщает, что за год до SalesBleed исследователи из Noma Security использовали тот же маршрут Web-to-lead, чтобы добраться до данных Salesforce, и что Salesforce ответила ужесточением правил для URL — тем самым сокрытием на основе регулярных выражений, которое затем обошла Zenity. Представитель Salesforce признал в беседе с Dark Reading, что предыдущий ответ был быстрым исправлением, а не комплексным, и заявил, что нынешний должен быть более надежным.

«Мы нашли несколько способов обойти границу безопасности, предназначенную для того, чтобы не дать Agentforce отправлять корпоративные данные в неутверждённые места назначения», — говорит в пресс-релизе Майкл Баргури, соучредитель и технический директор Zenity. «Жёсткие границы остаются одним из самых мощных инструментов для сдерживания ИИ-агентов, но они всё ещё программные. Когда эти средства контроля отказывают, у нас остаётся агент с привилегированным доступом, высокой автономностью и без границ». Тамир Ишай Шарбат, директор Zenity по исследованиям в области безопасности, изложил более широкую мысль Dark Reading: чем больше полномочий дано агенту, тем он опаснее, а агент, который сам может рассылать сообщения по нескольким каналам и при этом читать договоры, лиды или кредиторскую задолженность, — это комбинация, которую будут злоупотреблять. Баргури добавил вторую озабоченность тому же изданию — что агенты создаются как чёрные ящики, со сводками вместо журналов, из-за чего трудно понять, что сделал агент или почему.

Что перевело бы эту запись из демонстрации в инцидент — это не новая техника, а доказательство: раскрытие информации клиентом, CVE или заявление Salesforce или Zenity о том, что эти цепочки были замечены в реальном использовании. Ничего из этого нет в рассмотренных здесь источниках. Пока такого доказательства не появится, SalesBleed остаётся тем, чем его фиксирует архив, — уязвимостью высокой степени опасности, задокументированной с достоверностью уровня A теми, кто её обнаружил, и подтверждённой производителем как исправленная, без зафиксированного реального ущерба.