CVE-2025-62164 היא פגיעות חמורה ב- vLLM, אחד ממנועי ההסקת LLM בקוד פתוח הנפוצים ביותר. הבעיה קיימת בתוך API להשלמות והוא מופעל כאשר השרת מעבד הטמעות הפקודות המסופקות על ידי המשתמש. בגרסאות המושפעות (0.10.2 עד 0.11.1 לא כולל), vLLM מבצע דה-סריאליזציה של טנזורים באמצעות torch.load() ללא אימות חזק. טנזור דליל מעוצב יכול לחמוק ולגרום ל כתיבה מחוץ לגבולות במהלך צפיפות, אשר גורם לקריסת העובד באופן מהימן ועשוי להחמיר לביצוע קוד מרחוק בתנאים הנכונים. הפרויקט שיחרר תיקון ב vLLM 0.11.1. (NVD)

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

היכן ממוקם vLLM בסטאק — ומדוע מיקום זה מגביר את הסיכון

vLLM הוא למעשה שכבת הסקה המותאמת לתפוקה. צוותים פורסים אותו כ-API SaaS ציבורי, מאחורי שער ארגוני, או כ-backend לשירות עבור מערכות סוכנים מרובות דיירים. בכל התצורות הללו, vLLM קרוב לאינטרנט וקרוב למשאבי GPU. זה נשמע כמו הנדסת ביצועים; זה גם אומר מבקשי API בעלי הרשאות נמוכות עשויים להגיע לנתיבי קוד בעלי הרשאות גבוהות. (wiz.io)

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

הפגיעות בפסקה אחת

נקודת הקצה Completions בגרסאות vLLM פגיעות מאפשרת ללקוחות להעביר הטמעות מיידית במקום טקסט גולמי. vLLM משחזר את הטנזורים הללו באמצעות torch.load() ללא בדיקות תקינות, סוג או מבנה מספקות. מאחר ש PyTorch 2.8.0 מבטל כברירת מחדל את בדיקות תקינות הטנזור הדליל, טנזור דליל זדוני יכול לעקוף הגנות גבולות פנימיות ולעורר כתיבה לזיכרון מחוץ לטווח כאשר to_dense() נקרא. התוצאה המיידית והניתנת לשחזור היא DoS מרחוק (תקלה בעובד). עם פריסת זיכרון ובקרה נוחות, אותו פרימיטיב יכול להפוך באופן סביר ל RCE במארח. (NVD)

אנטומיה של הגורם השורשי: כיצד "הטמעה נוחה של מעבר" הפכה לשחיתות זיכרון

מנקז דה-סריאליזציה בנקודת קצה ציבורית

torch.load() הוא בעל עוצמה רבה מעצם תכנונו. הוא נועד לשחזר טנזורים וגרפי אובייקטים ממקורות מהימנים (נקודות ביקורת, צינורות פנימיים). במקרה של vLLM, הוא משמש בשדה שניתן לאכלס באמצעות מתקשר API. הדבר מעביר את גבול האמון מ"תוצר מודל פנימי" ל"קלט אינטרנט לא מהימן", שהוא המקום שבו, מבחינה היסטורית, מתרחשת דה-סריאליזציה לא בטוחה. (NVD)

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

שינוי ההתנהגות ב-PyTorch 2.8.0 היה הניצוץ

הייעוץ של vLLM ו-NVD מייחסים את ההחמרה לשינוי ב-PyTorch: בדיקות תקינות של טנזורים דלילים כבויות כעת כברירת מחדל. בעבר, טנזורים דלילים פגומים היו מועדים יותר לדחייה לפני שהקוד הגיע לשלב הצפיפות. עם השבתת הבדיקות, היעדר האימות המוקדם של vLLM הפך לניתן לניצול באופן עקבי. (NVD)

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

בדיקת המציאות של ההשפעה: DoS מובטח, RCE הוא תקרה

כל הכתבות הציבוריות מסכימות כי DoS מרחוק הוא אמין. בקשה אחת פגומה יכולה להשבית עובד; בקשות חוזרות ונשנות עלולות לגרום לחוסר יציבות בצי. (ZeroPath)

