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

מדובר ב-CVE-2026-63077, חולשה בציון 9.8 בשרת ה-CI/CD TeamCity, שמאפשרת לתוקף בלי שם משתמש וסיסמה להריץ פקודות מערכת הפעלה על השרת. ההתרעה יצאה ב-27 ביולי 2026. שנים עשר יום אחר כך, ב-8 באוגוסט, התחילה פעילות תוקפים על api.cadence.jetbrains.com, שרת שהריץ TeamCity ולא עודכן. דיווח האירוע של JetBrains, שעודכן לאחרונה ב-3 בספטמבר, מתאר מה נמצא שם. נעבור על החולשה עצמה, על מה שהתוקפים הוציאו, ועל הפרט שהופך את האירוע הזה למעניין: מה שהחזיק את פרטי האימות לא היה הסביבה החיה אלא גיבוי בן שנתיים.

מה זה Cadence, ולמה יושב בתוכו שרת CI

Cadence הוא שירות שמריצה JetBrains בענן שלה. מפתחי Python מתקינים תוסף אופציונלי ב-PyCharm, מסנכרנים אליו את הפרויקט, והקוד רץ על משאבי מחשוב מרוחקים במקום על המחשב המקומי. שימוש טיפוסי הוא אימון של מודל למידת מכונה שדורש חומרה שאין למפתח על השולחן.

מי שמתזמר את ההרצות האלה בצד השרת הוא TeamCity, מוצר ה-CI/CD של JetBrains עצמה. שרת CI (Continuous Integration, השרת שבונה ומריץ את הקוד אוטומטית בכל שינוי) הוא אחד היעדים השווים ביותר ברשת ארגונית, מסיבה פשוטה: כדי לעשות את העבודה שלו הוא חייב להחזיק את המפתחות לכל השאר. פרטי גישה לענן, token-ים ל-GitHub, סיסמאות ל-registry של קונטיינרים, מפתחות חתימה. מי שמגיע לשרת הזה כבר לא צריך לפרוץ לשום מקום אחר.

אז למה רשימת ההיתר לא הגבילה כלום?

סוכני הבנייה של TeamCity, המכונות שמריצות בפועל את משימות הבנייה, מדברים עם השרת בפרוטוקול משלהם. חלק מהתקשורת הזאת מגיעה כ-XML, והשרת מפרסר אותו ובונה ממנו בחזרה אובייקטים בזיכרון בעזרת ספריית XStream. הסכנה בבנייה כזאת ידועה שנים: אם התוקף שולט בתוכן ה-XML, הוא בעצם מכתיב אילו מחלקות קוד השרת ייצור, ובשרשור המתאים ביניהן אפשר להגיע מזה להרצת פקודות. לכן ספריות כאלה עובדות מול רשימת היתר שקובעת אילו מחלקות מותר לבנות, וכל השאר נדחה. לחולשות מהסוג הזה קוראים deserialization של מידע לא מהימן, והן מסווגות תחת CWE-502.

TeamCity אכן הגדירה רשימה כזאת. היא פשוט הוסיפה אותה על גבי מה שכבר היה שם. הניתוח של Rapid7, שכתב סטיבן פיוור (Stephen Fewer) ב-7 באוגוסט, מראה שה-constructor של XStream כבר הריץ קודם setupSecurity, שמתיר מראש היררכיות טיפוסים רחבות כמו Map ו-Throwable. הקריאות של TeamCity שהוסיפו את מחלקות הפרוטוקול שלה נערמו על ההיתרים הקיימים במקום להחליף אותם. התוצאה היא רשימה שנראית כמו הגבלה ולא מגבילה, כי ברירת המחדל הרחבה נשארה פתוחה מתחתיה.

ה-endpoint שדרכו זה עובד, לפי Rapid7, הוא /app/agents/v1/commands/error. הוא בודק כותרת של מזהה סשן סוכן, אבל אינו דורש אימות בפועל, ומעביר את גוף הבקשה הלאה לפירסור. התיקון בגרסה 2026.1.3 לא מוסיף עוד חוקים לרשימה; הוא מאפס את ההיתרים לפני שממלאים אותה מחדש, וכך היא הופכת לבלעדית באמת.

מהתיקון ועד הפריצה

החולשה דווחה ל-JetBrains ב-10 ביולי 2026 בגילוי מתואם, על ידי חוקר בשם אנטוני טרמבליי (Antoni Tremblay). ההתרעה יצאה ב-27 ביולי, יחד עם גרסאות 2025.11.7 ו-2026.1.3 ותוסף תיקון לגרסאות 2017.1 ומעלה עבור מי שאינו יכול לשדרג. כל גרסאות TeamCity On-Premises חשופות; לקוחות TeamCity Cloud לא נדרשו לפעולה.

