SalesBleed: Satu Lead Publik, Tiga Kelemahan Agentforce, Nol Klik

Pada 24 September 2026, Zenity Labsmenerbitkan riset yang disebutnya SalesBleed: tiga kerentanan dalam Salesforce Agentforce, platform milik vendor CRM tersebut untuk membangun dan menerapkan agen AI, yang memungkinkan orang asing menarik catatan pelanggan keluar dari org Salesforce sebuah perusahaan lalu menggunakan agen milik perusahaan itu sendiri untuk melakukan phishing terhadap stafnya. Dua dari tiga kerentanan itu tidak memerlukan klik dari siapa pun di dalam perusahaan. Paparan ini berlaku bagi tenant Agentforce yang menerima pengiriman Web-to-Lead, dan bagi agen apa pun yang telah diterbitkan tenant ke Slack. Dark Reading melaporkan bahwa tidak ada pengenal CVE yang ditetapkan, dan Salesforce mengatakan kepada media tersebut bahwa pihaknya tidak memiliki bukti eksploitasi terhadap pelanggan mana pun. Catatan lengkapnya, beserta tingkat keyakinan dan status kerugian milik arsip itu sendiri, terdapat dalam Orca AI Incident Archive, yang mencatat setiap insiden agen yang terdokumentasi terhadap sumber yang dikutipnya.

Bagaimana formulir prospek publik menjadi saluran data

Web-to-Lead adalah mekanisme resmi Salesforce untuk mengumpulkan lead, dan secara desain tidak terautentikasi — mekanisme ini ada agar siapa pun di internet dapat mengirimkan formulir dan isinya masuk ke CRM pelanggan. Postingan pertama Zenity, yang diatribusikan kepada Alex Apostolov dan rekan-rekannya, dibuka dengan hal itu sebagai satu-satunya syarat masuk: tidak ada akun untuk ditangguhkan, tidak ada sesi untuk dicabut, tidak ada peristiwa login untuk dideteksi. Penyerang tidak pernah menyentuh tenant.

Rantai yang dijelaskan para peneliti berjalan dalam lima langkah:

• Penyerang mengirimkan lead melalui endpoint Web-to-Lead publik, dengan injeksi prompt tersembunyi di salah satu kolomnya. Tampak seperti pertanyaan biasa.

• Prospek itu tetap ada di sana sampai seorang karyawan menanyakan sesuatu yang sepenuhnya biasa kepada agen mereka — contoh dari Zenity adalah "periksa prospek terbaru saya dan bantu saya dengan yang paling baru."

• Agen membaca catatan yang teracuni dan mengikuti instruksi di dalamnya, menggunakan tool Query Records yang dimiliki subagen default General CRM untuk melakukan kueri ke tabel Accounts. Zenity menegaskan bahwa tidak diperlukan eskalasi hak istimewa: subagen yang sama dilengkapi akses baca ke Leads dan Accounts, dan itu merupakan default, bukan kesalahan konfigurasi.

• Ia menuliskan nilai-nilai yang diambilnya — nama perusahaan dan ukuran kesepakatan, dalam contoh para peneliti — ke dalam subdomain dari nama host yang dikendalikan penyerang, dan menampilkan hasilnya kembali kepada pengguna sebagai tag gambar HTML.

• Antarmuka chat merender sumber gambar eksternal tanpa sanitasi atau langkah konfirmasi, sehingga klien me-resolve nama host. Data keluar di dalam kueri DNS.

Langkah terakhir itulah bagian yang perlu diperlambat. Karena payload ikut dalam lookup DNS, permintaan HTTP yang menyusul tidak relevan — bisa gagal, timeout, atau diblokir sepenuhnya, dan datanya sudah telanjur pergi. Zenity mencatat bahwa ini tetap lolos dari kontrol egress HTTP. Satu label DNS dibatasi 63 karakter dan nama lengkap 253 karakter, jadi satu pengiriman hanya membocorkan sepotong data; para peneliti menggambarkan pengurasan seluruh tabel Accounts satu akun setiap kali melalui permintaan berulang, dan dari situlah asal kata "bleed" dalam nama tersebut.

Ada jalur keluar kedua yang bahkan membutuhkan lebih sedikit: untuk agen yang dipublikasikan ke Slack, tidak diperlukan tag gambar. Slack mengubah URL mentah menjadi pratinjau dan merayapi tautan tersebut untuk membuatnya, jadi cukup menampilkan URL untuk memicu pencarian DNS yang sama. SecurityWeek mengutip ringkasan Zenity tentang perilaku yang dihasilkan: Slack memulai permintaan yang membawa data CRM ke infrastruktur yang dikendalikan penyerang segera setelah tautan tersebut muncul.

