פגם קריטי לפני אימות ב-MongoDB (CVE-2026-118383) עלול להפיל שרתים מפגרים בעת מעבר כשל

MongoDB שחררה גרסאות מתוקנות ל-CVE-2026-118383, פגם קריטי לפני אימות בשרת MongoDB שעלול להפיל חבר בסט רפליקה אם הוא זוכה בבחירות כשהוא עדיין מפגר בשכפול הנתונים לאחר שקיבל שתי בקשות לא מאומתות. הפגם הוא use-after-free, והוא דורג 9.5 מתוך 10 בסולם CVSS 4.0. החברים המושפעים כוללים חברי סט רפליקה, וכן את חברי שרתי השרד ושרתי הקונפיגורציה באשכולות מחולקים. לעומת זאת, mongod בודד, כלומר שרת יחיד שאינו חלק מסט רפליקה, אינו מושפע.

איך הפגם עובד

בגרסאות פגיעות, הפעלת אימות אינה עוצרת את שתי הבקשות. מדובר בפקודות ping הנושאות ערך readConcern.afterOpTime, וכל אחת מהן מבקשת מהשרת להמתין עד שהשכפול יגיע לנקודה מסוימת; השרת רושם לשם כך התראת המתנה שנקראת waiter. ההתראות האלה אינן פוקעות ונשארות במקומן עד שהחבר מופעל מחדש, מבצע rollback או יורד מתפקיד הפריימרי. הקריסה מתרחשת כאשר החבר שקיבל אותן זוכה בבחירות מאוחרות אף שהוא מפגר אחרי חבר אחר: כששלב ההשלמה מסתיים, שגרת הניקוי רצה פעמיים ועושה שימוש חוזר בזיכרון שכבר שוחרר, והפריימרי החדש קורס לפני שהוא מקבל כתיבות. לדברי החוקרים, לאחר שהתנאים האלה מתקיימים הקריסה אינה תלויה בניצחון במירוץ תזמון, ותוקף אינו יכול לגרום לחבר המיועד לפגר או לנצח בבחירות, וגם אינו יכול לראות מתי אחד מהשניים קורה.

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

MongoDB שחררה גרסה מתוקנת לכל ענף מושפע, וכל גרסה קודמת בענף מושפעת, עד הגרסה הראשונה של הענף. פריסות בניהול עצמי זקוקות לגרסה המתוקנת בכל חבר בסט הרפליקה, ולאחר השדרוג על המנהלים לבדוק איזו גרסה כל חבר מריץ, כולל חברים בקונטיינרים וכל חבר שהיה לא מקוון במהלך התחזוקה. אשכולות MongoDB Atlas מקבלים גרסאות מתוקנות אוטומטית במהלך תחזוקה, ולקוחות שדוחים תחזוקה צריכים להחיל את השדרוג בהקדם האפשרי. ענף 8.2 אינו נכלל ברשימת הגרסאות המושפעות, והגרסה החדשה ביותר שלו היא 8.2.12, אך הוכחת היתכנות שפורסמה ב-GitHub מדווחת שגם 8.2.12 הציג את הבאג בבדיקת מעבדה שהשתמשה בהגדרה המיועדת לבדיקות בלבד. לפי לוח הזמנים של מחזור החיים של החברה, ענף 8.2 הגיע לסוף החיים ב-31 ביולי.

זיהוי והקלה

עד שניתן לשדרג את החבר, החוקרים ממליצים להגביל את הגישה לרשת אל מסד הנתונים רק למערכות שזקוקות לה; הדבר מגביל מי יכול לשלוח את שתי הבקשות, אך אינו מתקן את הפגם. כדי לחפש סימני שתילה או קריסה, בדקו ביומנים המובנים: רשומת COMMAND Slow query עם מזהה 51803 עבור בקשת ping לא מאומתת הנושאת readConcern.afterOpTime שהסתיימה ב-MaxTimeMSExpired; חבר שנכנס לשלב ההשלמה של הפריימרי עם מזהה 21359 ואז יוצא ממנו פעמיים עם מזהה 21363 במעבר אחד; ואות קטלני או backtrace הכולל את CatchupState::abort_inlock() לאחר היציאות האלה. הבקשות עשויות להגיע לפני מעבר הכשל, ולכן יש לבדוק גם יומנים קודמים של אותו חבר.

טענות בדבר הרצת קוד

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

מקורות: The Hacker News