LiteLLM (שער מאוחד לממשקי מודלי שפה)

מה זה LiteLLM: שער אחד למאה מודלים

LiteLLM היא ספריית קוד פתוח, עם ליבה בשפת Rust ושכבת SDK בשפת Python. היא נועדה לפתור בעיה מוכרת לכל מי שמפתח עם כמה מודלי שפה במקביל: כל ספק מודלים (OpenAI, Anthropic, Google, Amazon Bedrock, Azure ואחרים) מגדיר פורמט קריאה (API) מעט שונה משלו. LiteLLM מציעה ממשק אחיד, בתבנית של OpenAI, שמאפשר לקוד לקרוא לכל אחד מיותר מ-100 ספקי מודלים נתמכים בלי לשנות את המבנה הבסיסי של הבקשה. הפרויקט קיים בשתי צורות. הראשונה היא ספריית SDK שמתקינים בתוך קוד האפליקציה (ייבוא Python וקריאה לפונקציה כמו completion()). השנייה היא "שער" (Gateway): שרת מרכזי שרץ בנפרד, בדרך כלל בשם "פרוקסי LiteLLM" (LiteLLM Proxy), שארגון שלם מפנה אליו את כל תעבורת ה-AI שלו. בתמורה הארגון מקבל ניהול מפתחות (כל צוות או משתמש מקבל מפתח גישה נפרד לשער, לא לספק המודל עצמו), מעקב עלויות, איזון עומסים בין ספקים, מגבלות תקציב, "מעקות הגנה" (guardrails) שבודקים תוכן לפני שהוא מגיע למודל או אחרי שהוא חוזר ממנו, ולוח בקרה מרכזי לניהול כל זה. לפי עמוד החברה, בין המשתמשים בכלי נמנות חברות כמו Rocket Money, Samsara, Lemonade ו-Adobe. בזכות צורת השער הזו LiteLLM מוזכרת כבר בכמה ערכים אחרים באתר, כדוגמה מוכרת לתשתית ניתוב בין מודלים.

מי בנה את זה

LiteLLM היא המוצר המרכזי של חברת BerriAI. החברה הוקמה ב-2023 בסן פרנסיסקו בידי קריש דולאקיה (Krrish Dholakia) ואישאן ג'אפר (Ishaan Jaffer), ועברה את תוכנית Y Combinator במחזור החורף של 2023. לפי עמוד החברה הרשמי ב-YC, הגיוס הראשוני עמד על כ-1.6 מיליון דולר, מגופים כמו Y Combinator, Gravity Fund ו-Pioneer Fund, והחברה מונה כיום כ-20 עובדים. מאגר הקוד של הפרויקט ב-GitHub (BerriAI/litellm) עמד, נכון לכתיבת ערך זה, על כ-62 אלף "כוכבים" (stars), מדד פופולריות מקובל בקוד פתוח. חברת האבטחה Datadog ציינה שלספרייה יש כ-23 מיליון הורדות בשבוע. הנתון הזה ממחיש כמה רחב משטח החשיפה כשמשהו משתבש בגרסה שמתפרסמת ממנה. הקוד הבסיסי פתוח לכולם, אבל חלק מהתכונות המתקדמות שמכוונות לארגונים גדולים, כמו בקרות הרשאה מורכבות, מסופקות תחת רישיון מסחרי נפרד, שהחברה מכנה "LiteLLM Commercial License". זה מודל עסקי נפוץ בכלי תשתית בקוד פתוח: הוא מאפשר לחברה להרוויח בלי לנעול את השימוש הבסיסי מאחורי תשלום.

התקרית הראשונה: מרץ 2026, אסימון גנוב וכלי סריקה פרוץ

