הצפנה שהופכת למלכודת: כיצד דף אינטרנט עלול להפוך את Grok לכלי להדלפת שיחות

חוקר Adversa AI, רוני אוטבסקי, דיווח על טכניקת הזרקת הקשר קריפטוגרפית (Cryptographic Context Injection) — מתקפת הזרקת פרומפט עקיפה וללא לחיצה נוספת מצד המשתמש, שלפי הדיווח משפיעה על סוכן הרשת של Grok.

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

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

מה משנה הזרקת הקשר קריפטוגרפית?

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

לפי הדיווח, הדף כולל מטען JSON המוצפן באמצעות AES-256-GCM, חומר מפתח והוראות שמניעות את Grok להריץ קוד פענוח בסביבת Python או בסביבת Sandbox.

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

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

כך פועלת שרשרת התקיפה המדווחת

1. הדף הזדוני נראה תמים. המשתמש מבקש מ-Grok לסכם או לנתח תוכן שנמצא בדף.
2. הדף מספק מידע מוצפן והנחיות לפענוח. לפי Adversa, המטען משתמש ב-AES-256-GCM ובמפתח שנגזר באמצעות PBKDF2, כך שההוראות העיקריות נשארות מוסתרות בעת בדיקת התוכן הראשונית.
3. Grok מריץ את קוד הפענוח. ההוראות המפוענחות מופיעות, לפי הדיווח, דרך נתיב הרצת הקוד או הכלים של המודל — ולא כטקסט גלוי שהיה חלק ברור מהדף המקורי. לאחר מכן Grok מתייחס אליהן כהקשר מהימן.
4. המטען מכתיב לסוכן את הפעולה הבאה. ההוראות המדווחות מנחות את Grok לאתר פרטי סשן, לשלב אותם בכתובת URL ולפתוח אותה. הבקשה מעבירה את המידע לנקודת קצה בשליטת התוקף.

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

הבעיה האמיתית נמצאת בסביבת ההרצה

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

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

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

לוח הזמנים ומצב הטיפול

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

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

מה צריך לתקן?

ההמלצות של Adversa מתמקדות ב-Runtime — סביבת ההרצה של הסוכן — ולא רק בהוספת מסננים למילות מפתח:

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

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

איך זה קשור למתקפות אחרות נגד סוכני AI?

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

בפרשת EchoLeak של Microsoft 365 Copilot תוארה פגיעות של הזרקת פרומפט ללא לחיצה, שבה הודעת דוא״ל שנבנתה במיוחד יכלה לאפשר לתוקף מרוחק ולא מאומת להוציא מידע שאליו העוזר היה חשוף. מחקר אקדמי מזהה את המקרה כ-CVE-2025-32711.

בדיווחים נפרדים על Copilot Personal של Microsoft תוארה שרשרת CoSnitch, שבה קישור שנבנה במיוחד יכול היה להפעיל פרומפט ולגרום להדלפת מידע מיישומים מחוברים. החוקרים מסרו כי Microsoft הפיצה תיקונים ב-18 באוגוסט 2026.

גם סוכני תכנות חשופים לסיכון דומה, רק שבמקום דפי אינטרנט וכתובות URL, וקטור התקיפה הוא מאגר קוד. Adversa דיווחה שמאגרים זדוניים יכולים לנצל התנהגויות של אמון והגדרות בכמה עוזרי תכנות, בהם Claude Code, Cursor CLI, Gemini CLI ו-Copilot CLI, כדי להפעיל שרתי MCP בשליטת התוקף עם הרשאות שעלולות להיות רחבות. בדיווח אחר תיארה Adversa עקיפת מדיניות במאגר קוד באמצעות שרשראות ארוכות של פקודות Shell, עם אפשרות לגניבת סיסמאות או סודות.

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

המשמעות הרחבה לאבטחת AI

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

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

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