פגיעות CVE-2026-85180 שנחשפה לאחרונה מאפשרת לתוקפים ללא הרשאה לנצל את ה-model-puller של Ollama כדי לבצע התקפות server-side request forgery (SSRF) נגד שירותים פנימיים, כולל נקודות קצה (endpoints) של מטא-דאטה בענן. הפרצה קיימת בגרסה הנוכחית, גרסה 0.33.2, וניתן להפעיל אותה ללא חשבון Ollama תקף.

למה הפגיעות הזו חשובה

צוותים רבים מפעילים שרת Ollama פנימי כדי לספק מודלים של LLM למפתחים ולצינורות CI. ה-API המספק את המודלים נותר לעיתים קרובות פתוח, כך שכל משתמש ברשת הפנימית יכול לבקש מודל לפי שמו. הנוחות הזו יוצרת נתיב ישיר מה-API הפונה לציבור אל הרשת הפרטית. CVE-2026-85180 הופך את הנתיב הזה לכלי נשק.

תוקף שמארח model registry זדוני יכול ליצור manifest שמפנה מחדש (redirect) את בקשת ההורדה לכל כתובת שתהליך ה-Ollama יכול להגיע אליה. כאשר ה-pull API מקבל את ה-manifest, הוא מבצע את ההפניה באופן אוטומטי. מכיוון שנקודת הקצה של ה-pull אינה דורשת אימות, התוקף אינו זקוק לחשבון Ollama. ההפניה יכולה להצביע על loopback, link-local, או על כל תת-רשת (subnet) פרטית, מה שמעניק לתוקף נקודת אחיזה בתוך ה-VPC בענן של הקורבן או ברשת ה-on-premise.

היעד המסוכן ביותר הוא שירות ה-cloud metadata (בדרך כלל 169.254.169.254). נקודת קצה זו מחלקת הרשאות (credentials) זמניות ל-instance.

איך הבאג חמק מהתיקונים הקודמים

מוקדם יותר השנה, Ollama תיקנה בעיית הפניה שזוהתה כ-CVE-2026-5530. התיקון הוסיף בדיקה שחסמה הפניות לכתובות פרטיות, אך הוא הוחל רק על רכיב ה-downloader הראשי. ה-tensor model downloader, שמטפל בסוג אחר של קבצי מודלים, משתמש בספריית HTTP client נפרדת. ספרייה זו מעבדת הפניות באופן ידני וחסרה בה כל אימות של היעד החדש. כתוצאה מכך, מנגנון ההגנה הישן לעולם אינו פועל עבור הורדות אלו, מה שמשאיר את וקטור ה-SSRF פתוח.

מי עלול להפסיד

ארגונים החושפים נקודת קצה של Ollama למערך רחב של מפתחים ניצבים בפני הסיכון הגבוה ביותר. עומסי עבודה (workloads) מבוססי ענן (cloud-native) המסתמכים על הרשאות מבוססות מטא-דאטה פגיעים במיוחד.

מה ניתן לעשות כבר עכשיו

טרם שוחרר תיקון (patch), והפגיעות עדיין קיימת בגרסה 0.33.2. עד שתיקון רשמי יפורסם, על המפעילים להקשיח את שכבת הרשת סביב תהליך ה-Ollama.

  • הפסקת הפניות למודלים שרירותיים. הגבילו את ה-API כך שרק משתמשים או שירותים מהימנים יוכלו להגיש שמות של מודלים. דחו כתובות URL של registry לא ידועות או כאלו שסופקו על ידי משתמש.
  • נעילת תעבורה יוצאת. ברמת הקונטיינר, המארח (host) או חומת האש (firewall), חסמו חיבורים ל-loopback, link-local וטווחי כתובות IP פרטיות מתוך תהליך ה-Ollama. דחו במפורש גישה לכתובת ה-cloud metadata (169.254.169.254) אלא אם עומס העבודה זקוק לה באמת.
  • שימוש ב-registry מנוהל. ארחו model registry פנימי שמגיש רק manifests שנבדקו. החילו רשימת הרשאות (allow-list) של שמות מארחים (hostnames) ודחו כל הפניה שמצביעה למקום אחר.
  • ניטור בקשות pull חשודות. סרקו את לוגים של Ollama לאיתור בקשות pull שמייצרות מיד תעבורת רשת לכתובות פנימיות. בצעו קורלציה עם טלמטריית רשת כדי לזהות חיבורים יוצאים בלתי צפויים.

מה לעקוב בהמשך

עקבו אחר הערות הגרסה (release notes) וההודעות על אבטחה של הפרויקט לקראת התיקון הקרוב. בינתיים, התייחסו ל-model-puller כשירות בעל יכולות רשת ויישמו את ארבעת אמצעי ההגנה באופן מיידי.

בשורה התחתונה: פגיעות SSRF ללא אימות במוריד המודלים של Ollama עלולה לחשוף הרשאות ענן ו-APIs פנימיים; עד שיפורסם תיקון, חסמו גישה יוצאת לרשתות פרטיות, הגבילו הפניות למודלים ונטרו פעילות pull.