R
מחילת הארנב 17 במאי 2026 · 4 דק׳ קריאה

Bleeding Llama: כשמודל ה-AI שמופעל אצלכם מדליף סיסמאות לכל דורש

אבטחת מידעCVEAI SecurityOllamaמתחיליםמודיעין איומים

שמו של האירוע לא מקרי: Bleeding Llama — דימום הלמה — הוא הד מכוון לפגיעות Heartbleed של 2014, שגרמה לדליפת זיכרון ממאות מיליוני שרתים ברחבי העולם. הפעם הקורבן הוא Ollama — שרת קוד פתוח שמאפשר להריץ מודלי שפה גדולים (LLMs) באופן מקומי — ולפחות 300,000 שרתים חשופים כרגע לפגיעות.

מה זה Ollama ומי בסיכון?

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

ברירת המחדל של Ollama היא להאזין רק לכתובת 127.0.0.1 (מחשב מקומי בלבד). אך רבים מגדירים OLLAMA_HOST=0.0.0.0 כדי לאפשר גישה מכמה מכשירים — ובכך חושפים את השרת לכל רשת שהוא מחובר אליה, כולל האינטרנט. על פי הממצאים, כ-300,000 שרתי Ollama חשופים כך ברבים.

עדכון Ollama 0.17.1 שוחרר ומתקן את הפגיעות. אם גרסת ה-Ollama שלכם ישנה יותר — אתם חשופים.

הפגיעות הטכנית: קריאת זיכרון מחוץ לגבולות

כדי להבין את הפגיעות, צריך להכיר פורמט אחד: GGUF (GPT-Generated Unified Format) — הפורמט הסטנדרטי לאחסון משקלי מודל AI, מטאדטה ומידע Tokenizer. כשמעלים מודל חדש ל-Ollama דרך ה-API שלו, המערכת מבצעת תהליך של quantization — דחיסה ויעול של המודל — ובמסגרתו קוראת וממירה את ה-Tensors מתוך קובץ ה-GGUF.

כאן נמצא הבאג: בפונקציה WriteTo(), שנמצאת בקבצי fs/ggml/gguf.go ו-server/quantization.go, Ollama משתמש בחבילת unsafe של Go — שמבטלת את בדיקות הבטיחות המובנות בשפה. כשקובץ GGUF מצהיר על Tensor עם גודל גדול ממה שהקובץ מכיל בפועל, הקוד ממשיך לקרוא מעבר לגבול החיץ שהוקצה — וקורא ישירות מזיכרון ה-Heap הסמוך של התהליך.

ציון ה-CVSS של הפגיעות, CVE-2026-7482, עומד על 9.1 — קריטי.

שלוש קריאות API לגניבת סיסמאות

המתקפה פשוטה במיוחד — ואינה דורשת שום אימות זהות:

שלב 1: העלאת קובץ GGUF מעוצב

התוקף שולח בקשת HTTP POST ל-/api/create עם קובץ GGUF שבו ה-Tensor מצהיר על גודל עצום — גדול בהרבה מתוכן הקובץ עצמו. אין בדיקת זהות, אין סיסמה נדרשת.

שלב 2: גרימת הדליפה

Ollama מנסה לבצע quantization למודל ה”חדש”. הפונקציה WriteTo() קוראת מעבר לגבול החיץ — ושואבת לתוך ה”מודל” שיוצרת זיכרון Heap שהתהליך מחזיק לידו. הנתונים אינם חלק מהקובץ שהועלה — הם שייכים לתהליך Ollama עצמו.

שלב 3: חילוץ הנתונים

התוקף משתמש ב-/api/push כדי “לדחוף” את הארטיפקט שנוצר לרג’יסטרי שבשליטתו — ומקבל בחזרה את כל המידע שנשאב מהזיכרון. גם נקודת קצה זו אינה מחייבת אימות.

מה נמצא ב-Heap?

זה בדיוק מה שהופך את הפגיעות לסכנה ממשית. ה-Heap של תהליך Ollama מחזיק לרוב:

  • משתני סביבה — המכילים לעיתים קרובות מפתחות API (כמו OPENAI_API_KEY, ANTHROPIC_API_KEY, DATABASE_URL ועוד)
  • System Prompts — ההוראות שארגון הגדיר לעוזר ה-AI שלו, שמכילות לעיתים לוגיקה עסקית קניינית ומידע רגיש
  • שיחות של משתמשים מקבילים — נתוני שיחה של כל מי שניצל את השרת ברגע המתקפה
  • מפתחות ומידע נוסף שנטען לזיכרון תוך כדי הפעלת המודל

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

מה לעשות עכשיו?

עדכון מיידי

עדכנו ל-Ollama 0.17.1 בהקדם האפשרי. ניתן להריץ ollama --version לאימות הגרסה הנוכחית.

הגבלת חשיפה

  • אם אינכם חייבים לחשוף את Ollama לאינטרנט — וודאו ש-OLLAMA_HOST=127.0.0.1 (ברירת המחדל)
  • חסמו את פורט 11434 בחומת האש לכל IP חיצוני לא מורשה
  • הפעלת ארגז חול כגון Container או VM לתהליך Ollama מגבילה את הנזק גם בתרחיש פריצה

רוטציה של מפתחות

אם Ollama פעל עם משתני סביבה שמכילים API keys — החליפו אותם מיידית. יש להניח שמפתחות אלה נחשפו לכל תוקף שהייתה לו גישה לשרת בזמן הפגיעות.

עיקרון המינימום הרשאות

תנו לתהליך Ollama רק את משתני הסביבה שהוא באמת צריך לתפקוד. מפתח של מסד נתונים, ארכיון S3, או שירות חיצוני שאין לו קשר ישיר ל-AI — אל תעבירו לתהליך.

סיכום

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

מקורות: The Hacker News | Mondoo Blog | CVEFeed

תגובות