CVE-2026-85706 ב-GitLab מנוצלת בפועל — עדכנו מיד התקנות בניהול עצמי

השורה התחתונה: לעדכן עכשיו

CVE-2026-85706 היא חולשת מעבר נתיבים (path traversal) בחומרת מקסימום ב-GitLab Community Edition ו-Enterprise Edition בהתקנות בניהול עצמי. דירוגה הוא CVSS 3.1 של 10.0. בנסיבות מסוימות, תוקף שאינו נדרש להזדהות יכול לקרוא קבצים שרירותיים מהשרת שעליו פועל GitLab. זו אינה סכנה תיאורטית בלבד: CISA, סוכנות הסייבר האמריקאית, צירפה את החולשה לקטלוג KEV שלה — קטלוג החולשות שיש ראיות לניצולן בעולם האמיתי — וחוקרים דיווחו על סריקות מול מערכות חשופות לאינטרנט זמן קצר לאחר פרסום התיקון. 32122

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

• 19.1.8 או חדשה יותר
• 19.2.6 או חדשה יותר
• 19.3.2 או חדשה יותר

הגרסאות הפגיעות הן GitLab CE/EE מ-18.7 ועד לפני 19.1.8, מ-19.2 ועד לפני 19.2.6, ומ-19.3 ועד לפני 19.3.2. GitLab פרסמה את התיקונים ב-10 בספטמבר 2026. 37

מה מאפשרת החולשה

מקור הבעיה הוא ב-Repository Commits API של GitLab: שילוב של הגבלה לא תקינה על נתיבים הנשלטים בידי המשתמש ואכיפת הזדהות חסרה. השילוב עשוי לאפשר לבקשה ללא הזדהות לקרוא קבצים שהגישה אליהם מותרת לשירות GitLab. 3

ההשפעה העיקרית היא חשיפת קבצים. המידע הקיים אינו מוכיח ש-CVE-2026-85706 לבדה מעניקה הרצת קוד מרחוק. עם זאת, קריאה של קבצים שרירותיים עלולה לחשוף את החומרים הדרושים לפגיעה בהמשך — בהתאם לתצורת השרת — כגון הגדרות יישום, אסימונים, מפתחות SSH, פרטי גישה למסד נתונים וסודות אחרים שנגישים לתהליך GitLab. 925

מדוע יש להתייחס לאירוע כאיום פעיל

חברת watchTowr דיווחה על זיהוי ניסיונות בדיקה בעולם האמיתי, לרבות ברשת ה-honeypot שלה ב-11 בספטמבר. גם ההוספה ל-KEV של CISA היא אות אזהרה משמעותי: מטרת הקטלוג היא לסמן חולשות שיש עדות לכך שהן מנוצלות בפועל. 222

CISA הוסיפה את CVE-2026-85706 לקטלוג ב-11 בספטמבר וקבעה ל-14 בספטמבר מועד לביצוע פעולה עבור סוכנויות פדרליות אזרחיות מכוסות בארה״ב. המועד אינו מחייב אוטומטית ארגונים פרטיים, אך הוא משקף היטב את דחיפות הסיכון לכל התקנת GitLab בניהול עצמי שחשופה לאינטרנט. 3

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

להתייחס לשרת חשוף כאירוע אפשרי של חשיפת סודות

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

תעדפו בדיקה והחלפה של אישורים וסודות שעשויים היו להיות נגישים, ובהם:

• סודות היישום וקובצי התצורה של GitLab;
• פרטי גישה למסד נתונים, Redis, אחסון אובייקטים, registry, SMTP, שירות ספריות וספקי זהות השמורים בתצורה;
• משתני CI/CD, אסימוני פריסה וגישה, אסימוני runners, מפתחות פריסה ואישורים שממופים למשימות או לאינטגרציות;
• מפתחות ענן, אישורי package registry, מפתחות חתימה ומפתחות פרטיים של SSH או TLS שהיו נגישים למארח או לתהליך GitLab.

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

חקירה וזיהוי: איפה לחפש

אינדיקטור ראשוני שימושי הוא בקשת HTTP מסוג POST לנתיב ה-Repository Commits API:

/api/v4/projects/<id>/repository/commits/

דיווחים ממליצים במיוחד לחפש בקשות הכוללות את הפרמטר file.path. בדקו לוגים של reverse proxy, מאזן עומסים, WAF ו-GitLab Rails לאיתור בקשות חריגות ללא הזדהות, קלטים מקודדים שנראים כמו מעבר נתיבים, מזהי פרויקטים לא צפויים, כשלונות חוזרים, דפוסי מִספּוּר/סריקה או גדלי תגובה חריגים. 212426

בדקו גם פעילות שעשויה להיות קשורה לאחר חלון החשיפה: יצירה או שימוש באסימונים חדשים, רישומי runner, שינויי משתני CI/CD או הגדרות pipeline, ייבואים חריגים, פעילות GraphQL וחיבורים יוצאים בלתי צפויים. ההנחיות שפורסמו סביב העדכון קוראות גם לבחון commits, מינויים ל-GraphQL, ייבוא פרויקטים ו-pipelines של CI/CD. 23

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

אם העדכון מתעכב: צעדי צמצום זמניים

שדרוג הוא התיקון הנדרש. אם עדכון חירום אינו אפשרי מיידית, צמצמו את החשיפה באמצעות הגבלת הגישה לשירותי ה-web וה-API של GitLab ל-VPN או לרשתות מאושרות בלבד. כלל ב-reverse proxy או ב-WAF שמגביל בקפדנות את נתיב ה-Repository Commits API עשוי להפחית סיכון בטווח הקצר, אך עלול לשבור אוטומציות תקינות ואינו תחליף לעדכון.

סדר הפעולות המעשי לכל שרת פגיע:

1. לזהות ולתעדף התקנות בניהול עצמי החשופות חיצונית.
2. לשדרג ל-19.1.8, ל-19.2.6, ל-19.3.2 או לגרסה חדשה יותר.
3. לוודא את הגרסה הפועלת בפועל לאחר השינוי.
4. לשמר ולבדוק לוגים לאינדיקטורים של ניסיון ניצול.
5. להחליף סודות שעלולים להיחשף, לפי הגישה שהייתה לשרת וההשפעה העסקית.

שתי חולשות נוספות באותו עדכון

בדיווחי האבטחה על אותה מהדורה תוארו גם שתי בעיות ב-Enterprise Edition:

• CVE-2026-87719: חולשת deserialization לא מאובטח לאחר הזדהות, בדירוג CVSS של 9.9; בחלק מהדיווחים היא קשורה לחשיפת תצורת Advanced Search ואישורים. 6
• CVE-2026-88765: סיכון להרצת קוד מרחוק לאחר הזדהות, בעת ייבוא export זדוני של פרויקט Git, בדירוג CVSS מדווח של 8.5. 625

לחולשות אלה תנאי קדם והשפעות שונים מאלה של CVE-2026-85706. עבור התקנות GitLab בניהול עצמי החשופות לאינטרנט, חולשת קריאת הקבצים ללא הזדהות — שכבר מנוצלת בפועל — צריכה להיות עדיפות הבלימה והתגובה הראשונה.