Argo CD הוא הכלי שמביא שינויים מ-Git אל אשכול Kubernetes, ובגרסאות מ-2.7.0 ואילך יש בו חולשה שמאפשרת להריץ פקודה בתוך הרכיב שמרכיב את המניפסטים, argocd-repo-server. הציון הוא 9.9 מתוך 10, ומה שהופך אותו לכזה הוא ההרשאה שנדרשת: לפי הרשומה די בהרשאת קריאה על Application אחד שקיים כבר. התיקונים הם 3.3.15, 3.4.10, 3.5.4 ו-3.6.0-rc2.

מה החולשה?

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

בפועל הערך הזה מגיע משדה ref או version בכתובת של משאב מרוחק בתוך קובץ Kustomize, והוא נמסר ל-git fetch. ל-git יש אפשרות בשם upload-pack, שתפקידה לציין איזו פקודה להריץ בצד השני של החיבור. תוקף שמכניס ערך שמתחיל במקף גורם ל-git לקרוא אותו כאפשרות הזאת, ואז הפקודה שהוא בחר רצה.

ושתי הערות ברשומה הן מה שמגדיר את התרחיש בדיוק. הראשונה: זה עובד רק כשהמשאב המרוחק מוגדר בתעבורה מקומית, למשל file://, ולא כשהוא כתובת https. הרשומה אומרת במפורש ש-git אינו מריץ את הפקודה שנמסרה לו כשמדובר ב-https.

השנייה מבטלת את ההגנה שמנהל מערכת היה מגיע אליה ראשון. תעבורה מקומית אינה יוצאת מה-pod בכלל, ולכן חסימת תעבורה יוצאת מה-repo-server אינה מונעת את ההרצה. ההגנה הזאת פשוט אינה נוגעת בבעיה.

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

מי מושפע?

הטווח שהרשומה נותנת הוא Argo CD מגרסה 2.7.0 ועד הגרסאות המתקנות: 3.3.15, 3.4.10, 3.5.4 ו-3.6.0-rc2. ארבעה ענפים נתמכים, תיקון לכל אחד.

אבל השאלה המעניינת כאן אינה הגרסה אלא ההרשאות, וזה החלק שכדאי לקרוא פעמיים. הרשומה מתארת שתי דרכים להכניס את הערך הזדוני. באחת התוקף מבצע commit של Kustomization למאגר Git שאיזה Application בונה ממנו. בשנייה הוא מעלה קבצים ישירות דרך הנקודה POST /api/v1/applications/manifestsWithFiles, שנחשפת גם דרך הפקודה argocd app diff עם הדגלים local ו-server-side-generate.

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

עוד פרט שחשוב לא לפספס: הרשומה מציינת שהחלפת Kustomize בגרסה חדשה יותר אינה מתקנת את החסר במפריד. היא גם מסבירה איך נוצר המצב הזה, ש-Kustomize 5.0.0 התחילה לקבל file:// בעוד 4.5.7 דחתה את התעבורה הזאת. מי שיחשוב שעדכון Kustomize פותר את העניין יישאר חשוף.

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

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

לפי המצב בעדכון האחרון של הרשומה, ב-20 באוקטובר 2026, לא ידוע על ניצול בפועל. החולשה אינה מופיעה בקטלוג ה-KEV שמנהלת CISA, סוכנות הסייבר האמריקאית, ובו נרשמות חולשות שהניצול שלהן אומת.

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

מה עושים?

1. בדקו באיזו גרסה אתם. את המספר אפשר לראות בפקודה argocd version, או בתג של התמונה בפריסה argocd-repo-server באשכול. כל גרסה מ-2.7.0 ואילך שאינה אחת מהמתוקנות חשופה.

2. עדכנו לפי הענף שלכם: 3.3.15, 3.4.10, 3.5.4 או 3.6.0-rc2. דף השחרור של 3.3.15 הוא נקודת הפתיחה.

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

4. אל תסתמכו גם על חסימת תעבורה יוצאת מה-repo-server. ההרצה מתבצעת בתעבורה מקומית שאינה עוזבת את ה-pod, ולכן החסימה אינה נוגעת בה.

5. עד שהעדכון מותקן, עברו על מי שיש לו הרשאת get על Application במערכת. זאת ההרשאה היחידה שהניצול דורש בדרך ההעלאה, והיא בדרך כלל ההרשאה הרחבה ביותר שחולקה. צמצמו אותה למי שבאמת צריך.

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