ב- 26 באוגוסט בשנה פורסמו שתי חולשות אבטחה חמורות בספריית הנגן mwEmbed של Kaltura, המופצת גם בשם html5lib. CVE-2026-19912 קיבלה מחוק הסייבר שגילה אותה ציון CVSS של 10.0 וזהו הציון המרבי האפשרי. היא מאפשרת הרצת קוד מרחוק על השרת. CVE-2026-19913, בציון 9.1, מאפשרת קריאת קבצים מתוך השרת. שתיהן אינן דורשות משתמש, סיסמה או טוקן. די בגישת רשת לנקודת הקצה הפגיעה. הנתון המדאיג באמת אינו הציון: חמישה חודשים אחרי הדיווח הראשון עדיין אין טלאי. ב- CERT/CC מסרו שלא הצליחו ליצור קשר עם היצרן כדי לתאם תיקון.
מה בדיוק שבור בקוד
נקודת הקצה mwEmbedLoader.php מקבלת פרמטר בשם ServiceUrl ומשתמשת בו ככתובת שאליה פונה השרת כדי למשוך נתונים. המחלקה שמבצעת את הפנייה – KalturaClientBase, מעבירה את מה שחזר מאותה כתובת ישירות לפונקציה unserialize של PHP, בלי לבדוק מהו המקור, מהו הפרוטוקול או מה התוכן. זהו כשל קלאסי של deserialization לא בטוח: השרת בונה אובייקטים חיים בזיכרון מתוך מחרוזת שהתוקף שולט בה במלואה.
מכאן נפתחות שתי דרכי ניצול. בראשונה מציב התוקף בפרמטר כתובת מסוג file://. השרת שולף קובץ מקומי במקום תשובת API, ניסיון הפענוח נכשל, אך הודעת השגיאה שחוזרת מכילה את תוכן הקובץ הגולמי. החוקר הדגים זאת על קובץ התצורה local.ini של Kaltura, שהכיל מחרוזות התחברות למסד הנתונים, סיסמאות מנהל וקונסולה והפניות לשרתים פנימיים, הכול בטקסט גלוי.
בדרך השנייה מפנה התוקף את אותו פרמטר לאובייקט PHP זדוני שהכין מראש. פרמטר נוסף בשם uiconf_id נושא רצף מעבר תיקיות, שמסיט את כתיבת קובץ המטמון אל תיקייה נגישה מהאינטרנט. פנייה ישירה לקובץ שנוצר מריצה אותו בהרשאות משתמש שרת הווב. שלב הכתיבה תלוי במנגנון מטמון מבוסס קבצים, שהוא ברירת המחדל של Kaltura. תצורת memcache בלבד עשויה לחסום דווקא את הנתיב הזה, אך אין בכך כדי להפוך את ההתקנה לבטוחה.
שלוש עובדות שהופכות את המקרה לחריג
- ראשית, הקוד הפגיע כמעט לא השתנה מעולם. הקריאה המסוכנת ל- unserialize קיימת בקוד מאז מרץ 2014. הקובץ המכיל אותה זהה בית-אחר-בית ב- 21 גרסאות שיצאו בין אפריל 2015 לאוגוסט 2026.
- שנית, לפי CERT/CC נקודת הקצה חשופה לא רק בהתקנות עצמאיות של לקוחות אלא גם על תשתית ה- CDN המשותפת של Kaltura. המשמעות היא שהחשיפה נוגעת לכל דייר שאותו משרתים אותם שרתים משותפים, גם אם מעולם לא התקין דבר בעצמו.
- שלישית, אין למי לפנות. ציר הזמן שפרסם החוקר מתעד דיווח ראשון ב- 23 במרץ, שליחה חוזרת מכתובת ארגונית ב- 13 באפריל, פנייה ל- CISO דרך לינקדאין ב- 23 במאי, הסלמה ל- CERT לאומי ב- 2 ביולי, פנייה של CERT/CC ליצרן ב- 8 ביולי. נכון ל- 25 באוגוסט סטטוס היצרן רשום כ"לא ידוע, לא התקבלה תגובה". לשתי החולשות אין עדיין רשומה ב- NVD. הן אינן מופיעות בקטלוג הניצול הפעיל של CISA. עד כה לא דווח על ניצול בפועל.
המשמעות לארגון שלכם
פלטפורמות וידאו יושבות בנקודה עיוורת קלאסית. הן נתפסות כ"תוכן" ולא כ"מערכת ליבה". הבעלות עליהן נמצאת לא פעם אצל השיווק, משאבי אנוש או מערך ההדרכה, לא אצל צוות ה- IT. התוצאה היא שרת החשוף לאינטרנט, אשר מדבר עם אחסון פנימי ועם מסדי נתונים, בלי שאיש מרגיש אחראי לעדכן אותו.
הסיכון המיידי אינו הווידאו. חולשת קריאת הקבצים מחזירה לתוקף את קובץ התצורה עם סיסמאות מסד הנתונים, סיסמאות המנהל וכתובות השרתים הפנימיים, כלומר היא מספקת נקודת זינוק לתנועה רוחבית ברשת. חולשת הרצת הקוד מעניקה web shell על שרת שיושב בדרך כלל בקצה, במקום שממנו קצרה הדרך פנימה.
נקודה נוספת: מכיוון שאין רשומה ב- NVD ואין הופעה בקטלוג של CISA, עלולים סורקי חולשות אוטומטיים ולוחות מחוונים של ניהול טלאים להציג "אין ממצא". שקט בלוח המחוונים אינו עדות להיעדר סיכון.
010 אבטחת סייבר
- מקרה שבו אין טלאי כלל הוא בדיוק המקום שבו ניהול סיכונים מקצועי מוכיח את עצמו: סקר סיכונים הוא הצעד הראשון. צריך למפות אילו נכסים של הארגון חשופים לאינטרנט, כולל מערכות מדיה, הדרכה ושיווק שאיש אינו רושם כ"מערכות מחשוב". הבדיקה הקונקרטית פשוטה: האם נקודת הקצה הפגיעה נגישה מבחוץ. שאלה שנייה, לא פחות חשובה: מי בארגון אחראי עליה בכלל?
- עדכוני תוכנה ואבטחה פועל כאן במתכונת הפוכה. אין גרסה מתוקנת להתקין. לכן העבודה כולה מתמקדת בבקרות מפצות: חסימת נקודת הקצה ב- WAF, ב- proxy או ב- CDN במקומות שבהם הנגן הישן ממילא אינו בשימוש; הגבלת ServiceUrl לכתובת ה- API של הארגון בלבד ודחיית פרוטוקולים שאינם HTTP או HTTPS; דחיית ערכי uiconf_id עם רצפי מעבר תיקיות; מניעת הרצת PHP בתיקיות המטמון; הגבלת התעבורה היוצאת משרת האפליקציה, שנתיב הרצת הקוד תלוי בה כדי למשוך את המטען.
- מניעת דלף מידע (DLP) רלוונטית ישירות, משום שחולשת קריאת הקבצים היא במהותה ערוץ הוצאת מידע. בנוסף, כל סוד שנחשף בקובץ התצורה חייב להתחלף: סיסמאות מסד הנתונים והמנהל, מפתחות API וסודות שותפים.
- SIEM/SOC נדרש כאן לזיהוי התנהגותי ולא לחתימות: תעבורה חריגה היוצאת משרת הווידאו, קבצים חדשים בתיקיות המטמון, או תגובות שגיאה המכילות תוכן קונפיגורציה.
- מודיעין סייבר משלים את התמונה. כל עוד היצרן שותק, מישהו צריך לעקוב אחרי הרגע שבו יתפרסם טלאי או יתחיל ניצול פעיל, בדיוק משום שהמקורות האוטומטיים הרגילים אינם מכסים את המקרה.
השורה התחתונה חורגת מ- Kaltura עצמה. ארגון הנשען כולו על "היצרן מוציא עדכון, אנחנו מתקינים" נשאר חסר הגנה ברגע שהיצרן אינו מגיב. היכולת לזהות חשיפה, לחסום אותה בשכבות שבשליטתכם ולנטר את מה שנשאר פתוח היא ההבדל בין סיכון מנוהל להפתעה.
למקור הידיעה ולקריאה נוספת לחצו כאן
