בעמוד התיעוד שהסביר איך להגדיר את שרת ה-proxy של המודול הופיעה דוגמה, ובה נכתב במלואו הסוד שחותם את ה-token-ים: supersecret. לידו הודגם פלט אמיתי של token חתום. העמוד הוסר מאז, בשקט, בלי הודעת אבטחה, ולכן כל ארגון שהקים את הרכיב לפי אותו מדריך ולא החליף את הסוד מאז חותם את ה-token-ים שלו במפתח שהתפרסם באינטרנט. את הפסקה הזאת לא כתב חוקר חיצוני. Dell כתבה אותה בעצמה, בהודעת האבטחה שפרסמה ב-1 באוקטובר.

ההודעה, DSA-2026-448, מרכזת 13 חולשות בקוד של Dell Container Storage Modules, המודול שמחבר מערכי אחסון ארגוניים של Dell לסביבות Kubernetes. שתיים מהן קיבלו ציון CVSS 10.0, הציון המלא, וארבע נוספות קיבלו מעל 9.5. מעקף זמני אין לאף אחת מהן. BleepingComputer ציין ש-Dell לא סימנה אותן כחולשות שנוצלו בשטח, והן גם לא מופיעות ברשימת ה-KEV של CISA בגרסת הקטלוג מ-2 באוקטובר. בהמשך נראה מה המודול הזה בכלל אמור למנוע, למה שתי החולשות הראשונות הופכות אותו לכלי ההפוך בדיוק, ואיך בקשה אחת מגיעה ל-root על כל ה-node-ים.

מה המודול הזה אמור למנוע

כדי להבין למה שתי חולשות בציון 10.0 באותו מודול הן יותר משני באגים, צריך לדעת מה המודול בא להחליף.

Kubernetes מדבר עם מערכי אחסון חיצוניים דרך דרייבר תקני שנקרא CSI. כדי שהדרייבר יוכל ליצור ולמחוק נפחי אחסון בפועל, הוא צריך פרטי אימות של המערך עצמו, ובדרך כלל אלה פרטי אימות ברמת אדמין. ברגע שהם יושבים בתוך ה-cluster, כל מי שמגיע אליהם שולט על האחסון של כל הארגון ולא רק על ה-namespace שלו. Dell בנתה את CSM Authorization בשביל להוציא אותם משם. במקום שהדרייבר יחזיק את פרטי האימות של המערך, הוא פונה לשרת מתווך, וזה שמחזיק אותם; המתווך מחלק ל-cluster-ים token-ים חתומים, כל אחד מוגבל ל-tenant מסוים, לתפקיד מסוים ולמכסת אחסון מסוימת, ומתרגם את הבקשות הלאה אל המערך. למתווך הזה קוראים proxy, ובתיעוד של Dell המודל מתואר בדיוק כך: RBAC ומכסות ל-CSI, בלי שה-tenant יחזיק פרטי אימות של האחסון.

המודול הזה עובד מול חמש משפחות מוצרים, לפי Dell: PowerStore, PowerScale, PowerFlex, PowerMax ו-Unity XT. כל עמידותו של המודל נשענת על דבר אחד. שה-proxy עצמו לא ייתן את מה שהוא שומר לכל מי שיבקש.

שני ציונים מלאים, אותה שגיאה

ו-CVE-2026-63688 היא בדיוק זה. בגרסה 2.4.0 של CSM Authorization, שרת ה-gRPC של רכיב csm-authorization-storage לא בדק מי מדבר איתו. Dell מנסחת את המשמעות בלי לרכך: תוקף מרוחק ולא מאומת יכול להגיע לפרטי האימות של האדמין של מערך האחסון "עבור כל המערכים הרשומים". באותה פסקה היא מוסיפה שהחולשה "מאפשרת מעקף מלא של מודל האבטחה של csm-authorization", ושליטה מלאה ברמת אדמין על תשתית האחסון בכל חמש משפחות המוצרים. הציון 10.0 נובע משילוב של גישה מהרשת, בלי הרשאות מוקדמות ובלי שום פעולה של משתמש, עם השפעה שחורגת מהרכיב עצמו.

החולשה השנייה בציון 10.0, CVE-2026-63692, יושבת ב-proxy ובשירות ה-tenant של אותה גרסה, ונובעת מאותו חוסר: אין אימות במקום שבו אמור להיות אימות. התוצאה שונה בזווית. במקום לחלץ את פרטי האימות של המערך, התוקף משיג שליטה אדמיניסטרטיבית על שירות ההרשאות עצמו, ולפי Dell זה מאפשר גישה ושינוי של משאבי אחסון "בכל ה-tenant-ים". מי ששולט בשירות שמנפיק את ההרשאות לא צריך לגנוב אותן.

הסוד שהיה בתיעוד

שתי החולשות הבאות הן אותו סיפור מזווית אחרת. לא חוסר אימות, אלא אימות שנשען על סוד שאינו סוד.

CVE-2026-54472, בציון 9.8, מסומנת כ-Use of Hard-coded Credentials ב-CSM Authorization 2.4.0. לפי Dell, תוקף מרוחק ולא מאומת יכול "לייצר token-ים אדמיניסטרטיביים חתומים באופן תקף קריפטוגרפית". הניסוח הזה הוא העיקר: ה-token לא עוקף את הבדיקה, הוא עובר אותה. מבחינת השרת החתימה פשוט נכונה.

