חדשות סייבר יומיות - 11 בנובמבר 2026

מה קרה

פגיעות קריטית לעקיפת אימות ב-Xen Orchestra (מזוהה כ-VSA-2026-062) מנוצלת בפועל, ומאפשרת לתוקפים מרחוק להשיג הרשאות מנהל בלי פרטי הזדהות.

התוקפים שולחים cookie שנבנה במיוחד ומכיל אובייקט JSON ריק (authenticationToken=j:{} או הצורה המקודדת ב-URL). נוצר חיפוש token ללא סינון שמחזיר את ה-token התקף הראשון, ומאמת את התוקף כבעליו. משם אפשר לשלוף login tokens לשימוש חוזר, להריץ קוד על pools מנוהלים ולהשתלט על מארחי XCP-ng כ-root.

Vates אישרה ניצול פעיל מכתובות IP ספציפיות ומ-Tor onion service. את הפגיעות גילו פיליפ מג'יק (Filip Magic) וכריסטופר אולסן (Christoffer Olsen). גרסאות מתוקנות זמינות.

מי מושפע

ארגונים שמריצים Xen Orchestra או את Xen Orchestra Appliance (XOA) ומנהלים מארחי וירטואליזציה של XCP-ng, ובמיוחד כל סביבה שממשק הניהול שלה נגיש.

הגרסאות המושפעות הן Xen Orchestra לפני 6.9.2 (stable) ו-6.10.1 (latest), וכן חבילות xo-server התואמות. גם התקנה ממקור וגם appliance מושפעים עד לעדכון. ההיקף משמעותי למפעילי ענן פרטי ו-VPS שמשתמשים בסטאק של XCP-ng.

למה זה חשוב

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

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

איך אפשר היה למנוע את זה

עדכנו מיד ל-Xen Orchestra 6.9.2 (stable) או 6.10.1 (latest), או לחבילות xo-server התואמות (5.211.2 / 5.213.1). בהתקנה ממקור, משכו את master העדכני, בנו מחדש והפעילו מחדש.

אל תחשפו את ממשק הניהול לאינטרנט; מקמו אותו ברשת ניהול ייעודית. נטרו תעבורת HTTP לאיתור תבניות cookie זדוניות. חסמו כתובות IP ידועות של תוקפים ותעבורת Tor אל ה-onion שברשימה. אם יש חשד לחדירה, בצעו רוטציה לכל הסיסמאות והסודות (משתמשים, root, pool, גיבויים, OTP, mail) ושקלו התקנה מחדש מלאה.

מה קרה

חוקרים של Microsoft הדגימו טכניקה בשם Lazarus ששותלת דלת אחורית סמויה במודל AI באמצעות עריכה ישירה של פחות מ-10 נוירונים בשימוש נדיר, בלי אימון מחדש מלא.

הנוירונים שנערכו מופעלים רק כשמופיעה מחרוזת trigger שנבחרה (בקלט משתמש או בפלט כלי) וכופים על המודל לפלוט פקודה שבחר התוקף, token אחר token. סוכן שמשתמש במודל מריץ אז את הפקודה עם ההרשאות שלו. הצוות בדק את זה בהצלחה על מודלים open-weight, כולל Nemotron-Terminal-8B (7 נוירונים, הצלחת trigger של כ-99%), Qwen3.6-27B ו-Gemma-4-31B-IT.

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

מי מושפע

ארגונים שפורסים סוכני AI הנשענים על checkpoints של מודלים open-weight או מצד שלישי, ובמיוחד כאלה שנמשכו מ-hubs ציבוריים, עברו fine-tune פנימי או הגיעו דרך נתיבי שרשרת אספקה.

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

למה זה חשוב

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

זה מעלה את סיכון שרשרת האספקה למערכות AI: כל מי שיכול לשנות checkpoint (גורם פנימי, פרטי הזדהות גנובים או מפרסם ב-hub ציבורי) יכול להטמיע התנהגות זדונית מתמשכת שמופעלת ב-trigger, בלי לשנות קוד ובלי צורך במחשוב כבד.

איך אפשר היה למנוע את זה

השוו כל checkpoint מול מודל הבסיס המוצהר שלו לפני פריסה ואחרי עדכונים; דחו כל אחד שבסיסו לא ניתן לאימות. הורידו רק ממפרסמים מקוריים, אמתו hashes, והתייחסו ל-fine-tunes, merges, quantizations ו-adapters מצד שלישי כאל לא מהימנים עד לביקורת.

