Michael Johnsonאם עדכנתם את Git בטרמינל, העבודה עדיין לא הסתיימה: יישומים וסביבות בנייה נפרדים עשויים להפעיל עותק משלהם. ב-10 בנובמבר 2026 פרויקט Git פרסם תיקונים לשש חולשות — החל בהרצת קוד בעת שכפול רקורסיבי ועד לפגיעה בזיכרון במהלך מיזוג. לכן צריך לבדוק כל סביבה שמעבדת מאגרים או את תוכנם, ולא רק את התוצאה של הפקודה git --version במעטפת שלכם.
מה השתנה בעדכון
התיקונים נכללו ב-Git 2.56.1 והוחלו גם בענפים הנתמכים: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 ו-2.50.2. העדכון מתקן שש בעיות בחלקים שונים של Git — בטיפול בנתיבים, בקישורים, בחתימות, בטלאים בינאריים, במיזוגים ובזרמי ייבוא. GitHub פרסמה ב-10 בנובמבר ניתוח של החולשות והמלצה לעדכן; הערות ההפצה של Git 2.56.1 מפרטות את מזהי ה-CVE שתוקנו בסדרה זו.
המשמעות המעשית היא לעדכן את Git בשלושה מקומות: במחשבי העבודה, באוטומציה ובתוך יישומים הכוללים גרסת Git משלהם. קל לפספס דווקא את הנקודה האחרונה: עדכון חבילת המערכת אינו משנה אוטומטית את הגרסאות בכל לקוח או בכל תמונת בנייה.
למה כדאי לשים לב ל-clone רקורסיבי
שרשרת התקיפה הברורה ביותר מתחילה בשכפול רקורסיבי של מאגר שאינו מהימן. בגלל קיטוע אורך הנתיב, מחרוזת ארוכה מאוד יכלה לעבור בדיקה תחת שם אחד ואז להיכתב לדיסק כשהיא מקוצרת. בתרחיש שתואר עבור Git, הדבר אפשר להחליף את קובץ .git של תת-מודול בקישור סמלי לתיקייה שמכילה הגדרות או hooks זדוניים. בהמשך, כאשר Git היה ניגש אליה, הוא עשוי היה להריץ קוד שהגדיר התוקף.
חשוב להבהיר: מדובר במאגר שהוכן במיוחד ובפעולה המתאימה. צוותים שמשכפלים באופן קבוע פרויקטים ממקורות חיצוניים עם הפרמטר --recurse-submodules צריכים לתת עדיפות לעדכון סביבות הפיתוח והאוטומציה. התיקון דוחה נתיבים ארוכים מדי לפני שאורכם נקטע.
נקודות נוספות שבהן Git מעבד נתונים לא מהימנים
בעיה נוספת מתרחשת בשכפול מאגר ריק באמצעות Git protocol v2. השרת היה יכול לשלוח הפניה מסוג HEAD עם שם ענף הכולל רכיבים למעבר בין תיקיות; בהמשך, פעולת עדכון הענף הייתה יכולה לכתוב קובץ מחוץ לתיקיית ההפניות הצפויה. בגרסאות המתוקנות Git בודק יעד כזה ושמות הפניות נוספים שמתקבלים דרך הפרוטוקול.
חולשות נפרדות השפיעו על פעולות מיזוג ותיקון. בעת עיבוד חתימות, מערך בגודל קבוע הניח שיהיו לכל היותר שתי חתימות; הודעה שנבנתה במיוחד ובה מספר גדול יותר של חתימות הייתה יכולה לגרום לכתיבה מעבר לגבולות המערך ולפגיעה בזיכרון. בעת החלת טלאי בינארי, בדיקת הגודל התחשבה בייצוג המקורי, אף שנתונים דחוסים עשויים להתרחב לנפח גדול בהרבה. כעת Git בודק את הגודל הלא-דחוס המוצהר לפני העיבוד.
גם מיזוגים גדולים היו עלולים לגרום לגלישה בחישוב גודל המאגר הנדרש, ולאחר מכן לכתיבה מעבר לגבולותיו. הדבר נוגע גם לשירותי אירוח וליישומים הממזגים תוכן שאינו מהימן. לבסוף, שלוש אפשרויות של git fast-import הוגבלו עבור פקודות מזרם הקלט: rewrite-submodules-from ו-rewrite-submodules-to יכלו לקרוא קבצים שרירותיים, ואילו export-pack-edges יכלה ליצור קבצים או להוסיף נתונים לקבצים קיימים. כעת האפשרויות האלה חסומות אלא אם צוין במפורש הדגל --allow-unsafe-features; יש להשתמש בו רק עם מחולל זרמים מהימן.
היכן לחפש עותקים נפרדים של Git
למפתחים, כדאי להתחיל במיפוי המקומות שמהם Git מופעל. בדקו את הגרסה בטרמינל והשתמשו בבדיקת העדכונים המובנית של סביבת הפיתוח המשולבת ושל לקוחות Git שולחניים. לאחר מכן בדקו תמונות CI, קונטיינרים, runner-ים ומשימות שרת שמבצעים clone או merge, מחילים טלאים בינאריים או מפעילים fast-import. עצם קיומה של גרסת Git עדכנית במחשב המארח אינו מבטיח שהיישום משתמש דווקא בה.
בארגונים כדאי לבדוק לא רק את תמונות המקור אלא גם סביבות עבודה שכבר נפרסו: runner קבוע או שירות פנימי עשויים לשמור קובץ בינארי ישן גם לאחר עדכון תמונת הבסיס. עבור GitHub Enterprise Server, GitHub מציינת את הגרסאות המתוקנות 3.19.15, 3.20.11, 3.21.9 ו-3.22.4. החברה מסרה שכבר פרסה את התיקונים ב-github.com וב-GitHub Enterprise Cloud, לרבות אפשרויות אירוח נתונים. ההפצות של GitHub Desktop ושל GitHub Copilot app הכוללות Git מתוקן נמצאות בתיאום; גם גרסאות מתוקנות עבור Codespaces ו-GitHub Actions עדיין צפויות להתפרסם.
איך לצמצם את הסיכון עד לעדכון
אם אי אפשר להתקין את התיקון מיד, הגבילו זמנית פעולות עם נתונים לא מהימנים: שכפלו מאגרים רק משרתים מהימנים, הימנעו משכפול רקורסיבי של פרויקטים שלא נבדקו, אל תמזגו את תוכנם ואל תחילו טלאים בינאריים או זרמי fast-import שהתקבלו מהם. צעדים אלה מצמצמים את החשיפה לתרחישים הפגיעים המסוימים, אך אינם מחליפים עדכון.
המסקנה המעשית פשוטה: צריך לחפש את תיקון Git בכל מקום שבו התוכנה באמת מריצה את Git. הפקודה בטרמינל היא רק נקודה אחת כזאת; יש לבדוק בנפרד לקוחות פיתוח, CI ושירותים לעיבוד מאגרים.
