שרת Jenkins הוא המקום שבו קוד הופך לתוכנה שרצה בייצור, ולכן הוא מחזיק בדרך כלל את מפתחות הגישה לכל השאר. לפי הרשומה, בגרסאות עד 2.56 ועד LTS 2.46.1 אפשר היה להריץ עליו קוד מרחוק בלי שום הזדהות, על ידי שליחת אובייקט Java אל ממשק שורת הפקודה שלו. הציון הוא 9.8 מתוך 10.

מה החולשה?

כשתוכנית צריכה להעביר אובייקט לתוכנית אחרת, היא מפרקת אותו לרצף בתים. בצד המקבל מתבצע התהליך ההפוך, והאובייקט מורכב מחדש מתוך אותם בתים. בעולם Java קוראים לשתי הפעולות serialization ו-deserialization, ולשנייה יש תכונה שקל לפספס: ההרכבה מחדש אינה העתקה פסיבית של נתונים, היא מפעילה קוד ששייך למחלקה של האובייקט.

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

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

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

מי מושפע?

הרשומה מסמנת את Jenkins בגרסאות 2.56 ומטה ואת גרסאות ה-LTS 2.46.1 ומטה. לצידן היא מסמנת גם מוצר של אורקל, Communications Cloud Native Core Automated Test Suite בגרסה 1.9.0.

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

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

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

כן. החולשה נכנסה ב-2 באוקטובר 2025 לקטלוג ה-KEV, הרשימה שמנהלת סוכנות הסייבר האמריקאית CISA ומאגדת חולשות שידוע כי נעשה בהן שימוש בתקיפות אמיתיות. המועד שנקבע לגופים הפדרליים האמריקאיים לסיים את הטיפול היה 23 באוקטובר 2025.

לוח הזמנים כאן מספר סיפור בפני עצמו. Jenkins פרסמה את הודעת האבטחה שלה ב-26 באפריל 2017, הרשומה נכנסה ל-NVD רק ב-29 בינואר 2018, ובין לבין קוד ניצול פומבי כבר היה זמין. הרשומה מפנה אל מאגר Exploit Database ואל פרסום ב-Packet Storm.

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

מה עושים?

עדכנו, וכדאי להכיר את שלושת הדברים שהרשומה מתארת בתיקון. SignedObject נוסף לרשימת החסימה. פרוטוקול ה-CLI החדש, זה שמבוסס HTTP, הועבר אחורה מגרסה 2.54 אל LTS 2.46.2. ופרוטוקול ה-CLI הישן, זה שנשען על serialization של Java, הוכרז כמיושן וכובה כברירת מחדל.

מי שנמצא על מסלול ה-LTS צריך להגיע ל-2.46.2 לכל הפחות, ומי שאינו עליו צריך לעבור את 2.56. הודעת האבטחה של Jenkins מ-26 באפריל 2017 היא המקור לפרטים המדויקים.

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

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

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