Artifactory יכול היה להחזיר את ה-token של המשתמש האנונימי הפנימי שלו לפונה שלא הזדהה כלל, ולפי הרשומה זה קרה גם בהתקנות שבהן הגישה האנונימית מכובה. הציון הוא 7.5 מתוך 10, ב-11 בספטמבר 2026 נכנסה החולשה לקטלוג החולשות המנוצלות בפועל של CISA, והתיקון נכנס בחמישה ענפי גרסאות שונים.

מה החולשה?

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

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

הצירוף עם ההגדרה הוא מה שהופך את זה למעניין. ההגדרה שנועדה לסגור את הדלת אינה מונעת את מסירת המפתח אליה.

מי מושפע?

הרשומה מונה חמישה טווחים: כל מה שמתחת ל-7.111.20, ואז הענף 7.117 עד 7.117.27, הענף 7.125 עד 7.125.19, הענף 7.133 עד 7.133.28 והענף 7.146 עד 7.146.8.

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

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

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

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

בין המקורות של הרשומה מופיעים פרסום של חברת Wiz על ניצול בשטח של חולשות ב-Artifactory ודף הקטלוג של CISA לרשומה הזאת.

מה עושים?

1. מצאו את מספר הגרסה המדויק של ההתקנה שלכם במסך הניהול, ולא רק את הענף שאתם עליו.
2. עדכנו לגרסה שסוגרת את הענף שלכם: 7.111.20, 7.117.27, 7.125.19, 7.133.28 או 7.146.8 ומעלה. עמוד השחרורים של JFrog מפרט אותן, והודעות האבטחה של היצרן מרכזות את ההנחיות לכל ענף.
3. אל תסתמכו על כך שהגישה האנונימית מכובה אצלכם. זו בדיוק התצורה שהרשומה מתארת, ולכן ההגדרה הזאת אינה שיקול בהחלטה אם לעדכן.
4. אחרי העדכון בדקו אילו משאבים היו פתוחים למשתמש האנונימי בהתקנה שלכם. מה שהיה חשוף לו הוא מה שהיה חשוף למי שהחזיק את ה-token שלו.