פרצת CVSS 10.0 בגיטלאב: מה עסקים שמריצים שרתי פיתוח עצמאיים חייבים לבדוק עכשיו

בתחילת אוקטובר 2026 חשפה גיטלאב (GitLab) פרצה בדירוג חומרה מקסימלי - CVSS 10.0 - בגרסאות השרת העצמאי (Self-Managed) של המערכת. מדובר בפרצת הרצת קוד מרחוק שלא מצריכה הזדהות כלל, כלומר תוקף יכול להשתלט על שרת גיטלאב בלי לדעת שם משתמש או סיסמה. ה-CISA האמריקאי אישר שהפרצה מנוצלת בפועל בשטח, והוסיף אותה לרשימת הפרצות המנוצלות באופן פעיל. עבור עסקים רבים בישראל שמריצים גיטלאב משלהם לניהול קוד, פרויקטים ותשתיות פיתוח, זה לא עדכון טכני שאפשר לדחות - זה חור פתוח לכל מה שהחברה בונה.

מה בדיוק קרה

הפרצה, המתועדת כ-CVE-2026-97229, נמצאת במנוע הביטויים הרגולריים (Regex) שגיטלאב משתמשת בו כדי לנתח קובצי הגדרה של תהליכי CI/CD - התהליכים האוטומטיים שבונים, בודקים ומפרסמים קוד. באג של גלישת מספרים (integer overflow) במנוע הזה, שמקורו בספריית Onigmo של שפת Ruby, מאפשר לתוקף לשלוח קלט מיוחד שגורם לשרת להריץ פקודות משלו. התוצאה: השתלטות מלאה על השרת, בלי צורך בחשבון משתמש ובלי אינטראקציה מצד אף אחד בתוך הארגון. גיטלאב שחררה תיקון בגרסאות 19.4.2, 19.3.5 ו-19.2.8 ב-12 באוקטובר, וכל הגרסאות שלפני כן נחשבות חשופות.

למה זה מסוכן לעסקים

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

מי בסיכון ומי לא

חשוב להבהיר: הפרצה נוגעת רק למי שמריץ גיטלאב בשרתים שלו (Self-Managed) - כלומר רוב הפתרון מותקן "בבית" או על שרת ענן בניהול עצמי של החברה. עסקים שמשתמשים בגרסת ה-SaaS הרגילה, כזו שרצה בענן של גיטלאב עצמה (gitlab.com), לא נדרשים לעשות דבר, כי גיטלאב מתחזקת ומעדכנת את התשתית הזו ישירות. הסיכון הגדול הוא לחברות טכנולוגיה, סטארט-אפים וצוותי פיתוח פנימיים בעסקים גדולים יותר, שבחרו להריץ את גיטלאב בעצמם מטעמי עלות, פרטיות או התאמה אישית - ודווקא אלה שמריצים גרסאות ישנות או לא מעדכנים באופן שוטף הם הפגיעים ביותר.

מה עושים עכשיו

הצעד הראשון והחשוב ביותר הוא לבדוק את גרסת גיטלאב המותקנת ולעדכן אותה לגרסה המתוקנת העדכנית, אם עדיין לא נעשה כך. חברות שמנהלות צוות IT או ספק ענן חיצוני צריכות לפנות אליו מיידית ולוודא שהעדכון בוצע בכל סביבה - פיתוח, בדיקות וייצור כאחד. כדאי גם לבדוק יומני גישה (logs) לאיתור פעילות חשודה מהתקופה שבה הפרצה הייתה פתוחה, ולשקול סריקת אבטחה שתאשר שלא בוצעה חדירה בזמן הזה. ככלל, מומלץ שלא לחשוף שרתי ניהול קוד פנימיים לאינטרנט הפתוח ללא הגנה נוספת, כגון רשת VPN פנים-ארגונית או מנגנון אימות רב-שלבי בשער הכניסה.

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