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

מה החולשה?

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

כשמאפשרים ל-webhook לפנות גם לכתובות ברשת הפנימית, וזו הגדרה שקיימת במערכת, הפנייה הזאת הופכת לכלי. הרשומה מתארת שתוקף לא מאומת יכול היה לגרום לשרת לבצע פנייה כזאת, כלומר להשתמש בו כדי להגיע למקומות שהוא עצמו אינו יכול להגיע אליהם מבחוץ. הסיווג הוא CWE-918.

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

מי מושפע?

כל שרת GitLab מגרסה 10.5.0 שלא הגיע לאחת מגרסאות התיקון: 13.6.7 בענף שעד 13.6, 13.7.7 בענף 13.7, ו-13.8.4 בענף 13.8.

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

האם מנוצלת בפועל?

כן. ב-18 בפברואר 2026 נכנסה החולשה לקטלוג ה-KEV של CISA, סוכנות הסייבר האמריקאית, שמרכזת בו חולשות שידוע שתוקפים משתמשים בהן בשטח, עם מועד תיקון לגופים פדרליים עד 11 במרץ 2026.

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

מה עושים?

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

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

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

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