בתחילת ספטמבר התחילו מנהלי רשת לפרסם בפורום של MikroTik וב-Reddit קטעי לוג מהנתבים שלהם. בכולם חזרו שתי שורות, והשנייה סותרת את הראשונה: ניסיון התחברות שנכשל למשתמש "-2" מהכתובת 82.192.72.4, ומיד אחריו, באותו session בדיוק, יצירת חשבון מנהל חדש בשם ops.

התחברות שנכשלה לא אמורה להספיק כדי לפתוח חשבון. סלבומיר רוזביצקי מ-CERT Polska, הצוות הלאומי הפולני לטיפול באירועי סייבר, פרסם ב-22 בספטמבר את הניתוח שמסביר איך זה בכל זאת עבד: שרשרת של שתי חולשות בשרת ה-SSH של RouterOS, שביחד נותנות גישה מלאה לקונסולת הניהול של הנתב בלי סיסמה, בלי מפתח SSH, ובלי להשלים אימות בכלל. לשרשרת קראו MikroTrick.

הרקע: ב-3 בספטמבר MikroTik שחררה עדכונים כמעט בו-זמנית לארבעה ענפי RouterOS נתמכים, 7.25beta3, 7.24.2, 7.23.4 ו-6.49.21, והמליצה להתקין בהקדם. החברה הגדירה את זה עדכון אבטחה חשוב, אבל נמנעה בכוונה מפרסום פרטים כדי לתת למנהלים זמן לעדכן. השילוב של דחיפות בלי הסבר עשה בדיוק את מה שאפשר היה לצפות: הפורום התמלא בניחושים, והמנהלים התחילו להעלות לוגים. נעבור על שתי החולשות אחת אחרי השנייה, נראה איך CERT Polska זיהתה את השנייה שבהן תוך שעה, ונגיע לחלק שאולי מעניין יותר מהבאג עצמו.

החולשה הראשונה: להחליף מפתחות באמצע האימות

חיבור SSH נבנה בשלושה שלבים, בסדר קבוע. קודם שכבת התעבורה: הצדדים מסכימים על אלגוריתמים, מחליפים מפתחות, והשרת חותם על הפרמטרים במפתח המארח שלו כדי שהלקוח יידע מול מי הוא מדבר. אחר כך שכבת אימות המשתמש, בסיסמה או במפתח ציבורי, שבסופה השרת שולח SSH_MSG_USERAUTH_SUCCESS. ורק אז השכבה השלישית, ניהול הערוצים, שבה הלקוח יכול לבקש shell, להריץ פקודה או להעביר קובץ. החלוקה מוגדרת ב-RFC 4253, 4252 ו-4254, והיא כל מה שעומד בין חיבור TCP אנונימי לקונסולת ניהול.

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

החולשה הזאת, CVE-2026-67279, קיבלה מ-CERT Polska ציון 6.9 בסולם CVSS 4.0, ובצדק: לבדה היא כמעט לא נותנת כלום. היא לא קובעת זהות ולא מקצה הרשאות, רק מזיזה את החיבור לשלב שבו אפשר לדבר עם התהליך הבא בשרשרת. הדלת נפתחה, ועדיין אין מה לעשות מאחוריה.

החולשה השנייה: שם משתמש שהוא מספר של קובץ פתוח

כשלקוח מבקש קונסולה מרוחקת, RouterOS יוצר טרמינל וירטואלי (pseudoterminal) ומריץ תהליך בן שמחובר אליו, /nova/bin/login. שני הארגומנטים האחרונים שהתהליך מקבל הם שם המשתמש המאומת ומסכת ההרשאות האפקטיבית שלו, כמספר עשרוני. התהליך הזה לא בודק שוב סיסמה או מפתח. הוא סומך על ההחלטה שקיבל תהליך האב, ובונה את הקונסולה לפיה.

שם המשתמש, לעומת זאת, מגיע מהלקוח כבר ב-SSH_MSG_USERAUTH_REQUEST, לפני שהאימות הסתיים. sshd שומר אותו ומעביר אותו הלאה אל מערך הארגומנטים של login בלי לבדוק אותו, וערך שמתחיל בסימן מינוס נקרא שם כאופציה ולא כשם משתמש. ל-login יש תחביר ישן שבו ‎-N, כשהמספר N מזהה קובץ פתוח של התהליך (file descriptor), אומר לו לקרוא משם רשומה בת שני שדות מופרדים בבית אפס: שם משתמש, ואחריו מסכת הרשאות.