Zenity berhati-hati soal apa yang dimaksud dengan "zero-click" di sini, dan perbedaannya penting. Karyawan tersebut melakukan tepat satu hal: mengajukan pertanyaan biasa kepada agen mereka sendiri tentang prospek milik mereka sendiri. Mereka tidak membuka lampiran, mengikuti tautan, atau berinteraksi dengan apa pun yang dikirim penyerang. Semua yang terjadi setelah pertanyaan itu berjalan otomatis. Prospek berbahaya itu juga tetap berada di tabel Leads seperti catatan lainnya, sehingga bisa terpicu lagi setiap kali seorang karyawan meninjaunya — dan penyerang yang menginginkan saluran lebih luas cukup mengirimkan lebih banyak prospek. SecurityWeek mencatat sebuah detail yang membuat kegagalan ini makin tajam: Agentforce melaporkan bahwa konten tersebut telah diblokir oleh kebijakan keamanan organisasi, padahal data CRM sudah sampai ke server penyerang.

Mengapa filter Trusted URLs tidak bertahan

Trusted URLs adalah kontrol Salesforce yang dimaksudkan untuk mencegah hal ini secara tepat — kontrol ini membatasi tujuan eksternal yang dapat dijangkau Agentforce dan menghapus tautan serta gambar yang mengarah ke domain yang belum disetujui siapa pun. Zenity menemukan dua kasus tepi yang, jika digabungkan, langsung menembus kontrol tersebut.

Yang pertama adalah domain tingkat atas. Redactor hanya mengenali daftar TLD tetap, dan .fun — domain yang digunakan oleh platform pengujian out-of-band app.interactsh.com — tidak ada di dalamnya. Nama host yang berakhiran TLD tak dikenal mungkin tidak dikenali sebagai nama host sama sekali. Yang kedua adalah tempat sebuah URL berakhir: redactor dan antarmuka yang merender jawaban tidak sepakat tentang karakter terminasi, dan kurung kurawal serta kurung siku berada di celah tersebut. String seperti https://random_string.oast.fun/{email} bukan URI yang valid menurut RFC 3986, namun tetap menghasilkan kueri DNS yang dibutuhkan oleh serangan tersebut. Redactor melihat non-URL yang cacat dan membiarkannya; browser bersedia mengambilnya sebagai sumber gambar.

Satu detail struktural membuat bypass dapat disetel. Penyensoran berjalan setelah agen menghasilkan keluarannya, sebagai proses terpisah yang tidak diketahui model. Zenity menemukan keluaran mentah agen dan versi tersensor sama-sama ada dalam respons yang dikirim ke klien, yang memungkinkan para peneliti membandingkan keduanya dan menghapus anomali apa pun yang ditangkap filter — tanda kurung siku di subdomain, misalnya — sampai injeksi stabil dari ujung ke ujung.

Dark Reading melaporkan bahwa penyuntingan URL Salesforce hingga kini mengandalkan pencocokan ekspresi reguler untuk menentukan apakah suatu string tampak seperti URL, itulah yang memungkinkan domain disembunyikan dalam format tak terduga. Perusahaan mengatakan telah menggantinya dengan penguraian URL yang sesuai spesifikasi, dan telah menyatukan pemeriksaan URL sehingga semua lalu lintas agen terkait URL kini melewati satu gateway.

Kelemahan ketiga: phishing atas nama agen itu sendiri

Temuan Slack, yang diterbitkan pada hari yang sama dalam posting kedua yang dikreditkan kepada João Donato dan rekan-rekannya, adalah tentang identitas, bukan data. Agen Agentforce dapat diterbitkan langsung ke Slack, dan kemampuan mereka hadir sebagai subagen; Zenity mencatat bahwa Slack Knowledge templat, termasuk semua aksinya, dapat ditambahkan dalam dua klik.

Sebagian besar tindakan penulisan Slack yang diperiksa peneliti memiliki dua perlindungan: langkah konfirmasi sebelum mengirim, dan atribusi pemanggil yang memberi tahu penerima permintaan pengguna mana yang menyebabkan pesan itu. Send a Slack Direct Message melakukan keduanya. Reply to a Slack Thread tidak melakukan keduanya. Begitu Agentforce memutuskan untuk memanggil tindakan itu, pesan terkirim tanpa persetujuan dan tanpa atribusi — pesan itu membawa identitas agen dan tidak ada yang mengarah kembali ke siapa pun yang memintanya.