CVE-2026-61421, גם בציון 9.8, היא הגרסה הארכיונית של אותה בעיה, והיא זו שבה הופיע supersecret. karavi-authorization, הרכיב שקדם ל-CSM Authorization ולפי Dell הועבר מאז לארכיון ואינו מתוחזק, החזיק מפתח חתימה קבוע בקוד. עמוד התיעוד הרשמי של הגדרת ה-proxy-server הדגים את המפתח הזה בשמו, לצד פלט אמיתי של token. Dell כותבת שהעמוד "הוסר לאחר מכן בלי הודעת אבטחה", ושכל ארגון שהקים את הרכיב לפי המדריך ולא החליף את מפתח החתימה "עשוי להישאר חשוף".

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

מ-custom resource אחד ל-root על כל ה-node-ים

עד כאן החולשות שלא דורשות חשבון בכלל. השתיים הבאות כן דורשות חשבון, אבל חלש, וזה מה שהופך אותן למעניינות יותר בעיני מי שמריץ cluster משותף.

CVE-2026-67269, בציון 9.9, נמצאת ב-CSM Operator בגרסה 1.12.0, ברכיב שמתרגם הגדרה מסוג ContainerStorageModule למה שצריך לרוץ בפועל ב-cluster. תוקף מרוחק עם הרשאות משתמש בסיסיות יכול, לפי Dell, להסלים ל-root על ה-node-ים. הניסוח בהודעה מדויק במיוחד כאן, והוא זה שקובע את החומרה: החולשה "ניתנת למינוף כדי להשתלט לחלוטין על כל ה-node-ים ב-cluster דרך הגשה אחת של custom resource". בקשה אחת, לא שרשרת של שלבים.

CVE-2026-67273, בציון 9.6, מגיעה למקום דומה בדרך אחרת. מנוע התבניות שמרכיב את הקונפיגורציה לא מנטרל תווים מיוחדים בקלט שהוא מקבל, ולכן מי שמצליח להכניס תווים משלו למקום שבו המנוע מרכיב את הפלט מכתיב מה ייווצר בסוף. התוצאה, לפי Dell, היא גישת קריאה לכל ה-Secrets ב-cluster ואפשרות ליצור משאבי RBAC ברמת ה-cluster, כלומר לתת לעצמך הרשאות. גישה לכל ה-Secrets של cluster היא לא בעיה של האחסון בלבד; שם יושבים גם ה-token-ים של כל שאר השירותים שרצים שם.

מה שמתחת לציונים

המשותף לשש החולשות הקריטיות הוא לא סוג הבאג. זה המקום שבו הן יושבות.

רכיב כמו CSM Authorization הוא מה שמכונה בשנים האחרונות management plane, שכבת הניהול שמתווכת בין המערכת לבין מה שהיא מנהלת. השכבה הזאת מקבלת כמעט תמיד הרשאות גבוהות מכל מה שסביבה, כי זה בדיוק התפקיד שלה, והיא נחשבת כמעט תמיד פנימית, כלומר נגישה רק מתוך הרשת. שני הדברים האלה יחד הם מה שמייצר ציון 10.0: רכיב שמחזיק את המפתחות לכל הממלכה, ושלא נכתב מתוך הנחה שמי שמדבר איתו עלול להיות עוין.

זה גם מה שמסביר את שאר הרשימה באותה הודעה. Dell תיקנה שם גם חולשת אימות תעודה בציון 8.2 ברכיב ה-proxy-server, שמאפשרת לתוקף מרשת סמוכה לחשוף את פרטי האימות של מערך האחסון, יצירה לא מאומתת של tenant-ים בציון 7.1, ושתי חולשות של כתיבת מידע רגיש לקובצי לוג. מעל כל אלה מופיעה רשימה ארוכה של חולשות בספריות צד שלישי, בעיקר golang.org/x/crypto ו-golang.org/x/net, שנסגרו באותה גרסה. ההודעה מציינת שהגרסאות שלפני 1.17.0 חשופות, ומפנה לעדכון ל-1.18.0 או מעלה.

מה זה אומר בפועל

אם יש אצלכם cluster שמחבר מערכי אחסון של Dell ל-Kubernetes דרך CSM, העדכון ל-1.18.0 הוא לא עוד פריט ברשימת ההקשחה לרבעון הבא. שתי חולשות בציון 10.0 שלא דורשות שום פרטי אימות אומרות שמי שמגיע לרשת שבה יושב ה-proxy מגיע גם לפרטי האימות של מערכי האחסון עצמם. ומכיוון שחלק מהחולשות מאפשרות לייצר token-ים חתומים כהלכה, העדכון לבדו לא סוגר את הסיפור: צריך להחליף גם את מפתחות החתימה של ה-JWT, כפי ש-Dell מבקשת במפורש, ולבדוק מה הוקם אצלכם בעבר לפי התיעוד של karavi-authorization. token שנחתם במפתח הישן לא יודע שיצא עדכון.