בכנס Black Hat USA 2026, חוקרים הראו שניתן להפוך את ה-Cascading Style Sheets (CSS) לכלי נשק המאפשר לסוכני אימייל מבוססי AI לקרוא תוכן שנסתר מעיני משתמשים אנושיים. הטכניקה עקפה את Outlook, Gmail, Yahoo ו-Proton, ואיפשרה לסוכנים להוציא נתונים כמו סיסמאות, אסימוני אימות (authentication tokens) וכתובות IP.

למה CSS חשוב לאבטחת אימייל

במשך שנים, ספקי webmail הגנו מפני HTML זדוני על ידי הסרת סקריפטים, ביצוע sandboxing ל-iframes והגבלת הפעולות שדואר אלקטרוני יכול לבצע. אמצעים אלו עוצרים התקפות קלאסיות המסתמכות על JavaScript או אובייקטים מוטמעים. עם זאת, CSS תמיד נחשב לקוד עיצוב חסר נזק. הסלקטורים המתקדמים שלו — סלקטורי מאפיינים (attribute selectors), שאילתות קונטיינר (container queries) וכדומה — מאפשרים לדף להגיב למבנה ה-DOM ללא צורך בשום סקריפט.

הדגמות ב-Black Hat הוכיחו כי הסלקטורים ה"חסרי הנזק" הללו יכולים להפוך לערוץ צדדי (side-channel) לדליפת נתונים. על ידי יצירת חוקי עיצוב החלים רק כאשר קיימים אלמנטים נסתרים מסוימים, תוקפים הופכים טקסט לבלתי נראה עבור המשתמש, אך הוא עדיין נשאר נוכח בדף המרונדר (rendered page) שסוכן ה-AI מנתח.

איך ההתקפות עובדות

הוכחת יכולת (proof-of-concept) אחת שלחה אימייל שנראה רגיל לחלוטין עבור הנמען. בתוכו הוסתרו חוקי CSS ששינו את צבע הטקסט הספציפי כך שיתאים לצבע הרקע, ובכך הסתירו אותו בפועל. אדם לעולם לא יראה את הטקסט, אך סוכן AI ששואב את ה-DOM או את עץ הנגישות (accessibility tree) אינו מחיל את המסנן הוויזואלי. כאשר הסוכן עיבד את האימייל, הוא קרא את הטקסט המוסתר ושלח אותו כחלק מ-URL fragment — חלק מכתובת אינטרנט שבדרך כלל דפדפנים מתעלמים ממנו בעת טעינת דף.

וריאציה נוספת השתמשה ב-indirect prompt injection (הזרקת הנחיות עקיפה). האימייל הכיל אסימון (token) Slack נסתר. ה-CSS הפך את האסימון לבלתי נראה עבור המשתמש אך שמר עליו בתוך ה-markup. סוכן ה-AI, שאומן לבצע הנחיות המוטמעות באימייל, פירש את האסימון כפקודה ושלח אותו חזרה לשרת של התוקף.

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

סוכני AI לעומת קוראים אנושיים

בני אדם מתעלמים באופן אינסטינקטיבי מטקסט שהם אינם יכולים לראות; אנו סומכים על הפריסה הוויזואלית שתגיד לנו מה חשוב. סוכני AI, לעומת זאת, פועלים על ה-DOM הגולמי או על עץ נגישות המתעד כל אלמנט ללא קשר למצבו הוויזואלי. כאשר AI קורא דף, הוא אינו מחיל את הכלל של "אם אני לא יכול לראות את זה, אני אתעלם מזה". חוסר התאמה זה יוצר נקודה עיוורת: צינורות ניקוי (sanitization pipelines) שנבנו לצריכה אנושית כבר אינם מבטיחים בטיחות עבור קוראים אוטומטיים.

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

מי אחראי על ההגנה?

ההתקפות מעלות שאלה של תחום אחריות. ספקי webmail כבר מנקים HTML כדי להגן על משתמשים אנושיים; דפדפנים כבר אוכפים את אותם חוקי רינדור. ובכל זאת, אף אחד מהשכבות הללו אינו לוקח בחשבון AI שנמצא בשלב מאוחר יותר בתהליך וינתח את אותו markup. האם שירות האימייל צריך להוסיף ניקוי (sanitisation) עמוק יותר של CSS? האם דפדפנים צריכים לחשוף דגל שמסמן אלמנטים כ"בלתי נראים לסקריפטים"? או שמא על ספקי AI לבנות מסננים שמשמיטים צמתים (nodes) נסתרים לפני העיבוד?

צוותי אבטחה המפתחים כלי אימייל מבוססי AI נדרשים לבצע ביקורת על כל תהליך הרינדור (rendering pipeline), ולא רק על ה-HTML שמגיע לתיבת הדואר הנכנס. המשמעות היא בדיקת ה-DOM לאחר החלת ה-CSS, בדיקת עץ הנגישות, והסרה או סימון מפורש של כל תוכן שאינו נראה לעין אנושית.

מה כדאי לעקוב אחריו בהמשך

  • בדיקות ספקים – מצפים מספקי AI לשלב וקטורי התקפת CSS מהעולם האמיתי במערכי הבדיקה שלהם. לאינטרנט יש שלושים שנות מחקר על פגיעויות; לסוכני AI יש רק כמה שנים.

אם ניתן להטעות עוזר AI ולגרום לו לדלוף פרטי גישה פשוט על ידי הסתרת טקסט באמצעות CSS, מודל האבטחה המגן על תיבות הדואר הנכנס כיום אינו מספיק עוד. מפתחים, ספקים ורגולטורים חייבים להתייחס לדף המרונדר — ולא רק ל-HTML הגולמי — כגבול האבטחה עבור כל צרכן אוטומטי. בעיית הטקסט הנסתר מזכירה לנו שטכנולוגיה שפעם הוגדרה כ"רק לעיצוב" יכולה להפוך למסלול לגניבת נתונים. גל ההגנות הבא יצטרך להכיר ב-CSS כשטח תקיפה (attack surface) פוטנציאלי, ולא רק כאמצעי עזר ויזואלי.