Hal itu menghasilkan dua jalur serangan. Orang dalam yang beritikad buruk yang sudah dapat mengobrol dengan agen tersebut dapat mengirim phishing ke thread yang tepat lalu pergi tanpa meninggalkan jejak apa pun yang menghubungkannya, karena penerima membacanya sebagai pesan dari agen. Penyerang eksternal memperoleh hasil yang sama melalui injeksi Web-to-Lead: lead yang telah teracuni memerintahkan agen untuk membalas ke kanal Slack, dan agen melakukannya tanpa bertanya kepada karyawan yang memicunya. Bypass redaksi URL dari pos pertama itulah yang membuat tautan phishing lolos dari penyaringan; Zenity kemudian menemukan bahwa tautan juga dapat disembunyikan di balik teks markdown yang tampak tidak berbahaya. Zenity dan Salesforce sama-sama merumuskan konsekuensinya dengan istilah yang sama: karyawan menerima pesan dari sistem tepercaya yang sudah beroperasi di dalam tempat kerja mereka, bukan dari pengirim luar yang tidak dikenal, dan siapa pun yang mengikuti tautan tersebut serta menyerahkan kredensial akan mengekspos email, Slack, repositori kode sumber, dan apa pun yang dapat dijangkau oleh identitas itu.

Apa yang sudah mapan, dan apa yang belum

Empat hal telah dipastikan di seluruh sumber yang ditinjau di sini. Zenity mendemonstrasikan rantai serangan dan menerbitkan video proof of concept. Salesforce mengakui analisis tersebut dan menjelaskan perubahan yang dilakukannya — dalam pernyataan kepada Dark Reading dan SecurityWeek. Tidak ada CVE yang ditetapkan untuk salah satu dari tiga celah tersebut, yang menurut Dark Reading disebabkan oleh perbaikan yang dilakukan di sisi Salesforce pada layanan yang dihosting, bukan pada perangkat lunak yang dijalankan pelanggan. Dan Salesforce menyatakan bahwa saat ini pihaknya tidak memiliki bukti bahwa salah satu dari hal tersebut dieksploitasi terhadap pelanggan.

Yang belum tuntas adalah segala hal tentang skala. Tidak ada sumber yang ditinjau di sini yang menyatakan berapa banyak tenant Agentforce yang menjalankan default yang terdampak, apakah ada data pelanggan yang benar-benar keluar dari lingkungan pelanggan, atau apakah ada pihak di luar Zenity Labs dan Salesforce yang mencarinya. Media independen — Dark Reading, SecurityWeek, Infosecurity Magazine, dan The Register — masing-masing melaporkan temuan tersebut dan memuat respons Salesforce, tetapi tidak ada liputan tersebut yang melaporkan upaya mereka sendiri untuk mereproduksi serangan itu. Tidak ada investigasi teknis independen kedua atas SalesBleed, dan artikel ini tidak menyiratkan adanya investigasi tersebut.

Sumber-sumber catatan itu sendiri juga tidak sepakat soal satu detail, dengan cara yang layak disebutkan alih-alih dihaluskan. Siaran pers Zenity, yang didistribusikan melalui Business Wire pada 24 September, menyatakan bahwa Salesforce menangani bypass Trusted URLs spesifik yang dilaporkan Zenity “dalam sekitar dua minggu.” Linimasa hari demi hari dalam postingan teknis Zenity berjalan dari 1 Juni, saat laporan dikirim, hingga 18 dan 19 Agustus, saat perbaikan dikonfirmasi — lebih mendekati sebelas minggu. Kedua keterangan itu berasal dari organisasi yang sama.

Apa yang diubah Salesforce, dan kapan

Pengungkapan itu berlangsung lama dan, menurut keterangan Zenity, berlangsung dengan ramah. Temuan tersebut dikirim ke Salesforce melalui email pada {{1}}1 Juni 2026{{/1}}; Salesforce mengonfirmasinya keesokan harinya dan mengatakan sedang mengerjakan perbaikannya; kedua tim mengadakan panggilan teknis pada {{2}}16 Juni{{/2}}; Salesforce menutup pengungkapan tersebut pada {{3}}17 Juni{{/3}} dengan mencatat bahwa tim engineering masih mengerjakannya. Pada {{4}}18 Agustus{{/4}} Salesforce mengonfirmasi perbaikannya, dan pada {{5}}19 Agustus{{/5}} Zenity memverifikasi secara khusus bypass Trusted URLs. Atribusi pada aksi Slack dikonfirmasi telah diperbaiki pada {{6}}20 Agustus{{/6}}. Mewajibkan konfirmasi secara default memakan waktu lebih lama: pada {{7}}25 Agustus{{/7}} Salesforce mengatakan masih mengerjakannya, pada {{8}}10 September{{/8}} pihaknya menetapkan {{9}}21 September{{/9}} sebagai target, dan pada {{10}}21 September{{/10}} Zenity menguji dan mengonfirmasi ketiganya.

