הרשומה הזאת עוסקת במודול ה-anti-CSRF של Sitecore, שמשחזר אובייקט .NET מתוך פרמטר שמגיע בבקשת POST. מה שמייחד אותה הוא הטווח: היא חלה על Sitecore עד גרסה 9.1 ועד בכלל, כלומר גם על גרסאות מאוחרות בהרבה מקו 7.x. התנאי הוא שהתוקף מזוהה במערכת. הציון הוא 8.8 מתוך 10, וסוכנות הסייבר האמריקאית CISA מסמנת את החולשה כמנוצלת בפועל.

מה החולשה?

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

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

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

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

מי מושפע?

לפי הרשומה, Sitecore CMS בכל גרסה עד 9.1 ועד בכלל. זה טווח רחב, והוא הנקודה החשובה בעמוד הזה: ארגון שבדק את עצמו מול חולשות ותיקות באותו מודול והרגיע את עצמו מפני שהוא לא על 7.x או 8.x עדיין יכול להיות בטווח הזה.

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

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

כן. החולשה נוספה ב-26 במרץ 2025 לקטלוג ה-KEV של CISA, רשימת החולשות שידוע שתוקפים משתמשים בהן בשטח, והמועד שנקבע לגופים הפדרליים האמריקאיים לסיום התיקון היה 16 באפריל 2025.

הרשומה עצמה פורסמה ב-NVD ב-31 במאי 2019. מה שקרה ב-2025 הוא לא גילוי של החולשה אלא תיעוד רשמי של כך שהיא בשימוש.

מה עושים?

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

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

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

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

5. את התיאור הטכני של המודול ושל הפרמטר פרסמה Synacktiv בהודעת האבטחה שלה.