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 الأول، المنسوب إلى Alex Apostolov وزملائه، بهذا كشرط الدخول بأكمله: لا حساب لتعليقه، ولا جلسة لإبطالها، ولا حدث تسجيل دخول لاكتشافه. لا يلمس المهاجم المستأجر أبدًا.

تسير السلسلة التي يصفها الباحثون في خمس خطوات:

• يرسل المهاجم عميلاً محتملاً عبر نقطة نهاية Web-to-Lead العامة، مع حقن أوامر مخفي في أحد حقوله. يبدو كاستفسار عادي.

• يظل العميل المحتمل هناك حتى يطلب الموظف من وكيله شيئًا عاديًا تمامًا — مثال Zenity هو "تحقق من أحدث عملائي المحتملين وساعدني في الأحدث."

• يقرأ الوكيل السجل المسموم ويتّبع التعليمات الموجودة داخله، باستخدام أداة Query Records التي يملكها بالفعل الوكيل الفرعي الافتراضي General CRM للاستعلام عن جدول Accounts. ويوضّح Zenity صراحةً أنه لم تكن هناك حاجة إلى تصعيد امتيازات: فالوكيل الفرعي نفسه يأتي بصلاحية قراءة لكل من Leads وAccounts، وهذه إعدادات افتراضية وليست أخطاء تهيئة.

• يكتب القيم التي استرجعها — اسم شركة وحجم صفقة، في مثال الباحثين — داخل النطاق الفرعي لاسم مضيف يتحكم به المهاجم، ثم يطبع النتيجة للمستخدم كوسم صورة HTML.

• تعرض واجهة الدردشة مصادر الصور الخارجية دون تنقية أو خطوة تأكيد، لذا يحل العميل اسم المضيف. وتغادر البيانات ضمن استعلام DNS.

تلك الخطوة الأخيرة هي الجزء الذي يستحق التمهل عنده. لأن الحمولة تنتقل داخل استعلام DNS، فإن طلب HTTP الذي يليه لا أهمية له — فقد يفشل أو تنتهي مهلته أو يُحجب كليًا، بينما تكون البيانات قد خرجت بالفعل. تشير Zenity إلى أن هذا يظل فعالًا رغم ضوابط الخروج عبر HTTP. يُحدّ طول تسمية DNS الواحدة بحد أقصى 63 حرفًا والاسم الكامل بـ253، لذا فإن كل إرسال يسرب شريحة واحدة؛ ويصف الباحثون استنزاف جدول Accounts بأكمله حسابًا واحدًا في كل مرة عبر طلبات متكررة، ومن هنا يأتي "bleed" في الاسم.

هناك منفذ ثانٍ يحتاج إلى قدر أقل: بالنسبة إلى الوكلاء المنشورين في Slack، لا يلزم وسم صورة. يحوّل Slack عناوين URL الخام إلى معاينات ويزحف إلى الرابط لإنشاء معاينة، لذا يكفي طباعة عنوان URL لتحفيز استعلام DNS نفسه. تنقل SecurityWeek ملخّص Zenity للسلوك الناتج: يبدأ Slack في إرسال طلبات تحمل بيانات CRM إلى بنية تحتية يتحكم فيها المهاجم بمجرد ظهور الروابط.

تتوخى Zenity الحذر في ما يعنيه «zero-click» هنا، والتمييز مهم. يفعل الموظف شيئًا واحدًا فقط: يسأل وكيله الخاص سؤالًا عاديًا عن عملائه المحتملين. وهو لا يفتح مرفقًا، ولا يتبع رابطًا، ولا يتفاعل مع أي شيء أرسله المهاجم. وكل ما يحدث بعد ذلك السؤال تلقائي. كما يبقى العميل المحتمل الخبيث في جدول العملاء المحتملين مثل أي سجل آخر، لذا يمكن أن ينشط مجددًا في كل مرة يراجعه فيها موظف — والمهاجم الذي يريد قناة أوسع يمكنه ببساطة إرسال المزيد من العملاء المحتملين. وتوثّق SecurityWeek تفصيلًا يجعل الفشل أكثر حدّة: فقد أفادت Agentforce بأن المحتوى قد جرى حظره بموجب سياسات الأمان لدى المؤسسة، رغم أن بيانات CRM كانت قد وصلت بالفعل إلى خادم المهاجم.

لماذا لم يصمد عامل التصفية Trusted URLs