Perubahan yang dijelaskan Salesforce bersifat spesifik. Pengaturan default untuk tindakan Agentforce tertentu di Slack kini mewajibkan konfirmasi pengguna sebelum pesan dikirim, dan perusahaan mengatakan pihaknya menghubungi pelanggan secara langsung untuk meninjau konfigurasi mereka. Pada Trusted URLs, pencocokan regex sudah tidak ada dan digantikan oleh penguraian yang sesuai spesifikasi, serta inspeksi URL telah dikonsolidasikan ke dalam satu gateway alih-alih ditangani di beberapa titik dalam alur kerja.

Catatan penutup Zenity tentang perbaikan Slack itu merupakan sebuah peringatan, bukan lampu hijau. Persyaratan konfirmasi hanyalah sebuah pengaturan, dan cukup satu klik untuk mematikannya; begitu dimatikan, jalur serangan yang sama kembali tersedia. Saran para peneliti kepada organisasi yang membangun agen adalah memperhatikan bagaimana tindakan tulis dikonfigurasi, bukan mengasumsikan bahwa pengaturan bawaan akan tetap berlaku.

Mengapa para peneliti mengatakan bahwa hal itu dapat digeneralisasi

Meskipun detailnya spesifik untuk Salesforce, Zenity membingkai SalesBleed sebagai salah satu contoh dari suatu pola. Ringkasannya sendiri adalah bahwa agen mana pun yang membaca catatan yang dikirim oleh sumber eksternal, menampilkan tautan atau gambar kembali kepada pengguna, dan juga memiliki akses alat ke data sensitif memiliki tiga bahan yang sama di tempat yang sama. Para peneliti menyebut kombinasi itu sebagai versi trifecta mematikan — data privat, konten tidak tepercaya, dan saluran keluar yang bertemu dalam satu identitas.

Pola ini punya sejarah lokal. Dark Reading melaporkan bahwa setahun sebelum SalesBleed, para peneliti di Noma Security menggunakan jalur Web-to-lead yang sama untuk menjangkau data Salesforce, dan bahwa Salesforce merespons dengan memperketat aturan URL-nya — penyuntingan berbasis regex yang kemudian diakali oleh Zenity. Juru bicara Salesforce mengakui kepada Dark Reading bahwa respons sebelumnya adalah perbaikan cepat, bukan solusi menyeluruh, dan mengatakan bahwa respons kali ini dimaksudkan agar lebih tangguh.

"Kami menemukan berbagai cara untuk menembus batas keamanan yang dirancang untuk menghentikan Agentforce mengirim data perusahaan ke tujuan yang tidak disetujui," kata Michael Bargury, salah satu pendiri dan chief technology officer Zenity, dalam rilis tersebut. "Batas yang keras tetap menjadi salah satu alat terkuat yang kita miliki untuk membatasi agen AI, tetapi itu tetap perangkat lunak. Ketika kontrol tersebut gagal, kita dihadapkan pada agen akses istimewa dengan otonomi tinggi dan tanpa batas." Tamir Ishay Sharbat, direktur riset keamanan Zenity, menyampaikan poin yang lebih luas kepada Dark Reading: semakin besar kekuatan yang diberikan kepada agen, semakin berbahaya agen itu, dan agen yang dapat mengirim pesan ke berbagai saluran dengan sendirinya sekaligus membaca kontrak, prospek, atau utang usaha adalah kombinasi yang akan disalahgunakan. Bargury menambahkan kekhawatiran kedua kepada media yang sama — bahwa agen dibangun sebagai kotak hitam, dengan ringkasan alih-alih log, sehingga sulit untuk mengetahui apa yang dilakukan agen atau mengapa.

Yang akan memindahkan catatan ini dari demonstrasi menjadi insiden bukanlah teknik baru, melainkan sepotong bukti: pengungkapan dari pelanggan, CVE, atau pernyataan dari Salesforce atau Zenity bahwa rantai tersebut terlihat digunakan. Tidak satu pun dari itu ada dalam sumber yang ditinjau di sini. Sampai ada, SalesBleed tetap seperti yang dicatat oleh arsip — kerentanan dengan tingkat keparahan tinggi, didokumentasikan dengan standar keyakinan A oleh orang-orang yang menemukannya dan dikonfirmasi telah diperbaiki oleh vendor, tanpa kerugian dunia nyata yang tercatat.