כך מתקפת «הזרקת הקשר קריפטוגרפית» על Grok עלולה לדלוף נתוני צ׳אט

כך פועלת המתקפה, שלב אחר שלב

1. הדף נושא מטען נסתר. התוקף מציב באתר טקסט מוצפן, הוראות לפענוח וחומר מפתח, באופן שיכול להיראות לצד תוכן רגיל. המבנה שדווח עושה שימוש בהפקת מפתח באמצעות PBKDF2 ובהצפנת AES-256-GCM.

2. הסריקה הראשונית אינה מזהה את הפקודה. המסננים של Grok יכולים לבדוק את התוכן הגלוי בדף, אך ההוראה המסוכנת מוסתרת בתוך נתונים מוצפנים. הצפנה חזקה מונעת מהמודל לפרש ישירות את הפקודה בשלב הראשון.

3. הסוכן מפענח את המטען. כאשר המשתמש מבקש מ-Grok לסכם או לנתח את הדף, הסוכן פועל לפי הוראותיו ומריץ את תהליך הפענוח בסביבת הרצת הקוד שלו.

4. הפקודה חוזרת להקשר של הסוכן. הטקסט המפוענח מוצג כתוצאה של פעולת כלי. כך נוצר כשל במקור המידע: תוכן שנשלט בידי התוקף עבר מדף אינטרנט לא-מהימן אל הקשר שהסוכן עשוי להתייחס אליו כתוצאה תפעולית מהימנה.

5. Grok אוסף נתונים מהסשן. בהדגמת הוכחת-היתכנות, ההוראות המפוענחות ביקשו מ-Grok לשלוף פרטים כמו שם המשתמש, מיקום משוער, סוג המנוי והפרומפטים או ההקשר של השיחה הזמינים לסוכן.

6. בקשת דפדפן שולחת את הנתונים החוצה. לאחר מכן Grok פתח כתובת URL בשליטת התוקף והציב את הנתונים שנאספו בפרמטרים של הכתובת. לפי ההדגמה שדווחה, ההעברה הושלמה ללא אישור נוסף וללא אזהרה גלויה.

חשוב לדייק בהיקף: הראיות הזמינות תומכות בגישה לפרומפטים ולהקשר שהיו זמינים לסוכן בשיחה הפעילה. לכן אין לפרש אוטומטית את הביטוי «היסטוריית צ׳אט מלאה» כגישה לכל השיחות המאוחסנות בחשבון המשתמש.

מתי דווחה התקלה ל-xAI?

Adversa מסרה כי דיווחה על הבעיה ל-xAI באמצעות HackerOne ב-3 ביוני 2026. החוקרים שלחו עדכוני תיאום נוספים ב-4 וב-10 באוגוסט.

נכון ל-19 באוגוסט 2026, Adversa אמרה שלא קיבלה תגובה מהותית וכי ניתן עדיין לשחזר את המתקפה מול Grok. הדיווחים שפורסמו באותה עת תיארו את הבעיה ככזו שטרם קיבלה תיקון, ללא מזהה CVE ציבורי וללא פתרון עוקף למשתמשים.

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

מדוע ההצפנה יוצרת «עיוורון» במנגנוני ההגנה?

מנגנוני הגנה מסורתיים מפני הזרקת פרומפט מתמקדים לרוב בזיהוי שפה חשודה בתוכן שמערכת הבינה המלאכותית קוראת או שולפת. Cryptographic Context Injection מעבירה את ההוראה המסוכנת לשלב מאוחר יותר בעיבוד.

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

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

חלק ממגמה רחבה יותר באבטחת סוכני AI

החשיפה של Grok משתלבת בדפוס רחב יותר: תוכן לא-מהימן משפיע על עוזרים שיש להם גישה למידע רגיש או לכלים בעלי הרשאות משמעותיות.

• EchoLeak ב-Microsoft 365 Copilot: מחקר על EchoLeak תיעד חולשת הזרקת פרומפט ללא לחיצות משתמש ב-Microsoft 365 Copilot, שאפשרה הוצאת מידע מרחוק וללא אימות באמצעות הודעת דוא״ל שנבנתה במיוחד. החולשה מתועדת כ-CVE-2025-32711.
• CoSnitch ב-Copilot Personal: חוקרי Varonis דיווחו כי מניפולציה חוזרת של תהליך ההסקה של Copilot עלולה לגרום לשליחת מידע רגיש לשרת חיצוני ואף לשיבוש הזיכרון המתמשך של העוזר.
• מתקפות על סוכני תכנות: במחקר TrustFall תיארה Adversa כיצד הגדרות זדוניות במאגר קוד עלולות לגרום לשרת MCP בשליטת תוקף להריץ פקודות דרך עוזרי תכנות כמו Claude Code, Gemini CLI, Cursor CLI ו-GitHub Copilot CLI.

המכנה המשותף הוא שהתוקף לא בהכרח צריך לפרוץ ישירות למודל או למערכת ההפעלה. הוא מספק תוכן שהסוכן מתוכנן לקרוא, ואז מסתמך על ההרשאות של הסוכן עצמו כדי לשלוף מידע, להפעיל כלים, לשנות מצב או לבצע בקשת רשת.

אילו הגנות נדרשות?

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

• הפרדה ברורה של מקור המידע: יש להפריד מבחינה טכנית וחזותית בין תוכן מדפי אינטרנט ופלט של כלים לבין הוראות מערכת ומצב יישום מהימן.
• הגבלת הרצת קוד: אין לאפשר לתוכן שנשלף להפעיל פענוח שרירותי או קוד אחר ללא מדיניות מוגדרת, הרשאות מצומצמות וסביבת sandbox קשיחה.
• עקרון ההרשאות המינימליות: יש להגביל את סוג המידע הפרטי שסוכן יכול לגשת אליו, ולא לאפשר למשימת סיכום שגרתית לחשוף נתוני סשן שאינם קשורים אליה.
• אישור לפעולות רגישות: בקשות רשת הכוללות מידע של משתמש או של שיחה צריכות לדרוש אישור מפורש ומשמעותי.
• בקרה על תעבורה יוצאת: רשימות דומיינים מורשים, בדיקה דרך פרוקסי ובקרות egress יכולות למנוע מסוכנים לשלוח נתוני הקשר לכתובות אקראיות.
• ניטור רצף הפעולות: יש לתעד ולהתריע על רצפים חריגים, כגון שליפת דף, הרצת קוד, חילוץ נתוני הקשר ופתיחת כתובת חיצונית.

השורה התחתונה פשוטה: סוכן AI אינו רשאי להתייחס לתוכן כמהימן רק מפני שהוא התקבל דרך כלי. במקרה שדווח על Grok, המתקפה הפכה דף אינטרנט לתהליך של פענוח והרצת הוראות — ואז ניצלה את הרשאות הסוכן עצמו כדי להעביר מידע פרטי אל מחוץ לשיחה.