ב-24 במרץ 2026, בשעה 10:39 (UTC), פרסם תוקף במאגר החבילות הציבורי PyPI גרסה זדונית של LiteLLM, 1.82.7, ובשעה 10:52 גרסה זדונית שנייה, 1.82.8. לפי חברת המחקר FutureSearch, שתי הגרסאות הורדו יחד 46,996 פעמים (32,464 מהן של גרסה 1.82.8) בחלון של 46 דקות, עד שמנהלי PyPI העבירו את שתיהן להסגר ב-11:25. הודעת האבטחה הרשמית של הפרויקט (Security Advisory) מתארת את הרקע: תוקף פרץ לכלי סריקת אבטחה חיצוני בשם Trivy, שבו השתמש צינור הבנייה (CI/CD) של LiteLLM, וגנב ממנו את אסימון ההרשאה לפרסום חבילות ב-PyPI. בעזרת האסימון הגנוב פרסם התוקף את שתי הגרסאות הזדוניות ישירות ב-PyPI, בלי לעבור כלל דרך מאגר המקור ב-GitHub. לכן אין להן תג גרסה (tag) תואם במאגר הציבורי. גרסה 1.82.7 הזריקה קוד זדוני בקידוד Base64 לתוך הקובץ proxy_server.py. גרסה 1.82.8 הוסיפה קובץ litellm_init.pth שרץ אוטומטית בכל הפעלה של Python, גם אם הקוד בפועל אינו מייבא (import) את LiteLLM. שתי הגרסאות נועדו לגנוב מפתחות API של ספקי AI, אישורי גישה לענן (AWS, GCP, Azure) וקובצי תצורה רגישים, ולשלוח אותם מוצפנים לכתובת חיצונית. התקרית התגלתה מהר יחסית בגלל תקלה בקוד הזדוני עצמו. קובץ ה-.pth הפעיל את עצמו מחדש בכל תהליך Python חדש, וכך יצר "פיצוץ תהליכים" (fork bomb) שהשבית מעבדים של משתמשים. לפי FutureSearch, מי שאיתר את הבעיה היה מהנדס שהבחין שהמחשב שלו "נתקע באופן קיצוני".

התקרית השנייה: אוקטובר 2026, מזהים גנובים ומאגר מזלג מתחזה

ב-21 באוקטובר 2026 התגלה פרסום של גרסה זדונית נוספת: 1.107.0. היא הועלתה ל-PyPI וגם לתגי ה-Docker הרשמיים (v1.107.0, latest, main-latest, main-stable) ב-GitHub Container Registry וב-Docker Hub. לפי חברת האבטחה Datadog, הפעם נוצל צינור השחרור הפרטי של LiteLLM עצמו, אחרי שתוקפים גנבו אסימוני הרשאה של GitHub CLI משלושה מהנדסים בחברה. הם הריצו את התהליך מול "מזלג" (fork) זדוני של המאגר בשם Berri-AI/litellm, שנבדל במקף יחיד בלבד מהשם של המאגר האמיתי, BerriAI/litellm, ואישרו את ההרצה בעצמם. חברת האבטחה Aikido תיארה גם פרט טכני משלים: בקובץ ההגדרות של הבנייה הוגדרה הנחיה שגרמה לכלי הבנייה לצרף לחבילה תיקייה בשם cook, שאינה קיימת כלל בקוד המקור הגלוי ב-GitHub. הגרסה הזדונית הטמינה בתוך site-packages של Python שלושה קבצים: cook.pth, שמריץ אוטומטית בכל הפעלה של Python קובץ לגניבת אישורים בשם cook.py, וקובץ sitecustomize.py שמפעיל סוס טרויאני לגישה מרחוק (RAT). שני הקבצים פועלים גם אם איש אינו מייבא בפועל את LiteLLM, בדיוק כמו בתקרית הקודמת. קובץ גניבת האישורים שלח נתונים מוצפנים לכתובת מתחזה, litellm[.]dev, שאינה שייכת לפרויקט האמיתי. הסוס הטרויאני, מצדו, בדק כל שעה קובץ במאגר GitHub חיצוני כדי לקבל כתובת שליטה עדכנית, והוריד ממנה קוד והריץ אותו. המנגנון הזה מאפשר לתוקף לשנות את מטרת ההתקפה גם אחרי ההדבקה, בלי לפרסם גרסה זדונית נוספת. ההתקנות הנגועות התאפשרו בחלון זמן קצר: הורדות מ-PyPI בין 11:39 ל-12:47 (UTC), ומשיכות Docker בין 11:46 ל-14:20. אז הסירה LiteLLM את החבילה ואת התגים הנגועים, ופרסמה הנחיות תיקון רשמיות בהודעה מספר 47826 במאגר הפרויקט.

מה בדיוק נגנב בשתי התקריות