عناوين URL الموثوقة هو عنصر التحكم في Salesforce المصمم لإيقاف هذا تحديدًا — فهو يقيّد الوجهات الخارجية التي يمكن لـ Agentforce الوصول إليها، ويزيل الروابط والصور التي تشير إلى نطاقات لم يوافق عليها أحد. اكتشفت Zenity حالتين حافيتين، تجاوزتا معًا هذا التحكم مباشرةً.

كان الأول هو النطاق الأعلى مستوى. كانت أداة التنقيح تتعرف فقط على قائمة ثابتة من النطاقات الأعلى مستوى، ولم يكن .fun — النطاق الذي تستخدمه منصة الاختبار خارج النطاق app.interactsh.com — ضمنها. وقد لا يُسجَّل اسم مضيف ينتهي بنطاق أعلى مستوى غير معروف اسمَ مضيف على الإطلاق. وكان الثاني هو موضع انتهاء عنوان URL: اختلفت أداة التنقيح والواجهة التي تعرض الإجابة حول محارف الإنهاء، وكانت الأقواس المعقوفة والأقواس المربعة تقع في الفجوة. إن سلسلة مثل https://random_string.oast.fun/{email} ليست URI صالحًا بموجب RFC 3986، ومع ذلك فهي لا تزال تُنتج استعلام DNS الذي يحتاجه الهجوم. رأت أداة التنقيح غير-URL مشوّهًا وتركته كما هو؛ بينما كان المتصفح على استعداد لجلبه كمصدر لصورة.

جعل تفصيل بنيوي واحد التجاوز قابلاً للضبط. تتم التنقية بعد أن يولّد الوكيل مخرجاته، كعملية منفصلة لا يعرف النموذج شيئًا عنها. اكتشفت Zenity أن المخرجات الخام للوكيل والنسخة المنقّحة موجودتان معًا في الردود المرسلة إلى العميل، مما أتاح للباحثين مقارنة الاثنين وإزالة أي شواذ كان الفلتر يلتقطها — أقواس مربعة في نطاق فرعي، على سبيل المثال — حتى أصبح الحقن مستقرًا من البداية إلى النهاية.

تقرير Dark Reading أن إخفاء Salesforce لعناوين URL كان حتى الآن يعتمد على مطابقة التعبيرات النمطية لتحديد ما إذا كانت سلسلة نصية تبدو كعنوان URL، وهو ما سمح بإخفاء النطاقات في تنسيقات غير متوقعة. وتقول الشركة إنها استبدلت ذلك بتحليل لعناوين URL متوافق مع المواصفات، وجمّعت فحص عناوين URL بحيث تمر الآن كل حركة مرور الوكيل المتعلقة بعناوين URL عبر بوابة واحدة.

الثغرة الثالثة: التصيّد الاحتيالي باسم الوكيل نفسه

الاكتشاف الخاص بـ Slack، الذي نُشر في اليوم نفسه في منشور ثانٍ منسوب إلى João Donato وزملائه، يتعلق بالهوية وليس بالبيانات. يمكن نشر وكلاء 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، ومتى

استغرق الإفصاح وقتًا طويلًا، وكان ودّيًا بحسب رواية Zenity. أُرسلت النتائج إلى Salesforce عبر البريد الإلكتروني في 1 يونيو 2026؛ وأكدتها Salesforce في اليوم التالي وقالت إنها تعمل على الإصلاحات؛ وعقد الفريقان مكالمة تقنية في 16 يونيو؛ وأغلقت Salesforce الإفصاحات في 17 يونيو مشيرة إلى أن فريق الهندسة لا يزال يعمل. وفي 18 أغسطس أكدت Salesforce الإصلاحات، وفي 19 أغسطس تحققت Zenity تحديدًا من تجاوز Trusted URLs. وتم تأكيد إصلاح الإسناد في إجراء Slack في 20 أغسطس. واستغرق اشتراط التأكيد افتراضيًا وقتًا أطول: في 25 أغسطس قالت Salesforce إنها لا تزال تعمل عليه، وفي 10 سبتمبر حددت 21 سبتمبر موعدًا مستهدفًا، وفي 21 سبتمبر اختبرت Zenity الأمور الثلاثة جميعها وأكدتها.