שמרו מודלים מאושרים ב-registry פרטי וחסמו משיכה ישירה של סוכנים מ-hubs ציבוריים. הריצו סוכנים בהרשאות מינימליות, בצעו sandbox לכל קוד שנוצר, הגבילו חיבורים יוצאים ודרשו אישור אנושי לפעולות בעלות השפעה גבוהה. הוסיפו סריקה לדלתות אחוריות ברמת המשקלים וברמת ההתנהגות.

מה קרה

CISA הוסיפה ארבע פגיעויות לקטלוג Known Exploited Vulnerabilities (KEV) שלה, על בסיס ראיות לניצול בפועל: CVE-2026-123218 (IBM Aspera Faspex, CVSS 9.8), CVE-2026-116779 (SignalWire FreeSWITCH, CVSS 9.8), CVE-2026-123158 (OpenBSD OpenSSH ב-Linux, הידועה גם כ-SSHole, CVSS 8.1), ו-CVE-2026-102895 (GPUStack, CVSS 9.8).

הפגיעות CVE-2026-123158 מאפשרת עקיפת אימות בתצורות מסוימות של musl libc ללא PAM, כשמספקים סיסמאות ארוכות. ניסיונות הניצול החלו בסביבות 6-7 בנובמבר 2026. לאחר הניצול נצפו שאילתות metadata בענן, גניבת password-hash ומפתחות SSH, שינוי authorized_keys, ופריסת סוכן C2 ב-Python (TAC Agent), לצד פעילות botnet וכורה.

הפגיעות ב-IBM מאפשרת למשתמש מאומת לבצע הסלמת הרשאות ל-admin מלא באמצעות הודעה שנבנתה במיוחד. ב-FreeSWITCH קיימת הזרקת קוד שמובילה לחשיפת פרטי הזדהות ולהרצת פקודות. אימות לקוי ב-GPUStack (אמון localhost כברירת מחדל) מאפשר גישת admin ללא אימות, חשיפת סודות והרצת קוד.

מי מושפע

משתמשים ב-IBM Aspera Faspex 5.0.0 עד 5.0.19, ב-FreeSWITCH לפני 1.11.3, ב-OpenSSH לפני 10.6p2 ב-Linux עם musl libc וללא PAM, וב-GPUStack לפני 2.2.0.

החשיפה ב-OpenSSH רלוונטית במיוחד למערכות Alpine ולמערכות דומות מבוססות musl. מערכת GPUStack משפיעה על מפעילי שרתי מודלי AI ואשכולות GPU. ההיקף כולל כל סביבה חשופה לאינטרנט או עם סגמנטציה לקויה של המוצרים האלה; סוכנויות פדרליות וארגונים רבים כפופים למועדי יעד מחייבים לתיקון לפי KEV.

למה זה חשוב

כל ארבע הפגיעויות מאושרות כמנוצלות בפועל ונושאות השפעה קריטית או גבוהה: השתלטות admin מלאה, RCE, גניבת פרטי הזדהות וגישה מתמשכת. OpenSSH הוא רכיב תשתית יסודי, ולכן עקיפות מובילות במהירות ל-root ולתנועה רוחבית.

הכנסה ל-KEV של CISA מפעילה מועדי יעד מחייבים לתיקון עבור סוכנויות אזרחיות פדרליות בארה"ב, ומסמנת עדיפות גבוהה לעדכון גם לכל השאר. רדיוס הפגיעה המשולב בתשתיות העברת קבצים, טלקום, SSH ו-AI הוא רחב.

איך אפשר היה למנוע את זה

עדכנו מיד לגרסאות המתוקנות: גרסאות IBM Aspera Faspex שאחרי נובמבר 2026, FreeSWITCH 1.11.3 ומעלה, OpenSSH 10.6p2 ומעלה, ו-GPUStack 2.2.0 ומעלה.

תעדפו ממשקים חשופים לאינטרנט וממשקי ניהול. עבור OpenSSH, בדקו את תצורות musl/PAM ונטרו ניסיונות אימות עם סיסמאות ארוכות ושינויים ב-authorized_keys. הגבילו את הגדרות האימות ב-GPUStack (בטלו את אמון force_auth_localhost). יישמו סגמנטציית רשת, הרשאות מינימליות, ונטרו את התנהגויות ה-post-exploitation שדווחו (גישה לשירות metadata, TAC Agent, פעילות כורה).

מה קרה

חוקרי Intezer הדגימו שמערכות AI מודרניות הופכות הנדסה לאחור של תוכנה מרכזית מורכבת ושל נוזקה לקלה ומהירה בהרבה משיטות ידניות מסורתיות.

