באג ב-Workers AI של Cloudflare: 155 תשובות של מודל GLM-5.3 הכילו מידע מבקשות של לקוחות אחרים
Cloudflare פרסמה דוח על תקלה בבידוד בין לקוחות במודל GLM-5.3 שהיא מגישה בשירות Workers AI. בין 27 באוגוסט ל-9 בספטמבר 2026 הכילו 155 תשובות לפרומפטים ארוכים במיוחד מידע מבקשות של משתמשים אחרים. לפי החברה, אין עדות לניצול מכוון, והתקלה תוקנה גם בתצורה שלה וגם במנוע ההסקה SGLang.
Cloudflare חשפה ש-155 תשובות שהחזיר מודל GLM-5.3 בשירות Workers AI הכילו מידע מבקשות של לקוחות אחרים. השירות מגיש מודלי AI לשימוש דרך הענן של החברה. לפי הדוח שפרסמה החברה, התקלה פעלה מ-27 באוגוסט 2026 ועד 9 בספטמבר, אז הוחזר המודל לשירות אחרי תיקון. החברה מציינת שהתקלה פגעה רק בפרומפטים ארוכים מ-681,280 טוקנים, ושאף מודל אחר ב-Workers AI לא נפגע.
איך זה התגלה
את הבעיה דיווח ב-8 בספטמבר החוקר גדי אברון מחברת Knostic, דרך תוכנית ה-HackerOne של Cloudflare (תוכנית שבה חוקרים מדווחים לחברה על פרצות). לפי הדיווח, פרומפטים ארוכים מאוד שנשלחו למודל @cf/zai-org/glm-5.3 החזירו לפעמים טקסט מסשנים של משתמשים אחרים. GLM הוא מודל לייצור טקסט של חברת Z.ai, שנבנה לעבודת תכנות בעזרת סוכני AI.
Cloudflare מספרת ששחזרה את התקלה למחרת בבוקר, והורידה את המודל מהשירות תוך 40 דקות מרגע שהכריזה על אירוע. באותו יום פרסה תצורה מתוקנת וגרסה מתוקנת של מנוע ההסקה, והחזירה את השירות. הדוח מתפרסם בגילוי מתואם יחד עם פוסט של SGLang, מנוע ההסקה בקוד פתוח (open source) שהחברה משתמשת בו.
מה השתבש
כדי להבין את התקלה צריך להכיר את ה-KV cache. זה זיכרון ביניים על ה-GPU, ששומר ייצוג מעובד של הטקסט שהמודל קרא, כדי שלא יצטרך לחשב אותו מחדש בכל מילה שהוא מייצר. לפי Cloudflare, הכשל נוצר משתי בעיות שהצטלבו.
הבעיה הראשונה הייתה בתצורה. Cloudflare הגדירה למודל חלון הקשר (context window) של 1,048,576 טוקנים. אבל מאגר ה-KV cache בכרטיסים שמעבדים את הפרומפט, שלב שנקרא prefill, הכיל מקום ל-681,280 טוקנים בלבד. החברה כותבת שידעה על הפער לפני ההשקה. היא ציפתה שהמנוע יחזיר שגיאה על כל פרומפט שאינו יכול לעבד, ומכיוון שבדיקות ההקשר הארוך שלה הצליחו, לא חשבה שיש כאן בעיה.
הבעיה השנייה הייתה באג ב-SGLang, במצב שבו שלב ה-prefill ושלב ייצור התשובה (decode) רצים על שרתים נפרדים. פרומפט שלא נכנס למאגר סומן כנדחה והוחלף בממלא מקום באורך טוקן אחד. אלא שבמקום לבטל את הבקשה ולהחזיר שגיאה, המערכת המשיכה כרגיל. שרת ה-decode קיבל הודעת "העברה הושלמה" והניח שה-cache מכיל את הפרומפט המלא. בפועל, רוב התוכן שנשאר בו היה מבקשות קודמות, והתשובה נוצרה על סמך הנתונים הישנים האלה.
אחרי שסיננה את הבדיקות שלה ושל החוקר, Cloudflare מסכמת שהבקשות שזוהו תואמות בתזמון ובהיקף לשימוש רגיל בהקשר ארוך, ולא לניסיון חוזר לנצל את הבאג. לדבריה, לא נמצאה עדות לניצול מכוון.
התיקון
Cloudflare תיקנה את הבעיה בשני מישורים. ראשית, היא שינתה את תצורת GLM-5.3 כך שתתאים לזו של GLM-5.2. השינוי פינה מספיק זיכרון כדי שהמאגר יכיל כ-2.04 מיליון טוקנים, בערך פי שניים מחלון ההקשר. כך כל פרומפט חוקי נכנס למאגר.
החברה כותבת שהסתמכות על גודל המאגר בלבד "שבירה", כי שינויים כמו quantization (דחיסת משקלי המודל) או גרסת מודל חדשה משנים את גודל המאגר באופן שקל לפספס. לכן היא גם תיקנה את המנוע, כך שבקשה שנדחתה נעצרת עם השגיאה המקורית לפני שמוקצה לה זיכרון או מועברים נתונים. התיקון הוצע לפרויקט כ-#38704. לדברי החברה, תיקון דומה כבר מוזג לענף הראשי של SGLang ב-#36988 ב-6 בספטמבר, אך עוד לא שוחרר בגרסה רשמית. המתחזקים מיזגו גם את #38935, שדוחה בקשות כאלה מוקדם יותר.
למה זה חשוב
בשירותי AI מתארחים, בקשות של לקוחות רבים רצות על אותה חומרה ובאותו זיכרון. הלקוחות סומכים על הספק שהבקשות שלהם מבודדות זו מזו. המקרה הזה מראה, ככל הנראה, שהבידוד תלוי גם בהתנהגות של מנוע ההסקה במקרי קצה שקשה לבדוק. כאן הכשל עבר את בדיקות הספק, כי הבקשות החזירו תשובות תקינות לכאורה.
המשמעות ללקוחות היא שכדאי לשאול ספקים כיצד הם מאמתים בידוד ברמת ה-cache, ולא רק ברמת החשבון. ההחלטה של Cloudflare לתקן גם את התצורה וגם את המנוע, ולהעביר את התיקון לפרויקט הקוד הפתוח, עשויה לצמצם את הסיכון גם אצל ספקים אחרים שמשתמשים ב-SGLang.