ב-5 באוגוסט הכניסה CISA את החולשה לקטלוג ה-KEV, רשימת החולשות שידוע שמנוצלות בשטח, עם תאריך יעד לתיקון ב-8 באוגוסט. שלושה ימים. ב-7 באוגוסט פרסמה JetBrains עדכון להתרעה ובו כתבה שהתקבלו דיווחים על ניצול פעיל ועל ניסיונות ניצול נגד שרתים לא מעודכנים.

ב-8 באוגוסט, אותו יום שבו פג תאריך היעד של CISA, מתחילה פעילות התוקפים ב-Cadence. היא נמשכת עד שהחברה מגלה אותה ב-23 באוגוסט ומורידה את השרת מהאוויר למחרת. שישה עשר יום בפנים.

מי עמד מאחורי המתקפה לא ידוע. CISA לא ייחסה את הניצול לגורם מסוים, JetBrains לא נקבה בשם, ורשימת סימני הפריצה (IoC) שפרסמה כוללת שש כתובות IP בלבד. אז כשקוראים על האירוע הזה, שווה לזכור שהחלק היחיד שמתועד לעומק הוא מה שקרה בפנים, לא מי עשה את זה.

מה נלקח, ולמה הגיבוי מ-2024 הוא הסיפור

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

החלק השני מעניין יותר. התוקפים השיגו גיבוי מלא של שרת Cadence משנת 2024, ובתוכו היו פרטי אימות. מכאן הגיעו כמה משתמשי IAM של AWS שנפרצו, כולל משתמשים ששייכים לעובדי JetBrains שהשתמשו בשירות, ואיתם ניגשו התוקפים לקבצים ב-S3 buckets בחשבונות ה-AWS של החברה. כלומר הרצת הקוד על השרת הייתה רק הכניסה. מה שהפך אותה לחילוץ פרטי אימות היה קובץ ארכיון בן שנתיים ששכב שם.

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

ההערכה של JetBrains גם זזה תוך כדי. ב-31 באוגוסט כתבה החברה שאין ראיה לכך שהתוקפים חילצו מידע, כולל סודות, מהסביבה הנוכחית של Cadence, ושמה שאושר הוא הגישה לגיבוי מ-2024. בעדכון מ-3 בספטמבר, שבו הודיעה שהחקירה הסתיימה, הניסוח השתנה: התוקפים השיגו גישה שיכלה לאפשר להם להגיע לאחסון של הסביבה הנוכחית, ובו כתובות מייל, קוד מקור של פרויקטים ופרטי אימות. החברה מציינת שלא זוהו נפגעים נוספים מעבר לאותה קבוצת משתמשים שכבר קיבלה פנייה ישירה, ושהיא מתייחסת למידע הזה כאל חשוף מטעמי זהירות. מי שקרא רק את העדכון של ה-31 באוגוסט קיבל תמונה מקילה ממה שהתקבע בסוף.

למשתמשי Cadence עצמם ההנחיה חדה: לבטל ולסובב כל פרט אימות שהיה בשימוש בהרצות, לעבור על מערכות מקושרות (חשבונות AWS, S3 buckets, סביבות deployment ו-registry-ים של חבילות וקונטיינרים), ולהתייחס לקוד שסונכרן מ-PyCharm אל השירות, ולכל מפתח שמוטמע בתוכו, כאל חשוף.

מה לבדוק אם אתם מריצים TeamCity

אם יש לכם שרת TeamCity On-Premises, שתי בדיקות שוות את הזמן. הראשונה היא בלוגים של השרת: JetBrains ממליצה לחפש הודעות מסוג com.thoughtworks.xstream.converters.ConversionException. ההודעה לבדה אינה מוכיחה פריצה, אבל היא סימן לניסיון ניצול ומצדיקה בדיקה. בשרת שכבר תוקן, הודעה מסוג com.thoughtworks.xstream.security.ForbiddenClassException מצביעה על ניסיון שנחסם, כלומר מישהו ניסה ונדחה אחרי שהעדכון כבר היה שם.

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

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

מה זה אומר בפועל

מי שמריץ TeamCity On-Premises בגרסה שאינה 2025.11.7 או 2026.1.3, ובלי תוסף התיקון, צריך לסגור את זה היום. החולשה בקטלוג ה-KEV מאז 5 באוגוסט, וידוע שהיא מנוצלת. אחרי העדכון מגיעה השאלה השנייה, והיא חשובה לא פחות: אילו פרטי אימות היו נגישים לשרת הזה עד לרגע שתיקנתם, ומתי סובבתם אותם לאחרונה. ואם אתם שומרים גיבויים של שרתי CI, פתחו אחד ותראו מה יש בו, כי אצל JetBrains דווקא הקובץ הישן היה זה שהחזיק את המפתחות.