التغييرات التي تصفها Salesforce محددة. تتطلب الآن الإعدادات الافتراضية لبعض إجراءات Agentforce في Slack تأكيد المستخدم قبل إرسال الرسالة، وتقول الشركة إنها تتواصل مع العملاء مباشرة لمراجعة إعداداتهم. وفي Trusted URLs، لم تعد مطابقة التعبيرات النمطية (regex) موجودة لصالح تحليل متوافق مع المواصفات، وتم توحيد فحص عناوين URL في بوابة واحدة بدلاً من معالجته في عدة نقاط داخل سير العمل.

ملاحظة زينيتي الختامية بشأن إصلاح سلاك هي تحفّظ وليست تطمينًا تامًا. فشرط التأكيد ما هو إلا إعداد، ولا يلزم لإيقافه سوى نقرة واحدة؛ وبمجرد إيقافه يعود مسار الهجوم نفسه متاحًا. وتتمثل نصيحة الباحثين للمؤسسات التي تبني وكلاء في مراقبة كيفية إعداد إجراءات الكتابة بدلًا من افتراض أن الإعداد الافتراضي يصمد.

لماذا يقول الباحثون إنه قابل للتعميم

على الرغم من أن التفاصيل خاصة بـSalesforce، فإن Zenity يضع SalesBleed في إطار مثال على نمط أوسع. وخلاصته الخاصة هي أن أي وكيل يقرأ سجلات مقدمة من مصادر خارجية، ويعرض روابط أو صورًا للمستخدم، ويمتلك أيضًا وصولًا إلى بيانات حساسة عبر الأدوات، فإنه يجمع المكوّنات الثلاثة نفسها في المكان نفسه. ويصف الباحثون هذا المزيج بأنه نسخة من الثلاثي القاتل — بيانات خاصة، ومحتوى غير موثوق، وقناة خارجة تلتقي في هوية واحدة.

لهذا النمط سجل محلي. تذكر Dark Reading أنه قبل SalesBleed بعام، استخدم باحثون في Noma Security المسار نفسه من Web-to-lead للوصول إلى بيانات Salesforce، وأن Salesforce ردّت بتشديد قواعد عناوين URL لديها — وهو التنقيح القائم على التعبيرات النمطية (regex) الذي تجاوزته Zenity لاحقًا. وأقرّ متحدث باسم Salesforce لـ Dark Reading بأن الاستجابة السابقة كانت إصلاحًا سريعًا لا حلًا شاملًا، وقال إن هذه الاستجابة يُقصد بها أن تكون أكثر متانة.

"وجدنا طرقًا متعددة لاختراق الحدود الأمنية المصممة لمنع Agentforce من إرسال بيانات المؤسسة إلى وجهات غير معتمدة"، كما يقول مايكل بارغوري، الشريك المؤسس والمدير التنفيذي للتقنية في Zenity، في البيان. "تظل الحدود الصارمة واحدة من أقوى الأدوات لدينا لاحتواء وكلاء الذكاء الاصطناعي، لكنها لا تزال برمجيات. وعندما تفشل تلك الضوابط، نكون أمام وكيل ذي وصول مميز واستقلالية عالية بلا قيود." وطرح تامير إيشاي شربات، مدير أبحاث الأمن في Zenity، النقطة الأوسع على Dark Reading: كلما مُنح الوكيل مزيدًا من القوة، أصبح أكثر خطورة، والوكيل القادر على مراسلة قنوات متعددة بنفسه مع قراءة العقود أو العملاء المحتملين أو الحسابات الدائنة هو مزيج سيُساء استخدامه. وأضاف بارغوري قلقًا ثانيًا إلى المنفذ نفسه — وهو أن الوكلاء يُبنون كصناديق سوداء، مع ملخصات بدلًا من السجلات، مما يجعل من الصعب معرفة ما فعله الوكيل أو لماذا.

ما سينقل هذا السجل من العرض التوضيحي إلى الحادث ليس تقنية جديدة، بل دليل: إفصاح من عميل، أو CVE، أو بيان من Salesforce أو Zenity بأن السلاسل شوهدت قيد الاستخدام. لا يوجد أي من ذلك في المصادر التي روجعت هنا. وإلى أن يوجد أحدها، يبقى SalesBleed كما يسجله الأرشيف — ثغرة عالية الخطورة، موثقة بمعيار الثقة A من قبل من اكتشفوها ومؤكد إصلاحها من قبل المورّد، دون أي ضرر مسجل في العالم الحقيقي.