ביום שני פרסמה Atlassian התראת אבטחה על חולשה שחוצה שמונה מהמוצרים שלה, וביקשה ממנהלי מערכת של התקנות מקומיות לעדכן בהקדם. באותו יום פרסמו חוקרי watchTowr Labs את הניתוח הטכני המלא, כולל קוד הוכחה עובד. לפי חברת האבטחה Previdian, תוך שעתיים מאותו פרסום השרתים שהיא מציבה ברשת במיוחד כדי למשוך תקיפות ולתעד אותן, honeypot בלשון המקצועית, התחילו לראות ניסיונות ניצול.

החולשה מסומנת CVE-2026-21589 ו-Atlassian נתנה לה ציון CVSS 9.3 בדירוג קריטי. היא מאפשרת לתוקף בלי שם משתמש וסיסמה לקרוא קבצים מתוך ספריית השורש של האפליקציה, ובהתקנות מסוימות השרשרת ממשיכה משם עד חשבון אדמין. מה שהופך אותה לעניין רחב במיוחד הוא שהיא לא יושבת במוצר אחד אלא בספרייה משותפת שכל המוצרים טוענים. נעבור על מה שבאמת קרה שם: למה שתי נקודתיים בכתובת הפכו לקו נטוי, מה אפשר לקרוא בפועל ומה לא, ולמה דווקא השעתיים האלה הן המספר שכדאי לזכור.

למה שתי נקודתיים הפכו לקו נטוי

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

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

הקוד האשם לא שייך ל-Jira או ל-Confluence. הוא יושב ב-atlassian-plugins-webresource, ספרייה משותפת שכל מוצרי Data Center טוענים, בגרסה 6.0.7, ותוקן בגרסה 6.0.8. המחלקה שמנתבת את הבקשות האלה אצל watchTowr נקראת Router, והיא זו שמפרסרת את המקטע ומחזירה אותו לצורת נתיב. זו הסיבה שרשימת המוצרים הנפגעים נראית כמו קטלוג: Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, Crucible ו-Fisheye, בכל הגרסאות שקדמו לתיקון. NVD מסווגת את זה כ-CWE-552, חשיפה של קבצים שלא היו אמורים להיות נגישים.

מה בעצם אפשר לקרוא, ומה לא

כאן כדאי להיות מדויקים, כי ההבדל בין "קריאת קבצים שרירותית" לבין מה שהחוקרים הדגימו בפועל הוא לא זניח. לפי הנוסח של Atlassian עצמה, התוקף יכול לגשת לקבצים מסוימים בתוך ספריית השורש של האפליקציה, ו-NVD מוסיפה שהוא צריך לדעת מראש את הנתיב המדויק, כי אין כאן אפשרות לעיין בתוכן התיקיות ולגלות מה יש בהן. watchTowr אישרו קריאת קבצים ב-Jira, ב-Confluence וב-Bitbucket, אבל מציינים שהטכניקה שלהם לא הצליחה לצאת מגבולות ההקשר של אפליקציית ה-Tomcat שמריצה את המוצר. כלומר לא /etc/shadow, ולא מפתחות SSH מתיקיית הבית.

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

מקובץ הגדרות אחד לחשבון אדמין

ארגונים רבים שמריצים כמה מוצרי Atlassian מחברים אותם ל-Crowd, המוצר שמרכז אצל Atlassian את ניהול הזהויות וההרשאות וה-single sign-on. החיבור הזה דורש שכל אפליקציה תדע להזדהות מול Crowd, והפרטים לכך יושבים בקובץ בשם crowd.properties: שם האפליקציה, כתובת שרת ה-Crowd, והסיסמה של האפליקציה בטקסט גלוי.

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

חשוב להבין איפה השרשרת הזאת נעצרת, כי היא לא עובדת בכל התקנה. היא דורשת ש-Crowd יהיה בכלל נגיש מהמקום שבו התוקף נמצא, ושלאפליקציה יהיו הרשאות מספיקות. החוקרים עצמם מציינים שהגדרת רשימת כתובות IP מורשות מול Crowd מקשה על הניצול מאוד: התוקף "יצטרך לעבור דרך מכונות אחרות או להשתמש ביכולות דמויות SSRF של Jira, Confluence או Bitbucket כדי להגיע ל-Crowd ישירות", כתבו. SSRF, במילים פשוטות, זה להכריח את השרת עצמו לשלוח בקשות רשת בשם התוקף, וכך להגיע למקומות שהתוקף לא יכול לפנות אליהם בעצמו.

אז למה שעתיים זה המספר שחשוב כאן?

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

Previdian אמרה ל-BleepingComputer שתוך שעתיים מפרסום המחקר וקוד ההוכחה, רשת ה-honeypot שלה התחילה לראות ניסיונות ניצול של החולשה. ריאן דיוהרסט מהחברה הוסיף שפורסמה גם תבנית ל-Nuclei, סורק חולשות בקוד פתוח שעובד לפי תבניות קהילתיות, וזה מה שהופך בדיקה חד-פעמית לסריקה אוטומטית של האינטרנט כולו. החברה דיווחה על ניסיונות משלוש כתובות IP והמליצה לחסום אותן, ודיוהרסט צופה שהיקף הניסיונות יגדל משמעותית בימים ובשבועות הקרובים.

הערה על המספרים: מדובר בטלמטריה של חברה אחת שדיווחה עליה לעיתון, ולא בדוח פומבי שאפשר לבדוק. בקטלוג ה-KEV של CISA, רשימת החולשות שידוע שמנוצלות בפועל, החולשה עדיין לא מופיעה בגרסה 2026.10.04 של הקטלוג, וזה לא מפתיע במיוחד כשהגילוי עצמו היה ב-5 באוקטובר. Atlassian מצדה כתבה שמכונות הענן שלה עודכנו ולא נמצאה אצלן עדות לניצול, אבל גם שהיא לא יכולה לקבוע אם התקנה מקומית של לקוח מסוים נפרצה. את הבדיקה הזאת כל ארגון עושה אצלו.

Confluence וההיסטוריה שחוזרת

הדפוס הזה, שבו פרסום ניתוח טכני מדליק את הסריקות, מתועד היטב סביב המוצרים האלה. בקטלוג ה-KEV של CISA יש כבר ארבע חולשות של Confluence Data Center ו-Server שנוספו אחרי ניצול המוני, בהן CVE-2022-26134, CVE-2023-22515, CVE-2023-22518 ו-CVE-2023-22527, וגם חולשות ותיקות של Jira ושל Crowd. הסיבה שהמוצרים האלה חוזרים לרשימה פשוטה: הם יושבים בתוך הארגון, מחזיקים את הקוד, התיעוד והתהליכים שלו, ולעיתים קרובות הם חשופים לאינטרנט כדי שספקים ועובדים מרחוק יגיעו אליהם.

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

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

אם אתם מריצים אצלכם אחד משמונת המוצרים האלה, העדכון לגרסה המתוקנת הוא הצעד הראשון, והוא דחוף יותר מהרגיל בגלל שקוד ההוכחה פומבי ותבנית הסריקה כבר בחוץ. מי שלא יכול לעדכן מיד ימצא בהתראה של Atlassian חלופות ביניים: כלל בחומת אש אפליקטיבית או בפרוקסי שחוסם את תבניות הטיפוס בנתיב, כלל RewriteValve ב-Tomcat עבור Confluence, Jira, JSM, Bamboo ו-Crowd, וכלל שכתוב כתובות עבור Bitbucket.

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