עד גרסה 0.16.8 כולל, הפרויקט Letta הגיע עם קובץ התקנה מוכן שאינו מפעיל את שכבת הסיסמה של השרת. התוצאה היא ששכבת האימות אינה נוספת כלל, וכל מסלולי ה-API עונים לכל מי שמצליח להגיע אליהם. הציון הוא 9.3 מתוך 10, ולא ידוע על ניצול בפועל.
מה החולשה?
את השרת הזה מרימים בדרך כלל דרך קובץ compose.yaml שמגיע עם הפרויקט, קובץ שמתאר אילו רכיבים להרים ובאילו הגדרות כדי שפקודה אחת תעמיד את הכול. הנוחות הזאת היא כל הרעיון, וכאן היא גם הבעיה.
לפי הרשומה במאגר NVD, הקובץ שנשלח עם הפרויקט אינו מדליק את ההגדרה LETTA_SERVER_SECURE. ההגדרה הזאת היא מה שגורם לשרת להוסיף את שכבת הסיסמה, הרכיב שעובר על כל בקשה נכנסת ובודק אם מצורפים אליה פרטי אימות. כשההגדרה כבויה, השכבה אינה נוספת בכלל. לא מדובר בסיסמה חלשה או בסיסמה שאפשר לנחש. אין בקשה לסיסמה.
באותו קובץ נחשף גם הפורט של מסד הנתונים PostgreSQL, עם פרטי האימות של חשבון ה-superuser שנשארו בברירת המחדל שלהם.
הרשומה מונה שלוש דרכים שנפתחות למי שמגיע לשרת כזה. הוא יכול לשלוח בקשה למסלול /v1/tools/run ולהריץ קוד Python על המכונה. הוא יכול לנהל משתמשים דרך /v1/admin . והוא יכול להתחבר למסד הנתונים ולהשתמש ב-COPY PROGRAM, פקודה שמאפשרת ל-superuser להעביר נתונים אל תוכנית חיצונית או ממנה, ובכך להריץ פקודות של מערכת ההפעלה.
אין כאן באג בזיכרון ואין טריק. כל רכיב עובד בדיוק כפי שתוכנן, וההנחה שהתכנון הסתמך עליה היא שהשרת יעמוד בסביבה מוגנת. לדפוס הזה קוראים הגדרת ברירת מחדל לא מאובטחת.
הציון, 9.3, נגזר מכך שהגישה היא מהרשת, בלי הרשאות מוקדמות ובלי שמישהו צריך ללחוץ על משהו, וההשפעה גבוהה בסודיות, בשלמות ובזמינות. זה ציון של שרת פתוח, והוא מדויק.
מי מושפע?
כל מי שהרים את השרת מהקובץ שמגיע עם הפרויקט, בגרסאות עד 0.16.8 כולל. זאת אינה תוכנה שיושבת על מחשב ביתי, ורוב הקוראים אינם נוגעים בה. מי שכן, הם מפתחים וחברות.
מה שקובע את החשיפה אינו מה הגדרתם אלא לאן הפורט מגיע. מי שהרים את זה על מחשב מקומי בלי לפרסם פורט לאינטרנט חשוף לרשת שלו בלבד. מי שהרים את זה על מכונה בענן כדי לנסות, ונתן לה כתובת ציבורית, פתח את השרת לכל העולם בלי לבחור בכך. הגדרות ברירת מחדל נבדלות משאר החולשות בכך שלא צריך לעשות שום דבר שגוי כדי להיחשף. צריך לא לעשות דבר.
הבעיה האופיינית היא דווקא הרמה זמנית. מכונה שהועמדה לכמה ימים כדי לבדוק משהו, ונשארה.
שווה לדעת גם שהגדרות ברירת המחדל האלה פומביות. הקובץ יושב בפרויקט בגיטהאב, וכך גם השורה בקוד השרת שמוסיפה את שכבת האימות רק כשההגדרה דלוקה. אין כאן מידע סודי על מה שפתוח בשרת כזה.
האם מנוצלת בפועל?
נכון לעדכון האחרון, החולשה אינה מופיעה בקטלוג ה-KEV של סוכנות הסייבר האמריקאית CISA, שמרכז חולשות שידוע כי נוצלו בשטח. המשמעות היא שלא ידוע על ניצול, לא שאין כזה.
כאן שווה לסייג את הסייג. קטלוג כזה מתעד ניצול של חולשות, ושרת שאינו מבקש אימות אינו דורש ניצול כדי להשתמש בו. מי שמגיע לפורט פשוט משתמש בממשק כפי שהוא בנוי, וזה אינו סוג האירוע שמותיר חתימה שמישהו מחפש. לכן ההיעדר מהקטלוג מרגיע כאן פחות ממה שהוא נראה.
הרשומה פורסמה ב-20 באוקטובר 2026 ועודכנה באותו יום, כך שזאת חולשה טרייה והתמונה עליה עוד יכולה להשתנות.
מה עושים?
עדכנו לגרסה מעל 0.16.8. הרשומה מגדירה את כל מה שעד 0.16.8 כולל כחשוף.
הדליקו את ההגדרה LETTA_SERVER_SECURE וקבעו סיסמה לשרת. זאת ההגדרה שגורמת לשכבת האימות להיכנס לפעולה, ובלעדיה היא אינה שם גם בגרסה מעודכנת.
סגרו את הפורט של מסד הנתונים כך שלא יהיה נגיש מחוץ למכונה, והחליפו את פרטי האימות של חשבון ה-superuser. חשבון כזה הוא דרך להריץ פקודות על המכונה, לא רק דרך לקרוא נתונים.
בדקו מה מצב השרת שלכם עכשיו: פנו לאחד ממסלולי ה-API שלו מבחוץ, בלי פרטי אימות. אם הוא עונה, הוא פתוח. את פירוט המסלולים ואת הניתוח המלא מפרסמת חברת VulnCheck בהודעה שלה.
ואם השרת היה חשוף לאינטרנט, אל תסתפקו בעדכון. אחד המסלולים מאפשר להריץ קוד על המכונה, ולכן ההנחה הנכונה היא שצריך לבדוק את המכונה עצמה ולא רק לסגור את הדלת.