מודול האימות שלח בקשת bind ל-389 Directory Server, קיבל בחזרה שהאימות הצליח, ופתח למשתמש session. הסיסמה הייתה שגויה. התשובה הגיעה מהתוקף, לא מהשרת, והיא נכנסה לחיבור בשנייה שבה הוא עבר להצפנה. זאת CVE-2026-86345, בציון 9.0, ורד האט דירגה אותה Moderate.

סקירה כללית

389 Directory Server הוא שרת ה-LDAP בקוד פתוח של רד האט, הבסיס של Red Hat Directory Server ושל החבילה 389-ds-base שב-RHEL. בארגון הוא מחזיק את ספר הזהויות, וכל מודול PAM או אפליקציה שמאמתים מולו שולחים פעולת bind ושואלים שאלה אחת, האם שם המשתמש והסיסמה תקינים.

חיבור ל-LDAP יכול להיות מוצפן מהרגע הראשון בפורט 636, או להתחיל גלוי בפורט 389 ואז לעבור להצפנה באמצע. למעבר הזה קוראים StartTLS. מה ש-389-ds-base לא עשה ברגע הזה הוא לזרוק את הבתים שהצטברו אצלו מהשלב הגלוי. הם נשארו ב-buffer, והשרת מפרסר אותם אחרי שההצפנה עלתה, כאילו הגיעו מתוכה.

מזהה: CVE-2026-86345
סוג: הזרקת הודעת LDAP לחיבור שעובר ל-TLS (CWE-923)
מוצר: 389-ds-base
גרסאות מושפעות: RHEL 8, 9 ו-10, ו-Red Hat Directory Server 11, 12 ו-13
גרסה מתוקנת: אין. רד האט מסמנת את כולם Affected
ניצול בפועל: לא, והחולשה אינה ברשימת ה-KEV של CISA

ציר זמן

7 בספטמבר 2026: רד האט פותחת את באג המעקב 2529332 אחרי דיווח של החוקר xclow3n
1 באוקטובר 2026: החולשה מתפרסמת יחד עם CVE-2026-86344, חולשה שנייה של אותו חוקר
2 באוקטובר 2026: הרשומה עולה ל-NVD עם הווקטור והציון של רד האט
7 באוקטובר 2026: באג המעקב עדיין פתוח, ואין גרסה מתוקנת לאף מוצר

איך הניצול עובד

התוקף צריך לשבת על הנתיב בין הלקוח לשרת (on-path, מי שהתעבורה עוברת דרכו ויכול להוסיף לה בתים), ודווקא בחלון שבו החיבור עדיין גלוי. שם הוא דוחף הודעת LDAP משלו. כאן נכנס לתמונה ה-messageID, המספר שדרכו LDAP מתאים כל תשובה לבקשה שלה: ההודעה המוזרקת מקבלת את אותו messageID שהלקוח נתן לבקשת ה-bind. השרת עונה לה אחרי שההצפנה עלתה, והלקוח קורא בתשובה הזאת שהאימות שלו הצליח.

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

ניתוח ציון ה-CVSS

ציון CVSS: 9.0

הציון מגיע משילוב אחד: אין דרישת אימות, ותוצאת bind שבורה מתגלגלת לכל מה שמאמת מול השרת. מה שמוריד אותו הוא התנאי המוקדם, להיות על הנתיב בדיוק ברגע ה-StartTLS, ועליו רד האט נשענת כשהיא מדרגת את החולשה Moderate. ההשוואה מספרת את זה טוב מכל הסבר: CVE-2026-86344, שמשתיקה את השרת לכל הלקוחות בכך שהיא תופסת את כל ה-thread-ים בבריכה, קיבלה 7.5 ודירוג Important.

איפה למצוא Proof of Concept (PoC)

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

עד שיגיע תיקון, רד האט ממליצה על מעקף אחד: לכבות StartTLS בפורט 389 ולדרוש ldaps:// בפורט 636, חיבור שאין בו קטע גלוי להזריק אליו.