חדשות סייבר יומיות - 29 באוקטובר 2026

מה קרה

CISA הוסיפה פגיעות ברישום לוגים ב-VMware ESX לקטלוג Known Exploited Vulnerabilities שלה, לאחר ש-CrowdStrike דיווחה שקבוצת התקיפה Warp Panda (המזוהה גם כ-Armory Castle, Clay Typhoon ו-VerdantBamboo), המקושרת לסין, ניצלה אותה כ-zero-day בתחילת 2026.

הפגיעות היא CVE-2026-41709 (CVSS 2.7), פגיעות של רישום לוגים לא מספק. מנהל זדוני יכול לבצע פעולות מסוימות בלי שהן יירשמו, וכך נפגעת נראות מסלול הביקורת. Broadcom תיקנה אותה בגרסאות יולי 2026 עבור ESXi, Cloud Foundation, vSphere Foundation ו-Telco Cloud Platform.

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

מי מושפע

ארגונים שמריצים מוצרי Broadcom VMware ESX, ESXi, Cloud Foundation, vSphere Foundation ומוצרים קשורים ללא תיקון, ובמיוחד כאלה במגזר המשפטי בארה"ב שקבוצת Warp Panda תקפה.

כל סביבה שבה תוקף יכול תחילה להשיג גישת מנהל על ה-hypervisor או על מישור הניהול חשופה לעקיפת הרישום.

למה זה חשוב

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

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

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

החילו מיד את תיקוני Broadcom: ESXi80U3j-25429389 ואת גרסאות SXi-9.1.0.0 / ESXi-9.0.2 המפורטות עבור Cloud Foundation ו-vSphere Foundation, וכן VMware Cloud Foundation 5.2.4.

הגבילו ונטרו גישת מנהל ל-ESXi/vCenter, הפעילו רישום מקיף והעברה ל-SIEM שלא ניתנים לביטול על ידי אותו מנהל, וצודו אחר אינדיקטורים של BRICKSTORM/SharpStorm וכן אחר רישומי התקני MFA חריגים ושימוש בטוקני סשן.

מה קרה

קבוצת התקיפה Volt Typhoon, בחסות המדינה הסינית, מפעילה מסגרת ממסרים בשם Silent Train במשך שלוש שנים לפחות. היא משתמשת בשרשראות מתחלפות של התקנים שנפרצו לפי דרישה כדי להסתיר את מקור המתקפות, כולל ניצול zero-day נגד יעדים בעלי ערך גבוה.

Black Lotus Labs (Lumen) עקבה אחרי התשתית: התעבורה יוצאת מצמתי VPS חיצוניים, קופצת דרך ממסרים בחו"ל כמו מודמים של Intelbras, ואז דרך התקנים בארה"ב כמו נתבי Netgear Orbi, לפני שהיא פוגעת בקורבנות. המסגרת מנוקה אחרי כל מבצע ומתרעננת באופן רציף. היא סייעה להחליף את תשתית KV-Botnet הקודמת שה-FBI שיבש.

החוקרים אימתו ניצול של לפחות ארבע פגיעויות zero-day במערכות קצה וניהול. הפעילות מתמקדת בטלקום, ממשל, ביטחון, חינוך, שירותי תשתית, לוויינים, IT/MSPs, תחבורה, תעופה ושירותי חירום, עם ריכוז גיאוגרפי בקליפורניה, טקסס והוואי.

מי מושפע

תשתיות קריטיות בארה"ב וארגונים קשורים בתקשורת, אנרגיה, תחבורה, מים, ממשל, קבלני ביטחון, חינוך, ספקי לוויין, חברות IT, MSPs, תעופה ושירותי חירום.

כל ארגון שהתקני הקצה, ה-SD-WAN/orchestrators או מישורי הניהול שלו ניתנים לפריצה ולהפיכה לממסרים נמצא ברדיוס הפגיעה הפוטנציאלי.

למה זה חשוב

המטרה המוצהרת של Volt Typhoon היא מיקום מוקדם לקראת שיבוש אפשרי בעת משבר עתידי. שרשראות הממסרים המתחלפות והמנוקות של Silent Train מקשות הרבה יותר על ייחוס וחסימה מאשר C2 סטטי.

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

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

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

בצעו סגמנטציה לרשתות תשתיות קריטיות, אכפו הרשאות מינימליות, פרסו רישום חזק וזיהוי רשת שמחפש Living off the Land ותבניות multi-hop, והתייחסו לכל אינדיקטור מאומת של Volt Typhoon כתקרית דחופה.

מה קרה

פגיעות buffer overflow בת 16 שנה ב-EDK II, מימוש הייחוס בקוד פתוח של UEFI שרוב ספקי ה-firmware משתמשים בו, מאפשרת הרצת קוד במהלך אתחול רשת (PXE), לפני ש-Secure Boot והגנות אחרות מופעלות.

