שורת שרתים בחדר מחשוב ארגוני הממחישה תשתית Cisco UCS
צילום: Kevin Ache / Unsplash

Cisco: חולשה ב־UCS Central מאפשרת הרצת קוד — ואין מעקף

Cisco פרסמה ב־4 בנובמבר 2026 עדכון אבטחה לחולשה ברמת חומרה גבוהה ב־UCS Central Software. הפגם, CVE‑2026‑76506, מאפשר לתוקף מרוחק שכבר מחזיק בפרטי כניסה תקפים להריץ פקודות שרירותיות, לכתוב קבצים במערכת ולחשוף מידע רגיש.

החולשה קיבלה ציון CVSS של 7.6 ומסווגת כ־Path Traversal מסוג CWE‑22. לפי Cisco, היא נובעת מאימות לא מספק של קלט שהמשתמש שולח בבקשת HTTP לממשק הניהול מבוסס הרשת.

מה תוקף יכול לבצע?

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

  • הרצת פקודות שרירותיות על ההתקן;
  • כתיבת קבצים במערכת הקבצים;
  • גישה למידע רגיש;
  • פגיעה אפשרית בסודיות, בשלמות ובזמינות של מערכת הניהול.

הצורך בפרטי כניסה מוריד את הסיכון ביחס לחולשה בלתי מאומתת, אך אינו הופך אותה לשולית. חשבון שנגנב ב־Phishing, Credential Stuffing, מכשיר מנהל שנפרץ או משתמש פנימי יכולים להפוך את ממשק הניהול לנקודת קפיצה אל סביבת ה־UCS.

אילו גרסאות מושפעות?

Cisco מציינת שהחולשה משפיעה על Cisco UCS Central Software ללא תלות בתצורת ההתקן. טבלת התיקון הרשמית קובעת:

  • גרסה 2.1: הגרסה המתוקנת הראשונה היא 2.1(2c).
  • גרסה 2.0 ומטה: יש לעבור לגרסה מתוקנת נתמכת.

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

אין Workaround

Cisco מדגישה שאין מעקף שמטפל בחולשה. לכן, הקטנת חשיפה של ממשק הניהול ובקרה על חשבונות הן פעולות חשובות, אך אינן תחליף לעדכון תוכנה.

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

צעדי תגובה מומלצים

  1. מיפוי: לאתר את כל מופעי UCS Central, גם במעבדות, באתרי גיבוי ובסביבות מבודדות.
  2. אימות גרסה: להשוות לגרסה המתוקנת הראשונה 2.1(2c) ולמסלול השדרוג המתאים.
  3. גיבוי: לגבות תצורה ומידע תפעולי ולוודא שחזור לפני העדכון.
  4. הגבלת גישה: לאפשר גישה לממשק הניהול רק מרשתות ניהול ייעודיות, VPN או Jump Host.
  5. בדיקת זהויות: להסיר חשבונות לא פעילים, לצמצם הרשאות ולשנות סודות שנחשפו או שותפו.
  6. ניטור: לחפש בקשות HTTP חריגות, כתיבת קבצים לא צפויה ופקודות שנוצרו מחשבונות ניהול.
  7. בדיקת תאימות: לוודא שהחומרה, האינטגרציות וזרימות התפעול נתמכות בגרסה החדשה.

למה מערכות ניהול דורשות עדיפות?

UCS Central מרכזת ניהול של תשתיות מחשוב. פגיעה במערכת ניהול אינה מוגבלת לשרת יחיד: היא יכולה לחשוף מידע על הטופולוגיה, החשבונות והתצורה, ואף לאפשר פעולות בעלות השפעה רחבה. לכן יש לדרג עדיפות לפי Blast Radius ולא רק לפי ציון CVSS.

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

מקורות

תמונה: Kevin Ache / Unsplash, ברישיון Unsplash. דף המקור, היוצר והרישיון מתועדים במדיה.

דילוג לתוכן