תוכנה שפותחת חיבור מוצפן אמורה לעצור אם הצד השני לא מציג תעודה שהיא סומכת עליה. בלקוח ה-TLS 1.3 של Erlang/OTP היא לא עצרה: ssl:connect החזירה {ok, Socket} מול שרת בלי תעודה, בלי מפתח פרטי ובלי שום חיבור קודם עם הלקוח. החולשה היא CVE-2026-89422, בציון 9.3.

סקירה כללית

אפליקציית ssl היא מימוש ה-TLS המובנה של Erlang/OTP, וכל מה שמדבר מוצפן שם עובר דרכה: httpc, ספריות לקוח למסדי נתונים ולתורי הודעות, והחיבור בין nodes. הצד הפגיע הוא הלקוח ולא השרת, כך שמי שמתחבר החוצה הוא הקורבן. אז מי חשוף בפועל? כל אפליקציית Erlang או Elixir שפותחת חיבור TLS 1.3 יוצא בהגדרות ברירת המחדל. לקוחות שהוגבלו במפורש ל-TLS 1.2 לא מושפעים.

פרטים בקצרה:
מזהה: CVE-2026-89422
סוג: החלפת מפתחות בלי אימות זהות הצד השני (CWE-322)
מוצר: Erlang/OTP, אפליקציית ssl
גרסאות מושפעות: מ-OTP 22.2 ולפני 27.3.4.18, 28.5.0.7 ו-29.1.1
גרסה מתוקנת: OTP 27.3.4.18, 28.5.0.7 ו-29.1.1
ניצול בפועל: לא, אינה ברשימת ה-KEV של CISA

ציר זמן

OTP 22.2: הגרסה הראשונה שבה הקוד הפגיע קיים, לפי ה-CNA.
22 בספטמבר 2026: יוצאות חבילות התיקון OTP 27.3.4.18, 28.5.0.7 ו-29.1.1. הערת השחרור: "Reject unsolicited TLS-1.3 pre_shared_key in client".
22 בספטמבר 2026, 08:49 UTC: ה-CNA של Erlang Ecosystem Foundation מפרסמת את ההמלצה ורשומת ה-OSV.
22 בספטמבר 2026, 09:17 UTC: הרשומה נכנסת ל-NVD.

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

ל-TLS 1.3 יש קיצור דרך לחיבור חוזר: אם הלקוח והשרת דיברו בעבר, הלקוח יכול להציע מפתח משותף מראש, ושני הצדדים מדלגים על החלפת התעודות. לבקשה הזאת קוראים pre_shared_key, והיא הגיונית רק אם הלקוח ביקש אותה. הבאג הוא שהלקוח לא בדק אם ביקש. כשהשרת עונה בהודעת ServerHello שמכילה הרחבת pre_shared_key, הקוד מסמן resumption=true על עצם קיומה, ומשם ה-handshake ממשיך ישר לשלב הסיום ומדלג על שלבי התעודה. כל מה שאדמין הגדיר כדי לבדוק את הצד השני לא רץ: אימות שרשרת התעודות, verify_fun, בדיקת שם המתחם, partial_chain, CRL ו-OCSP stapling. גם המפתחות לא עוצרים אותו, כי הקוד נופל לערך האפסים של "אין PSK" ומייצר מפתחות במסלול הרגיל. התוקף מחזיק אז את כל מפתחות התעבורה, קורא את פרטי האימות וה-token-ים שהאפליקציה שולחת, ומייצר כל תשובה שהוא רוצה.

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

ציון CVSS: 9.3

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

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

ביום הפרסום לא נמצא PoC פומבי לחולשה. ההפניה הטכנית הטובה ביותר היא ההמלצה של ה-CNA של Erlang Ecosystem Foundation, שמפרטת את שמות הפונקציות, את המסלול שבו ה-handshake עוקף את שלבי התעודה, ואת הקומיטים שסוגרים אותו.

מההגדרות אין הגנה בלי לשלם עליה: לפי ה-CNA הדרך היחידה לעקוף את הקוד הפגיע היא להגביל את הלקוח ל-{versions, ['tlsv1.2']}, כלומר לוותר על TLS 1.3. העדכון לאחת משלוש הגרסאות המתוקנות הוא התשובה היחידה שלא גובה מחיר.