הפגיעות, שמזוהה כ-CVE-2026-97631 (CVSS 9.5 לפי TianoCore), נמצאת בטיפול של דרייבר ה-PXE בהודעות שגיאה וסטטוס של ICMP. בדיקות הגודל שגויות הן ב-IPv4 והן ב-IPv6, כך שהודעה שנבנתה במיוחד וארוכה יותר מה-buffer הקבוע של 504 בתים גורמת ל-overflow ויכולה לדרוס זיכרון סמוך. מקרה של overflow פשוט תוקע את האתחול; אקספלויט ספציפי ל-build יכול להטמיע event מזויף שמריץ קוד של התוקף בתוך ה-firmware.

הקוד הפגיע קיים מאז commit מנובמבר 2010 ומשפיע על EDK II עד כולל edk2-stable202608. אף גרסה יציבה עדיין לא כוללת את התיקון. Red Hat ו-SUSE מדרגות אותה כ-adjacent-network ולא כחשיפה פתוחה לאינטרנט. אין תיעוד של ניצול בפועל מאושר.

מי מושפע

שרתים ומערכות שמבצעים אתחול PXE/רשת ומריצים firmware של UEFI המבוסס על EDK II, כולל מוצרים של AMI, Insyde, Phoenix ו-Project Mu של Microsoft.

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

למה זה חשוב

קוד שרץ לפני Secure Boot יכול לערער את כל שרשרת האמון. גם הרצה חד פעמית מספיקה כדי להטמיע bootkit עמיד ששורד אתחולים מחדש ופועל מתחת ל-OS ולרוב כלי האבטחה.

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

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

בטלו אתחול PXE/רשת במערכות שאינן זקוקות לו. בודדו את תשתית ה-PXE ברשתות מבוקרות היטב והגבילו מי יכול לשלוח תעבורה למארחים בתהליך אתחול.

עקבו אחרי advisories של TianoCore ושל יצרני OEM לגבי גרסת ה-EDK II היציבה המתוקנת שצפויה לצאת, והחילו עדכוני UEFI של הספק מיד עם שחרורם. העדיפו measured boot ותכונות hardware root-of-trust היכן שהן זמינות.

מה קרה

החוקר אורנג' טסאי (Orange Tsai) מ-DEVCORE הדגים שרשרת באגים לוגיים טהורה שבורחת מ-sandbox של Microsoft Edge ומשיגה הרצת קוד ב-Windows, וזכה ב-175,000 דולר ב-Pwn2Own Berlin במאי 2026. הפרטים הטכניים המלאים פורסמו ב-28 באוקטובר.