RCE מתואר כ פוטנציאל מסיבה טובה. פגיעה בזיכרון מספקת נתיב, אך הפיכתה לנשק תלויה בהתנהגות המוקצה, בדגלי הקשחה, בגבולות המכל ובמידת השליטה של התוקף על האזור הפגוע. יש אין רישום CISA KEV ולא אושר באופן נרחב שרשרת ניצול בפועל נכון ל-25 בנובמבר 2025, אך התייחסות לשחיתות זיכרון במישור הנתונים כאל "DoS בלבד" תהיה טעות. (wiz.io)

גרסאות מושפעות ומצב התיקון

(NVD)

מי צריך להיכנס לפאניקה ראשון: מודלים של איומים משמעותיים

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

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

פלטפורמות "LLM as a Service" מרובות משתמשים מגיעות לאחר מכן. הסכנה היא שהטמעות עלולות לזרום פנימה. בעקיפין — באמצעות שרשראות כלים, תוספים, מסגרות סוכנים או שירותי upstream שמעבירים הטמעות כשיפור. ככל שתקבל יותר מקומות עם מטענים שאינם טקסט, כך גבול האמון שלך יהפוך למורכב יותר.

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

דרכים בטוחות לאישור חשיפה (ללא בדיקות מסוכנות)

המיון המהיר ביותר הוא מיון מבוסס גרסאות.

python -c "import vllm; print(vllm.__version__)" # מושפע אם 0.10.2 <= גרסה < 0.11.1

(NVD)

מבחינה תפעולית, חפשו דפוס של שגיאות segfault של עובדים או הפעלה מחדש פתאומית קשורות לבקשות השלמה גדולות מהרגיל או מוזרות מבחינה מבנית. בפועל, תחילה מופיעים שיאים של קריסות; ניצול מתוחכם (אם הוא מגיע אי פעם) מגיע מאוחר יותר. (ZeroPath)

בדיקת קנרי בלתי מזיקה — השלמות סטנדרטיות, ללא העברת הטבעה — שימושית ליציבות בסיסית סביב תיקונים:

import requests, json, time HOST = "https:///v1/completions" headers = {"Authorization": "Bearer "} payload = { "model": "your-model-name", "prompt": "health check",
    "max_tokens": 4 } for i in range(5): r = requests.post(HOST, headers=headers, data=json.dumps(payload), timeout=10, verify=False) print(i, r.status_code, r.text[:160]) time.sleep(1)

תיקון מהיר, ולאחר מכן הקשחת מישור הנתונים

הפתרון האמיתי הוא פשוט לשדרג ל- vLLM 0.11.1 ואילך. כל השאר הוא פתרון זמני. (NVD)

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

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

מדוע CVE-2025-62164 חשוב לאבטחת בינה מלאכותית כתחום

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

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

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

אימות מבוקר כאשר ה-PoC מסובכים או מאחרים

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

בתהליכי עבודה בסגנון Penligent, ניתן להנחות את הסוכנים לקלוט את הייעוץ של vLLM ואת רשומת NVD, להסיק את תנאי החשיפה המדויקים (גרסאות, נתיב הטמעות, הנחות PyTorch) וליצור תוכנית אימות בסיכון מינימלי שאתה מריץ רק ברפליקה מבודדת. כך תקבל הוכחה אמיתית — טביעות אצבעות של גרסאות, חתימות קריסה, דלתות לפני/אחרי תיקון — מבלי להסתכן עם ה-GPU הייצור שלך. (NVD)

חשוב לא פחות, דיווח המבוסס על ראיות מקל על הסברת הדחיפות להנהלת התפעול. "תיקנו את הבעיה כי כך נכתב בבלוג" לא יעמוד במבחן בדיקת האירוע. "תיקנו את הבעיה כי העתק המעבדה שלנו היה נתון לקריסה באמצעות נתיב ההטמעות הפגיע, והנה ציר הזמן וההבדלים לאחר השדרוג ל-0.11.1" כן עובר. CVE-2025-62164 PoC: באג במישור הנתונים של vLLM שהופך הטמעות למשטח תקיפה