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

את הדפוס הזה מתארים חוקרי Wiz Research בדוח שפרסמו ב-10 בספטמבר. שחר דורפמן, שון ג'ונסטון, זוהר קפלן וקורט ג'אקינו כותבים שהם זיהו ניצול פעיל בשטח של שלוש חולשות ב-JFrog Artifactory, ובלב הדוח שרשרת של שתיים מהן שאף אחת לבדה לא נחשבה מסוכנת במיוחד. חלון הניצול שהם מתעדים נמשך בין ה-15 באוגוסט ל-8 בספטמבר. נעבור על מה שכל חולשה עושה, נראה למה דווקא שורת הלוג היא הבעיה הגדולה של המגינים, ונגיע למספרים שמסבירים כמה שרתים נשארו פתוחים.

המחסן שכל חברת תוכנה בונה ממנו

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

מי שמשתלט על שרת כזה לא רק קורא ממנו. הוא גם יכול לכתוב אליו, כלומר להכניס גרסה מורעלת של רכיב שכל שאר המערכות בארגון מושכות אוטומטית בבנייה הבאה. האתר כבר סיקר בתחילת החודש גל ניצול של חולשה שלישית באותו מוצר, CVE-2026-82329 בציון 9.8, שמאפשרת השתלטות בבקשה אחת. הדוח החדש עוסק במשהו אחר: שתי חולשות שקיבלו ציונים נמוכים יותר, לא נכנסו לרשימת החובה של CISA, ובדיוק בגלל זה נשארו פתוחות בהרבה מאוד ארגונים.

שתי חולשות שאף אחת מהן לא מספיקה לבד

כל מערכת שמנפיקה token-ים צריכה לבדוק שני דברים על token שמגיע אליה. הראשון הוא שה-token אמיתי, כלומר שהוא נחתם על ידי מי שאמור לחתום עליו. השני הוא שהוא מתאים למה שמבקשים ממנו לעשות עכשיו, כלומר שההרשאות שנצרבו בו ברגע ההנפקה באמת מכסות את הפעולה. Artifactory בדקה את הראשון והזניחה את השני. זאת CVE-2026-42016, חולשת הסלמת הרשאות שפורסמה ב-27 ביולי וקיבלה ציון 8.1 מ-JFrog ו-8.8 מ-NVD.

לבד היא לא שווה הרבה, כי כדי להתחיל צריך כבר להחזיק token תקף כלשהו. כאן נכנסת לתמונה השנייה. CVE-2026-42018, בציון 7.5, גורמת לשרת להחזיר token של המשתמש האנונימי הפנימי שלו למי שביקש בלי להזדהות בכלל, וגם כשגישה אנונימית מושבתת בהגדרות. הבקשה שעבדה בשטח נשלחה ל-endpoint בשם /access/api/v1/aws/token/, עם לוכסן בסוף, וחזרה עם קוד 200 ועם JWT תקף.

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

אז למה הלוג מראה anonymous?

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

Wiz מציעה בהתאם לחפש התנהגות במקום זהות. לגבי החולשה הראשונה כותבים החוקרים שהסימן בעל רמת הביטחון הגבוהה ביותר הוא התנהגותי: שגיאת 401 על הנתיב החשוף, ומיד אחריה תשובת 200 על וריאציה כלשהי שלו, מאותו לקוח ובתוך חלון זמן קצר. זאת החתימה של תוקף שבודק איזו צורה של הנתיב חשופה לפני שהוא מסתמך עליה, ולקוח רגיל לא מייצר דפוס כזה. לגבי השנייה, מה שצריך לחפש הוא פער בין מי שהזהות היא לבין מה שהיא עושה: זהות בהרשאות נמוכות שמנפיקה token-ים, מונה משתמשים, או נוגעת בממשק התוספים.

מה עשו התוקפים אחרי שנכנסו

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

השלב הבא היה הורדת מטען. לפי הדוח, דרופר משך קובץ בינארי דרך HTTP, כתב אותו לתיקייה שפתוחה לכתיבה לכל משתמש כמו /tmp, /var/tmp או /dev/shm, ופתח ערוץ אל שרת שליטה ובקרה (C2, השרת שדרכו התוקף שולח פקודות לקוד הזדוני). בכמה מקרים נפרדים ראו החוקרים דלת אחורית שנכתבה ב-Rust עם יכולות C2 משלה. במקרים אחרים הועלה סקריפט אל תוך אחד המאגרים עצמם, כדי לשמור אחיזה בשרת גם אם החשבון שנוצר יימחק.

החשבונות שנוצרו מספרים סיפור בפני עצמם. חלקם נושאים שמות שנראים כאילו נלקחו היישר מכלי ניצול מדף: 0xTerror, ושמות שמתחילים ב-Nxploited_ או ב-labadmin_. אחרים נבחרו כדי להיבלע ברשימה: jfrog-distribution, jfrog-insight, repo-service, backup-service, migration-tool. מנהל שעובר על רשימת המשתמשים בשרת בנייה עמוס לא בהכרח יעצור על שורה שכתוב בה backup-service.

החולשה בציון 9.8 קיבלה טיפול, השתיים האחרות פחות

הנתונים של Wiz על קצב התיקון הם אולי החלק המעשי ביותר בדוח. ב-27 ביולי, כשפורסמה CVE-2026-42016, ל-67% מהארגונים שמריצים Artifactory הייתה לפחות מכונה אחת חשופה. עבור CVE-2026-42018 המספר ביום הפרסום היה 69%, ועבור החולשה בציון 9.8 הוא עמד על 67%. נקודת הפתיחה, במילים אחרות, הייתה כמעט זהה בשלושתן.

מה שקרה אחר כך שונה לגמרי. שישה שבועות אחרי הפרסום הראשון, 59% מהארגונים עדיין חשופים ל-CVE-2026-42016. CVE-2026-42018 ירדה מ-69% ל-62% בארבעה שבועות. לעומתן, החולשה בציון 9.8 ירדה מ-67% ל-49% בתוך שבועיים בלבד. Wiz מעריכה שההבדל נובע מדירוג החומרה הקריטי, שדחף צוותי אבטחה לטפל בה בדחיפות גבוהה יותר.

ההיגיון הזה מובן, וזאת בדיוק הבעיה. רשימת החולשות המנוצלות של CISA כוללת מבין השלוש רק את CVE-2026-82329, שנוספה ב-2 בספטמבר עם מועד יעד ל-5 בספטמבר לגופים פדרליים. שתי החולשות שמרכיבות את השרשרת אינן ברשימה, ו-Wiz כותבת שלא ידוע לה על דיווח פומבי קודם על ניצול שלהן בשטח. ארגון שתעדף לפי ציוני חומרה ולפי רשימות חובה עשה בדיוק את מה שמצפים ממנו, ונשאר עם שתי חולשות פתוחות שמצטרפות יחד למשהו ששקול להשתלטות מלאה.

(אגב, בצד השני של אותה משוואה, חוקרי Fastly ספרו ברשת שלהם כ-406 אלף ניסיונות ניצול של החולשה בציון 9.8 ביום אחד, ה-2 בספטמבר. תשומת לב עובדת לשני הכיוונים.)

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

אם יש לכם Artifactory בארגון, העדכון הוא הצעד הראשון ולא הצעד האחרון. הגרסאות המתוקנות משתנות לפי ענף הגרסה, ו-Wiz מונה את 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 ו-7.161.20 ומעלה; את חולשת הסלמת ההרשאות עצמה JFrog תיקנה כבר בגרסה 7.133.11.

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