אז מה קורה כששולחים שם משתמש "-2"? login קורא את הרשומה מ-file descriptor מספר 2. ה-descriptor הזה, יחד עם 0 ו-1, מצביע על אותו טרמינל וירטואלי שנוצר קודם, ושלושתם חולקים תור קלט אחד. התוקף כבר מחובר לערוץ הזה בזכות החולשה הראשונה, אז הוא שולח דרכו את הערכים שהוא רוצה. הערך שהופיע בניתוח הוא 655358, מסכת ההרשאות של קבוצת full.

זאת CVE-2026-86060, בסיווג CWE-88, הזרקה של מפרידי ארגומנטים. CERT Polska נתנה לה 9.2 ב-CVSS 4.0, ו-NVD העריכה אותה ב-9.8 בסולם CVSS 3.1. זה לא באג בקריפטוגרפיה ולא באג בזיכרון. זאת מחרוזת שעוברת שלושה רכיבים ומשנה משמעות בדרך.

שעה מרגע שהטלאי ירד

כש-MikroTik שחררה את הגרסאות החדשות, CERT Polska התחילה להשוות בין החבילות כדי לוודא שהחולשות שהיא עצמה דיווחה עליהן תוקנו, ומצאה בדרך גם תיקונים לדברים שלא הופיעו בדיווח שלה. אחד מהם היה פונקציית ולידציה חדשה שבודקת את שם המשתמש לפני שהוא מועבר ל-login, ופוסלת שמות שמתחילים במקף (0x2d) או ברווח (0x20). היקף הבדיקה רמז בדיוק על מה שהיא באה למנוע.

התיקון השני היה מעניין אפילו יותר. למנגנון Flagged, שמסמן רשומות תצורה שעשויות להעיד על פריצה, נוספה בדיקה שרצה בעליית המערכת ומחפשת חשבון בשם ops שמשויך לקבוצת full. אם הוא נמצא, RouterOS מנטרלת אותו, רושמת אזהרה ומסמנת את המכשיר. סימן זיהוי ספציפי כל כך, עם שם חשבון קבוע, לא נולד מניתוח תיאורטי. לפי CERT Polska הוא מעיד שליצרן הייתה לפחות ידיעה חלקית על תקיפות בפועל.

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

מה כבר קרה בשטח

הלוגים הציבוריים המוקדמים ביותר מתוארכים ל-2 בספטמבר, יום לפני שהטלאים יצאו. בדיווחים חזרה אותה חבילת סימנים: חיבורים מ-82.192.72.4, ניסיון אימות בשם "-2", ויצירת חשבון ops עם הרשאות מלאות. דוח אבחון שפורסם בפורום של MikroTik תיעד את כל הרצף, אימות שנדחה, rekey, פתיחת ערוץ ומשלוח פקודה דרך exec. באותו מכשיר התקיפה נגמרה בקריסה של תהליך ה-SSH. מנהל אחר מצא את החשבון על כמה מכשירים שהוא מתחזק, ודיווח נוסף אישר שהחשבון נוצר גם על מכשירים שהוגדרו לקבל רק מפתחות SSH ורק צפנים חזקים. ההקשחה הזאת לא עוזרת כאן, כי התוקף לא מנסה להתחבר.

בלוגים שפורסמו בפורום trzepak.pl, ובדיווח דומה ב-Reddit, מופיע גם השלב הבא: יצירה של קובץ אבחון RIF והעברה שלו לאותה כתובת בעזרת פקודת fetch, מיד אחרי שנוצר. CERT Polska מנסחת את זה כהערכה, ואומרת שהרצף מעיד בסבירות גבוהה על חילוץ קבצי האבחון.

