ב-Zimbra Collaboration Suite יש רכיב בשם ProxyServlet, שתפקידו להעביר בקשות הלאה בשם הלקוח. בגרסאות שמופיעות ברשומה אפשר היה להפעיל אותו בלי להזדהות מולו ולקבוע לאן הוא פונה. הציון 7.5, והחולשה רשומה בקטלוג המנוצלות בפועל של CISA.
מה החולשה?
יש הבדל בין באג שגורם לרכיב לעשות משהו שלא נועד לו, לבין רכיב שעושה בדיוק את מה שנועד לו, מול מי שלא היה אמור לבקש. זה המקרה השני. ProxyServlet קיים כדי לשלוף כתובות בשם הלקוח, וזו עבודתו התקינה. השאלה היחידה שחשובה בו היא מי רשאי להגיד לו מה לשלוף, ובגרסאות האלה התשובה הייתה רחבה מדי.
לתוצאה קוראים SSRF, כלומר בקשה שהשרת מבצע לפי בחירת מי שפנה אליו. מה שמעניק לה ערך הוא לא הבקשה אלא הכתובת שממנה היא יוצאת: שרת דואר ארגוני יושב עמוק ברשת ומגיע למקומות שאינם פתוחים מבחוץ.
מרכיבי הציון מסמנים את הגבול במדויק. פגיעה גבוהה בסודיות, ואפס בשלמות ובזמינות. הנתיב הזה מוציא מידע, הוא אינו משנה דבר ואינו מפיל את השרת. מנגד הוא זמין מהרשת, בלי הרשאות ובלי שאיש צריך ללחוץ על משהו.
וברשימת המקורות של הרשומה יש רמז לאופן שבו זה עבד בפועל. הפרסום הציבורי שמופיע שם מציג את החולשה הזאת יחד עם חולשה שנייה באותו מוצר וקושר בין השתיים. זה הדפוס המוכר בשרתי דואר: חולשה אחת אינה היעד, היא חוליה בשרשרת.
מי מושפע?
הרשומה מגדירה את הטווח לפי רמות תיקון ולא רק לפי מספרי גרסה: כל מה שלפני 8.6 patch 13, קו 8.7 שלפני 8.7.11 patch 10, וקו 8.8 שלפני 8.8.10 patch 7 או שלפני 8.8.11 patch 3.
זה פרט שקל לפספס בבדיקה. שרת שמדווח על עצמו כ-8.8.11 אינו בהכרח מעודכן, כי מה שמכריע כאן הוא רמת ה-patch שמעל מספר הגרסה, לא המספר עצמו.
מי שמריץ Zimbra עושה זאת מתוך בחירה להחזיק את הדואר אצלו, ולכן זה בדרך כלל מוסד, גוף ציבורי או ספק שמוכר תיבות כשירות. הקהל מצומצם, והחשיפה גדולה מהמספר שלו: תיבת הדואר הארגונית היא הדרך שבה מאפסים סיסמאות לכל שאר המערכות, ולכן מי שמגיע אליה מגיע רחוק.
האם מנוצלת בפועל?
כן. ב-7 ביולי 2025 צירפה CISA את החולשה לקטלוג ה-KEV, הרשימה שמרכזת חולשות שידוע כי תוקפים מנצלים אותן בשטח, עם מועד תיקון לגופים הפדרליים ב-28 ביולי 2025.
הפער כאן גדול במיוחד. הרשומה פורסמה ב-30 באפריל 2019, והתיקון של Zimbra קדם אפילו לה, שכן הודעת היצרן שמקושרת ברשומה היא ממרץ 2019. בין קיומו של תיקון לבין ההכרה הרשמית בניצול עברו יותר משש שנים.
מה עושים?
בדקו את רמת ה-patch ולא רק את מספר הגרסה, כי הטווח ברשומה מוגדר לפי רמות תיקון. שרת שנראה עדכני לפי הקו הראשי יכול בהחלט להיות מתחת לרמה שנדרשת.
העדכון מגיע דרך מרכז האבטחה של Zimbra ודרך דף הודעות האבטחה שלו, ושם מפורטת רמת התיקון שמתאימה לכל קו גרסאות.
אם השרת רחוק מרמות התיקון האלה, הניחו שהוא רחוק גם במקומות אחרים. שרת דואר שלא עודכן שנים אינו סיפור של חולשה בודדת, ומעבר לגרסה נתמכת עדיף בו על תיקון נקודתי שסוגר שורה אחת ברשימה.
ואחרי העדכון, הסתכלו החוצה. חולשה מהסוג הזה מותירה את סימניה ביומני הפניות היוצאות מהשרת: כתובות פנימיות שאין סיבה ששרת דואר יבקש, ופניות שיצאו ממנו בלי שום פעולה של משתמש שמסבירה אותן.