לא נעשה שימוש ב-memory corruption. השרשרת מתחילה במנגנון navigation throttle של conditional access, שמייצר primitive של universal XSS (UXSS) ומאפשר JavaScript באתרים שרירותיים כולל google.com. באגים לוגיים נוספים בטיפול ב-popup, ב-auto-sign-in, ב-headers של cross-origin ב-assets.msn.com, ב-Immersive Reader (read://) ובפונקציית zip אבחונית מאפשרים כתיבת קובץ שרירותי והפיכתו להרצה. האקספלויט כולו מונה פחות מ-100 שורות.

Microsoft תיקנה את בעיות ה-Edge יום לאחר התחרות. בין ה-CVE-ים הקשורים: CVE-2026-45492, CVE-2026-45494 (שניהם CVSS 5.4) ו-CVE-2026-45495 (CVSS 8.8). הניצול מסווג כ-none; זו הייתה הדגמה בתחרות בלבד.

מי מושפע

משתמשי Microsoft Edge (מבוסס Chromium) שלא החילו את העדכונים שאחרי Pwn2Own. Edge העדכני שעודכן במלואו אינו פגיע לשרשרת הזו.

התקיפה דרשה שהקורבן יבקר בדף זדוני כשהוא מחובר לשירותי Microsoft; auto-sign-in הפך את החיבור לשכיח.

למה זה חשוב

בריחה מ-sandbox היא ההבדל בין באג web מוכל לבין חדירה מלאה למכשיר. ההדגמה ששרשרת קצרה של שגיאות לוגיות (לא בעיות memory safety) יכולה להשיג זאת מרחיבה את משטח התקיפה שעל המגינים לשקול.

זה מדגיש שאינטראקציות בין תכונות, navigation throttles, סכמות URL מותאמות וכלי אבחון יכולים להפוך ל-primitives חזקים כשמשלבים אותם.

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

ודאו ש-Microsoft Edge מעודכן במלואו כדי שתיקוני Pwn2Own יהיו במקום. שמרו על Windows ועל רכיבים קשורים מעודכנים.

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

מה קרה

החוקר העצמאי בן צימרמן (Ben Zimmermann) סרק 7.25 מיליון מאגרים ציבוריים ב-Gitee (פלטפורמת אירוח קוד סינית) ומצא 26,400 פרטי הזדהות שעדיין אומתו בהצלחה בבדיקה.

רובם היו מפתחות ענן ו-AI: 9,473 זוגות AccessKey של Alibaba Cloud, 3,805 מפתחות YouTube API, 3,170 מפתחות DeepSeek, 1,489 מפתחות Zhipu BigModel, 1,348 מפתחות OpenAI, ומספרים קטנים יותר עבור GitHub, AWS, Google Cloud ו-Gemini. אחד מהם היה פרט הזדהות פעיל ברמת מנהל ארגון לפלטפורמת AI ארגונית גדולה. הסורקים (TruffleHog ו-Kingfisher) בדקו את היסטוריית ה-commit המלאה, כך שמפתחות שהוסרו מאוחר יותר עדיין נספרו. כמעט מחציתם מתוארכים ל-commits מ-2025; חלקם היו ישנים בהרבה. צימרמן הודיע לספקים הגדולים אך לא למפתחים בודדים, ולא יכול היה לאשר ביטולים.

מי מושפע

כל מפתח או ארגון שאי פעם הכניס מפתחות ענן, AI או API פעילים למאגר ציבורי ב-Gitee. משתמשים שמסתמכים על החשבונות האלה חשופים לגניבת מכסות, חשיפת נתונים, חיובים בלתי צפויים וניצול משאבים.

השירותים עם המספרים הגבוהים ביותר (Alibaba Cloud, YouTube/Google, DeepSeek, Zhipu, OpenAI) הם החשופים ביותר במערך הנתונים הזה.

למה זה חשוב

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

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

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

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

עבור Alibaba Cloud: הנפיקו זוג AccessKey חדש, העבירו את האפליקציות, השביתו או מחקו את הישן, ובדקו את ActionTrail יחד עם לוגים ספציפיים לשירות. עבור מפתחות Google/YouTube ו-OpenAI: בצעו רוטציה, הוסיפו הגבלות API ומגבלות IP/referrer, ונטרו שימוש. לעולם אל תכניסו סודות ל-commit; השתמשו בכספות, בהזרקת environment ובסורקי סודות pre-commit.

מה קרה

GitHub השיקה מערכת firewall לחבילות npm שבודקת חבילות מול מדיניות ארגונית לפני ההתקנה. המערכת יכולה לחסום נוזקה מוכרת, חבילות עם פגיעויות קריטיות, וגרסאות חדשות לגמרי שנתוני המטא של השחרור שלהן נופלים בתוך חלון soak/cool-down שניתן להגדרה.

כל מפתח יכול להפנות את npm אל ה-firewall. הבדיקות מתבצעות לפני שהחבילה מגיעה למחשב נייד, ל-CI build או לסוכן קידוד. היכולת היא אחת מארבע יכולות אבטחה חדשות ש-GitHub הכריזה עליהן. האחרות כוללות AI Scan ל-pull requests וסריקת repo לפי דרישה (שמכסה שפות כמו PHP, Shell ו-COBOL), הרחבת Copilot Security שמציפה התראות בתוך ה-IDE, וניתוח reachability משופר של Dependabot שמראה האם פונקציות פגיעות נקראות בפועל.

מי מושפע

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

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

למה זה חשוב

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

ניתוח reachability וסריקה מוקדמת בסיוע AI מפחיתים עייפות מהתראות ועוזרים למפתחים לתקן בעיות אמיתיות לפני שהקוד מתמזג או יוצא לשוק.

מה קרה

האקר בשם Department of Peace גנב ופרסם מידע מזהה אישית (PII) על יותר מ-40,000 עובדים וקבלנים של מחלקת הביטחון הפנים של ארה"ב (DHS). הנתונים כוללים שמות, תפקידים, כתובות אימייל ארגוניות, מספרי טלפון ניידים ומיקומי משרדים.

גורם האיום טען שהמקור הוא מערכת single sign-on (SSO) של Okta שבשימוש סוכנויות DHS. ה-dump כולל גם רשומות IT והתחברות שמראות לאילו מערכות ואפליקציות פנימיות כל חשבון יכול לגשת. כ-21,000 רשומות שייכות ל-Customs and Border Protection (CBP), כ-10,000 ל-Immigration and Customs Enforcement (ICE) ול-Homeland Security Investigations, כמעט 1,000 ל-CISA, ועוד אלפים מהמטה וממרכיבים אחרים כמו USCIS ו-Federal Protective Service.

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

מי מושפע

יותר מ-40,000 עובדי DHS וקבלנים, ובמיוחד קציני CBP בנקודות כניסה, אנשי ICE/HSI, אנשי הסייבר של CISA ובכירים שפרטי הקשר הארגוניים שלהם והרשאות המערכת שלהם הפכו לציבוריים.

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

למה זה חשוב

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

גישה לנתוני הרשאות שמקורם ב-SSO חושפת גם ארכיטקטורה פנימית וחשבונות בעלי ערך גבוה שעלולים להיות מנוצלים במתקפות המשך.

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

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

התייחסו לפניות לא מבוקשות בחשד מוגבר, הפעילו Phishing-resistant MFA, ודווחו על הטרדות. לקחים רחבים יותר: החמירו את הרישום ואת זיהוי החריגות ב-SSO, צמצמו הרשאות קבועות, ובצעו סגמנטציה של גישת admin והרשאות מוגברות.