הם בנו harnesses ייעודיים למשימה (סוכני orchestrator לצד כלי ניתוח סטטי, קומפיילרים, VMs ומספר LLMs), ופרקו בהצלחה, מיפו ושיחזרו במידה רבה את Slack, את Finder של Apple, ואפילו pipeline עובד של נוזקת Turla. נוזקה הייתה היעד הקשה ביותר, ובכל זאת התקבלה תמונה מלאה של מנגנון ה-C2 ושל העברת הקבצים. דיווחים של Anthropic כבר מראים שגורמי איום מדינתיים (כולל Midnight Blizzard) משתמשים ב-Claude להנדסה לאחור של SDK ולניתוח מוצרי אבטחה.

כלים בקוד פתוח כמו REA (Reverse Engineer Anything) זינקו בפופולריות, והורידו עוד את רף המיומנות הנדרש.

מי מושפע

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

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

למה זה חשוב

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

מגינים יכולים לנתח איומים מהר יותר, אך אותה יכולת מאיצה גם עבודה התקפית ומעלה את מחיר השמירה בסוד על מימושים קנייניים. טכניקות ערפול (obfuscation) ו-anti-analysis ניצבות מול תוחלת חיים קצרה יותר ככל שהמודלים משתפרים מדי חודש.

מה קרה

ESET גילתה ערכת כלים מודולרית ב-.NET שכינתה Turla's Cereal, המיוחסת בביטחון גבוה לקבוצת התקיפה Turla המיושרת עם רוסיה (עם זיקה ל-FSB). ערכת הכלים רצה על שרתי Microsoft Exchange שנפרצו, מקבלת פקודות, מורצת בזיכרון, ממפה את הארגון ואוספת בשקט מיילים נבחרים.

נצפתה לראשונה בשרת Exchange ממשלתי בקזחסטן ב-28 בנובמבר 2025 ובסוכנות ממשלתית ברומניה ב-23 בדצמבר 2025. ברומניה היא הוגדרה למקד הודעות אל כתובות NATO ו-EU או מהן. לא נעשה שימוש בתשתית C2 חיצונית; שרת ה-Exchange של הקורבן עצמו מגויס כערוץ הפקודות דרך נתיבים שמחקים תעבורת OWA, Autodiscover ו-ActiveSync רגילה.

הרכיבים מוזרקים לתהליכי Exchange לגיטימיים (כולל ה-transport pipeline) ומשאירים מינימום של ארטיפקטים בדיסק.

מי מושפע

ארגונים ממשלתיים וארגונים בעלי ערך גבוה שמריצים Microsoft Exchange on-premise, במיוחד כאלה שמעניינים את המודיעין הרוסי (כבר נצפו בקזחסטן וברומניה).

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

למה זה חשוב

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

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

איך אפשר היה למנוע את זה

הקשיחו ונעלו את Exchange on-premise: החילו את עדכוני ה-cumulative העדכניים ביותר, הפעילו auditing מתקדם של transport ושל process injection, וצודו מודולים חריגים שנטענים ל-EdgeTransport.exe או לתהליכים דומים.

בדקו נתיבי web חריגים תחת /owa/, /autodiscover/ ו-ActiveSync שנושאים payloads מוצפנים. בצעו סגמנטציה לניהול ה-Exchange והגבילו יכולות יוצאות. פרסו זיהויים של ESET או מקבילים ל-IoCs שפורסמו של Cereal ולתבניות serialization של .NET. הניחו שנפרצתם ובדקו לוגים של mail-flow לאיתור איסוף סלקטיבי של תעבורה הקשורה ל-NATO/EU.

מה קרה