שני המנגנונים הזדוניים נועדו לגנוב כמה שיותר, לא פריט מוגדר אחד. בתקרית מרץ 2026 המטרה המרכזית הייתה מפתחות API של ספקי AI (OpenAI, Anthropic, Azure) ואישורי גישה לענן. בתקרית אוקטובר 2026 דיווחה חברת האבטחה Aikido על רשימה רחבה בהרבה: סיסמאות שמורות והיסטוריית גלישה מדפדפנים מבוססי Chromium ומ-Firefox; מפתחות SSH פרטיים והיסטוריית מעטפת; אישורי גישה לענני AWS, Azure ו-GCP (כולל נקודות קצה של מטא-דאטה); אסימוני גישה של Kubernetes; סודות של כלי CI/CD כמו GitLab ו-Jenkins; אישורים ותצורה של כלי פיתוח מבוססי AI כמו Claude Code, Cursor, GitHub Copilot ו-Gemini CLI; וכן אישורי Git, npm ו-PyPI. ברשימה נכלל גם תוכן מסד הנתונים הפנימי של LiteLLM עצמו, כולל מפתחות API שאוחסנו בו לכל ספקי המודלים שחוברו לשער.

מה משותף לשתי התקריות

בשתי התקריות התוקף לא נגע בקוד המקור הגלוי של LiteLLM ב-GitHub, ולא ניצל חור אבטחה באפליקציה עצמה. הוא השתלט על צינור ההפצה של החבילה. גניבת אסימון הרשאה בודד הספיקה כדי להעלות גרסה זדונית תחת השם הלגיטימי של הפרויקט, ולהפוך כל מי שמריץ pip install litellm לקורבן, בלי שום פעולה נוספת מצדו. שני המנגנונים הזדוניים גם נבנו כך שירוצו אוטומטית בכל הפעלה של Python, בלי קשר לשאלה אם מישהו באמת משתמש בספרייה. לכן גם סביבת פיתוח שבה LiteLLM רק מותקנת, ולא נקראת בקוד, פגיעה. התבנית הזו, ספרייה פופולרית בקוד פתוח שהופכת לכלי להפצת מתקפה, חוזרת גם בתקריות אחרות שמתוארות באתר הזה. פרויקטים פופולריים כאלה הם מטרה אטרקטיבית בדיוק מהסיבה הזו: מספר קטן של מתחזקים אחראי על קוד שרץ בתוך אלפי מערכות אחרות. כך פריצה אחת, במקום אחד, משתכפלת אוטומטית לכל מי שמתקין את הגרסה הנגועה.

ההשלכה המעשית, ומי נפגע

בעקבות שתי התקריות פרסמה LiteLLM הנחיות תיקון רשמיות. מי שהתקין או הריץ אחת מהגרסאות הנגועות (1.82.7, 1.82.8 או 1.107.0) מתבקש להניח שכל האישורים שהיו נגישים באותה סביבה נחשפו, ולהחליף אותם. עליו גם להסיר ידנית את הקבצים הזדוניים, כי מחיקת החבילה עצמה אינה מספיקה, ולבדוק את יומני הפעילות כדי לאתר שימוש חשוד בתקופת החשיפה. לפי דיווחים, בין החברות שנפגעו מהתקרית הראשונה נמנית גם Mercor, חברת גיוס מבוססת AI שמתוארת בערך נפרד באתר הזה. שתי התקריות הפכו את LiteLLM לדוגמה שחוזרת בדיוני אבטחה על התלות הגוברת של תעשיית ה-AI בכלי תיווך יחיד בקוד פתוח.

למה זה נוגע גם למי שלא מתקין LiteLLM בעצמו

משתמש קצה שמדבר עם צ'אטבוט או עם סוכן AI כלשהו בעבודה בדרך כלל לא יודע אם מתחת לפני השטח יושב שער כמו LiteLLM, שמנתב את הבקשה שלו לספק המודל המתאים. ככל שיותר חברות מרכיבות מערכות AI משכבות תיווך מוכנות כאלה, במקום לכתוב אינטגרציה נפרדת לכל ספק, כך גדל מספר השירותים שתלויים באבטחה של אותה שכבה אחת, בלי לדעת זאת במפורש. שתי התקריות של LiteLLM ב-2026 הן דוגמה מוחשית לכך. התוקף לא תקף יישום AI ישירות, אלא את התשתית המשותפת שמאחורי יישומי AI רבים שאין ביניהם קשר. זו הסיבה שחברות אבטחה מתייחסות היום לרשימת התלויות (dependencies) של מערכת AI כחלק מתמונת הסיכון שלה, ולא רק לקוד שהצוות הפנימי כתב בעצמו.