ב-10 בספטמבר CISA הוסיפה את CVE-2026-86060 לקטלוג ה-KEV שלה עם מועד תיקון של שלושה ימים, יחד עם CVE-2026-67277, חולשה נפרדת בשירות btest שמאפשרת דליפת זיכרון מהקרנל ומניעת שירות. נקודה אחת שכדאי לתקן: כמה פרסומים קשרו לשרשרת גם את CVE-2026-67276. לפי CERT Polska זו חולשה נפרדת, שמאפשרת התחזות למשתמש שהתאמת במפתח RSA ודורשת מהתוקף גם את שם החשבון וגם את המודולוס של המפתח הציבורי שלו. הציון שלה גבוה, 9.2, אבל היא לא מתאימה לתקיפה המונית.

אז למה הפער בין הטלאי לניתוח הפומבי נסגר?

המחקר עצמו נעשה בעזרת סוכני LLM, וזה חלק מהסיפור ולא הערת שוליים. הצוות מפרט שהשתמש במודלים GPT-5.5-cyber ו-GPT-5.6-sol דרך תוכנית GTAC של OpenAI, עם ספי סירוב מופחתים, ולצידם מודלים במשקולות פתוחות שהוא מריץ בעצמו, בהם DeepSeek, Qwen והמודל הפולני PLLuM. המעבדה שנבנתה סביבם הגיעה ל-40 מכונות וירטואליות מסוג CHR, 39 snapshot-ים ו-24 גרסאות RouterOS, מ-6.43.11 ועד 7.25beta3. הסוכן הפעיל אותן דרך libvirt, הכין ושחזר snapshot-ים, והריץ ניתוח סטטי של הבינאריים בעזרת radare2 ו-Ghidra מול הגדרות הפרוטוקול ב-RFC.

לפי הדיווח, המודלים היו טובים במיוחד בדבר אחד: להתייחס לפרוטוקול כאל מכונת מצבים ולבדוק שיטתית מה קורה כששלב חוזר על עצמו, כשהודעה מדולגת, או כשערוץ תלוי נפתח מוקדם מדי. אחת הבדיקות האלה הייתה rekey לפני שהאימות הסתיים. ככה נמצאה CVE-2026-67279.

הצד השני של אותו מטבע הופיע מיד אחרי שהטלאים פורסמו. ב-4 בספטמבר ב-03:22 UTC, מהנדס רשת בשם ניק פראטלי פרסם ניתוח של ההבדלים בין החבילות, וכתב במפורש שהעבודה נעשתה בהובלת AI ואומתה במעבדה, "שש שעות מול מה שבדרך כלל היה לוקח שבועות עד חודשים". הגרסה הראשונה שלו עוד לא שחזרה את השרשרת המלאה, אבל היא כבר הצביעה על השינויים המרכזיים בשרת ה-SSH. עד 5 בספטמבר הקשר בין השם "-2" לבין file descriptor כבר היה ציבורי, וחוקרים עצמאיים דיווחו שהצליחו לשחזר גישה לא מאומתת.

בשלב הזה CERT Polska פרסמה את רשומות ה-CVE, ב-5 בספטמבר ב-20:00 UTC. ההיגיון ישיר: שמירת הפרטים בערוצי הגילוי המתואם כבר לא הקשתה על מי שמשחזר את הניצול, היא רק צמצמה את המידע הזמין למנהלי המערכות. "המהירות של ניתוח טלאים בעזרת LLM מטשטשת את הגבול בין שחרור עדכון לבין פרסום הפרטים הטכניים של החולשה", כתב רוזביצקי. (וזה, אגב, הצד שנוטים לפספס בדיון על AI התקפי: לא נשק חדש, אלא קיצוץ אגרסיבי של לוח הזמנים שההגנה מתוכננת סביבו.)

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

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

אם יש אצלכם ציוד MikroTik, הגרסאות המתוקנות הן 6.49.21, 7.23.4, 7.24.2 ו-7.25beta3, והן זמינות מ-3 בספטמבר. אחרי העדכון עברו על רשימת המשתמשים במכשיר: חשבון ops בקבוצת full, או כל משתמש וסקריפט שאתם לא מזהים, אומרים שהמכשיר כבר נפרץ, ועדכון לא מוציא תוקף שכבר נכנס. MikroTik מוסיפה שגרסאות מתוקנות מסמנות מכשיר כזה בסטטוס Flagged ומנטרלות את החשבון.

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