חברת האבטחה Claroc גילתה שמתוך 37,571 אפליקציות חיות שנבנו ב-Grok Build (פיצ'ר chat-to-app של SpaceXSI/xAI), 35,578 (94.7%) היו נגישות לציבור בלי שום התחברות.

האפליקציות מקבלות subdomains תחת grok.me; אחרי ביקור, רשומות Passive DNS הופכות את השמות לגילויים. הגדרת הפרסום כברירת מחדל בבדיקה של החוקרים הייתה "Anyone with the link". בין האפליקציות הפתוחות היו 24 שבנו עובדי X ו-SpaceXSI, ובהן תוכניות onboarding חסויות, מפת טריטוריות מכירה של 594 חשבונות, והצעות פרסום (אחת סומנה כחסויה לסוכנות פדרלית בארה"ב). בערך אחת מכל עשר אפליקציות פתוחות הכילה נתונים עסקיים פנימיים או אישיים מ-30 ארגונים מזוהים נוספים, כולל שישה מ-Fortune 500.

בין החשיפות שאומתו: רשימת עובדים של בית חולים עם יותר מ-3,500 שמות, תדריך מטופל ב-ICU, לוח משמרות של מכבי אש, וגיליון שעות של קבלן עם סיסמאות עובדים בטקסט גלוי. SpaceXSI הסירה את 24 האפליקציות שלה אחרי ההודעה, אבל השאירה אחרות פעילות.

מי מושפע

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

עובדי X/SpaceXSI ומשתמשים בכל תוכניות Grok שלחצו Publish בלי לשנות את ברירת המחדל. Passive DNS הפך את הגילוי לפשוט לכל מי שספר subdomains של grok.me.

למה זה חשוב

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

זה ממחיש סיכון קלאסי של shadow-IT ו-vibe coding: יצירת אפליקציות מהירה בלי ברירות מחדל אבטחתיות ובלי סקירה יוצרת חשיפה רחבת היקף. בונים דומים (למשל ChatGPT) מגדירים ברירת מחדל מגבילה יותר, ומדגישים פער בתכנון המוצר.

איך אפשר היה למנוע את זה

בדקו מיד כל אפליקציית Grok Build שפורסמה, ושנו את הגישה ל-"Only you" או "Invited users". מחקו או בטלו פרסום של כל אפליקציה שמכילה נתונים רגישים. בצעו רוטציה לכל סיסמה, מפתח API או פרטי הזדהות שנחשפו.

התייחסו לבוני אפליקציות AI כמו למערכות production: אל תטמיעו סודות בקוד client-side, סרקו PII/PHI לפני פרסום, ואכפו מדיניות private-by-default. מפו נכסים ב-grok.me דרך Passive DNS והדריכו עובדים בהגדרות גישה. העדיפו בונים שברירת המחדל שלהם פרטית.

מה קרה

תוקף ניצל פגיעות הרצת קוד מרחוק (RCE) במנוע ה-inference בקוד פתוח SGLang והשיג הרצת קוד על אחד משרתי ה-inference של NEAR AI ב-8 בנובמבר 2026.

משם יכול התוקף לצפות בבקשות שעובדו באותו יום, כולל בקשות במצב confidential (שפעלו בתוך TEE). סביבת TEE אינה מגנה מפני פגמים בתוכנה שרצה בתוכה. לאחר מכן הגיע התוקף ל-backend מיושן של Private Chat, והוריד פרטי חשבון (אימיילים, שמות, ולחלק מהמשתמשים גם מידע על תוכנית/יתרה) של כ-100 משתמשים. לא נמצאו ראיות לגישה לשיחות שמורות או לקבצים שהועלו.

התוקף גם ניגש ל-18 AI agents בסביבת legacy ללא TEE, וביצע הוצאת נתונים (exfiltration) של היסטוריית צ'אט, הגדרות ולוגים. שני מפתחות API של NEAR AI Cloud של לקוחות הופיעו בקבצי הלוג ובוטלו. NEAR AI בלמה את האירוע, החילה תיקון ל-SGLang בכל השרתים, ביצעה רוטציה לפרטי הזדהות והחזירה את השירות.

מי מושפע

משתמשי NEAR AI Cloud שבקשותיהם הגיעו לשרת ה-inference שנפרץ ב-8 בנובמבר, כ-100 משתמשי Private Chat שמטא-דאטה של חשבונותיהם נלקח, 18 ה-agents בסביבת ה-legacy, ושני הלקוחות שמפתחות ה-API שלהם נחשפו.

כל ארגון שמריץ SGLang ללא תיקון ל-inference של מודלים חשוף לסיכון RCE דומה. NEAR AI הודיעה ישירות לגורמים שנפגעו; אחרים אינם נדרשים לפעולה מעבר לערנות כללית.

למה זה חשוב

גם סביבות confidential computing / TEE חזקות רק כמו הקוד בתוך ה-enclave. פגיעות RCE במנוע ה-inference שברה את הבטחת הפרטיות ואפשרה תנועה פנימית נוספת.

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

איך אפשר היה למנוע את זה

החילו את תיקון ה-SGLang שפרסה NEAR AI (דווחו על הפגיעות ל-upstream אם היא עדיין לא פומבית). בודדו שרתי inference, בטלו ובצעו רוטציה לכל הסשנים, לפרטי הזדהות של admin, ל-tokens של agents ולמפתחות API אחרי כל חדירה חשודה.

השאירו שירותים מיושנים offline או בסגמנטציה חזקה. נטרו הרצת קוד בלתי צפויה ותנועה רוחבית מצומתי inference. אם קיבלתם מייל מ-security@near.ai, פעלו לפי השלבים שסופקו; אחרים, התייחסו בזהירות להודעות לא מבוקשות על חשבון או יתרה. העדיפו סביבות TEE שגם אוכפות הרשאות מינימליות וסריקת dependencies סדירה בתוך ה-enclave.