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

מה קרה

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

המערכת ייצרה 948 אקספלויטים עובדים ונפרדים להסלמת הרשאות מקומית (LPE) שמעניקים למשתמש ללא הרשאות גישת root בהפצת desktop סטנדרטית, לצד תיקונים מועמדים לכל פגיעות, בעלות API כוללת של 1,213,430 דולר (כ-1,279 דולר לאקספלויט). היא התחילה מאלפי ממצאים מועמדים, שחזרה באופן דינמי 1,724 פגיעויות, וגם ייצרה 291 הוכחות היתכנות לדליפת מידע. מדגם מהאקספלויטים השתמש בלפחות 10 טכניקות שהיו חדשות אפילו למומחי קרנל חיצוניים.

מי מושפע

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

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

למה זה חשוב

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

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

מה קרה

Binarly שלפה אקספלויט מוכן לשימוש מתשתית תוקפים, שעדיין השיג הרצת פקודות OS ללא אימות במתגי סדרת Zyxel GS1900 גם אחרי שקיבלו את התיקון מיוני 2026 ל-CVE-2026-7273.

האקספלויט מכוון לפגיעות out-of-bounds write נפרדת שמתועדת כעת כ-CVE-2026-107441 (CVSS 8.8) בתוכנית ה-CGI, ושאליה ניתן להגיע דרך בקשות HTTP שנבנו במיוחד לממשק ניהול ה-web. CVE-2026-7273 (גם CVSS 8.8) נוסף ל-CISA KEV אחרי ש-GreyNoise זיהתה גורמים דוברי סינית שמשתמשים בפעילות קשורה כדי לפגוע בכמעט 1,000 מכשירים. Zyxel שחררה את התיקון ל-CVE-2026-107441 בקושחת 2.90 Patch 3 ב-22 באוקטובר, אחרי ההודעה של Binarly.

מי מושפע

מתגי רשת מסדרת Zyxel GS1900 שמריצים קושחה 2.90 Patch 2 (XXXX.2)C0 או מוקדמת יותר. עשרה דגמים מאושרים כמושפעים. ממשק הניהול חייב להיות נגיש מה-LAN לצורך ניצול ללא אימות.

ארגונים ורשתות קטנות יותר שהחילו את התיקון הקודם מתוך אמונה שהם מוגנים נשארים חשופים עד שיחילו את Patch 3.

למה זה חשוב

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

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

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

עדכנו מיד כל מתג GS1900 לגרסת הקושחה 2.90 Patch 3 של הדגם שלו. הגבילו את הגישה לממשק הניהול לרשתות מהימנות בלבד, נטרו בקשות CGI חריגות ל-dispatcher.cgi ולנקודות קצה קשורות, וחפשו סימנים לחדירה קודמת כמו שינויי קונפיגורציה בלתי צפויים או חיבורים יוצאים. אל תסתמכו על מחרוזות גרסה בלבד; אמתו את הבינארי כשאפשר.

מה קרה

פגיעות במנהל החבילות APT (CVE-2026-109518) מאפשרת לתוקף הממוקם על הנתיב, שמסוגל לתפעל תעבורת HTTP בין לקוח לשרת archive, להחליף חבילה מאומתת בחבילה שבשליטת התוקף במהלך התקנה או שדרוג.

המתקפה מנצלת redirects ושגיאות חולפות שמפעילות את התנהגות ה-retry ברירת המחדל של APT (Acquire::Retries), וגורמת ללקוח להתקין payload לא מאומת שרץ לאחר מכן כ-root. מפתחי Debian, Ubuntu ו-APT פרסמו advisories וחבילות מתוקנות ב-4 בנובמבר. Ubuntu מדרגת אותה בעדיפות גבוהה עם ציון CVSS 4.0 של 7.7. לא אושר ניצול בפועל ב-KEV.

מי מושפע

Debian 12 ומעלה, Ubuntu 22.04 LTS ומעלה, ונגזרותיהן, במערכות שבהן retries מופעלים כברירת מחדל. גרסאות ישנות יותר (Debian 11, Ubuntu 20.04 וקודמות) בטוחות בקונפיגורציית ברירת המחדל, אך נחשפות אם Acquire::Retries מוגדר לערך שאינו אפס, שינוי נפוץ בסקריפטים.

כל מערכת שמבצעת התקנות או שדרוגי חבילות מעל HTTP מ-mirrors או דרך proxies נמצאת בטווח; חבילות Snap אינן מושפעות.

למה זה חשוב

מנהלי חבילות הם הבסיס לשלמות התוכנה. מתקפת MitM שיכולה להחליף חבילה אחרי בדיקות חתימה שוברת את מודל האמון המרכזי ומניבה הרצת קוד כ-root מיידית בעת ההתקנה.

בונים ומפעילים של ציי Debian/Ubuntu, במיוחד כאלה שמשתמשים ב-mirrors פנימיים, במקורות HTTP או ב-pipelines של עדכונים אוטומטיים, מתמודדים עם סיכון בסגנון שרשרת אספקה שעלול להיות מופעל בשקט במהלך תחזוקה שוטפת.

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

החילו מיד את חבילות ה-APT המתוקנות (לדוגמה Ubuntu 22.04: 2.4.15ubuntu0.1, 24.04: 2.8.4ubuntu0.1, וגרסאות DSA/DLA המתאימות של Debian). בעת התקנת העדכון עצמו, השביתו זמנית את ה-retries באמצעות -o Acquire::Retries=0. העדיפו mirrors ב-HTTPS, בצעו pin למקורות מהימנים, ובדקו כל הגדרת Acquire::Retries מותאמת אישית. ה-advisories לא מתארים workarounds נוספים.

מה קרה

Sekoia מייחסת קמפיין watering-hole ושרשרת אספקה רחב היקף בשם Poisoned Source, שהתגלה באמצע אוקטובר 2026, ל-APT29 המקושרת לרוסיה, ברמת ביטחון בינונית עד גבוהה. התוקפים פרצו לאתרים לגיטימיים, הקימו דומיינים מתחזים, ובין 27 באוגוסט ל-3 בספטמבר 2026 הזריקו JavaScript זדוני לסקריפט Plerdy SEO Tracker בכתובת a.plerdy.com.

ה-loader מאפיין דפדפנים ומכשירים ואז מגיש שרשראות N-day ספציפיות לפלטפורמה. נתיבי iOS כוללים Class A (iOS 16.7 שמשתמש ב-CVE-2025-43529 וב-CVE-2024-27834 לגניבת cookies) ו-Class B/DarkSword (iOS 18.5 שמשלבת את CVE-2025-43529, CVE-2026-20700, CVE-2025-14174, CVE-2025-43510 ו-CVE-2025-43520 לגניבת נתוני מכשיר מלאים). ב-Android מועברות גניבת נתוני Chrome וסיסמאות Wi-Fi ללא persistence. מספר CVEs נמצאים ב-CISA KEV ומאושרים כמנוצלים בפועל.

מי מושפע

מבקרים באתרים שנפרצו או באתרים מתחזים, במיוחד יעדים בעלי ערך גבוה הקשורים להקשר של רוסיה ואוקראינה (צבא, ביטחון, תעשייה כימית, פוליטיקה ואתרים אוקראיניים שטענו את Plerdy). משתמשי iOS 16.7 ו-18.5 וגרסאות Chrome מסוימות ב-Android הם קורבנות המובייל העיקריים.

אלפי אתרים שכללו את ה-tracker של Plerdy במהלך חלון ההזרקה היו וקטורי מסירה פוטנציאליים.

למה זה חשוב

חדירה בודדת לשרשרת האספקה של analytics לצד watering holes קלאסיים יכולה להעביר בשקט ערכות אקספלויט למובייל ברמה מסחרית למשתמשים בעלי עניין אסטרטגי. גניבת נתוני מכשיר מלאים (הודעות, keychain, תמונות, פרטי הזדהות) או הוצאת נתונים (exfiltration) של cookies וסיסמאות Wi-Fi מתרחשת בלי צורך ב-persistence.

מפעילי אתרים בעלי ערך גבוה וציי מכשירי מובייל חייבים להתייחס לסקריפטים של צד שלישי כסיכון גבוה ולשמור על מערכות ההפעלה למובייל מעודכנות במלואן; N-days נשארים אפקטיביים מול משתמשים שמפגרים בעדכונים.

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

עדכנו את iOS/iPadOS ואת Android/Chrome לגרסאות המתוקנות העדכניות ביותר שמטפלות ב-CVEs המפורטים. בדקו והסירו או שלטו בקפדנות בסקריפטי analytics ו-tracker של צד שלישי; נטרו הזרקות סקריפט בלתי צפויות. השתמשו ב-content security policies, בניטור רשת לתבניות C2 מוכרות, וחנכו משתמשים בסיכון גבוה לגבי סיכוני watering-hole. בצעו ציד אחר אינדיקטורים מהדוח של Sekoia בנכסים המושפעים.

מה קרה

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

הקורבנות נוחתים על reverse proxy חי (framework בשם Nyasher) מול דף ההתחברות האמיתי של Google. המפעיל מעביר בזמן אמת סיסמאות ואת כל גורמי ה-MFA (SMS, authenticator, Tap-Yes, recovery) ולוכד את הסשן. Operation CloudFire של Material Security חסמה עשרות אלפי הודעות, ניתחה יותר מ-2,000 כתובות URL והובילה להסרת 897 דומיינים.

מי מושפע

משתמשי Google Workspace ארגוניים שמקבלים או לוחצים על הזמנות Calendar, במיוחד אלה שאנשי הקשר שלהם או ארגוני שותפים כבר נפרצו. הקמפיין זיהה אלפי כתובות שולח שנפרצו על פני אלפי root domains.

כל ארגון שמסתמך על התחברות Google עם MFA סטנדרטי חשוף אם אפשר לפתות משתמשים לזרימה דרך ה-proxy.

למה זה חשוב

בקרות מוניטין קלאסיות של דומיין ותעודה נכשלות כי הקישורים הגלויים הם תשתית Google לגיטימית ואתגר ה-MFA הוא האמיתי. עוגיות סשן מעניקות גישה מלאה לחשבון בלי בקשות נוספות.

מגינים חייבים להתקדם מעבר לניקוד מוניטין אל זיהוי התנהגותי של ניצול לרעה של Calendar, מאפייני סשן חריגים ושיבוש תשתית מהיר; MFA לבדו אינו מספיק מול reverse proxies בזמן אמת.

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

התייחסו בחשד להזמנות Calendar בלתי צפויות גם משולחים מוכרים; אמתו בערוץ נפרד לפני הלחיצה. אכפו Phishing-resistant MFA (passkeys או מפתחות חומרה) בכל מקום אפשרי, הפעילו תכונות הגנה מתקדמות, נטרו יצירת סשנים חריגה ו-impossible travel, וחסמו או הכניסו ל-sandbox תבניות proxy מוכרות. דווחו והסירו תשתית זדונית במהירות; בדקו הרשאות OAuth ואפליקציות צד שלישי אחרי כל חשד לחדירה.

מה קרה

גורמים לא מורשים השתלטו על בקרי קירור בשלושה אתרים של שירות הדם הלאומי של צרפת (EFS) בלילה שבין 1 ל-2 בנובמבר 2026, והעלו את ערכי ה-setpoint של טמפרטורה והפשרה בחדרי קירור שבדרך כלל מחזיקים פלזמה ודגימות סביב -30°C עד ל-110°C (230°F).

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

מי מושפע

מתקני אחסון קר של EFS (בעיקר בורגונדיה ו-Franche-Comté) שמחזיקים פלזמה לעירויים ולייצור תרופות, לצד דגימות לניטור בריאות. לקוחות Coolworld שמשתמשים ברכיבי הניטור מרחוק המושפעים בצרפת, ופוטנציאלית גם במדינות אחרות.

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

למה זה חשוב

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

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

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

בצעו סגמנטציה והגבילו בחומרה גישה מרחוק לבקרי קירור ו-BMS. דרשו MFA, allow-listing וניטור של שינויי setpoint. תחזקו אזעקות מקומיות עצמאיות ומענה כוננות שאינם מסתמכים רק על ענן הספק. ערכו מלאי של רכיבי צד שלישי, החילו תיקונים או צעדי מיטיגציה זמינים מ-Coolworld ומהספקים שלה, ותרגלו failover פיזי של מחסנים קריטיים. דווחו ל-CERTs לאומיים מיד על חריגות.

מה קרה

Binance פרטה חדירה שנמשכה חודשים והסתיימה בגניבה של כ-6.3 עד 6.34 מיליארד דולר בנכסי קריפטו. גורמי איום מצפון קוריאה (יחידת TraderTraitor המיוחסת ל-FBI) השתמשו בהנדסה חברתית ובנוזקה: ביוני מהנדס Wallet DevOps הוריד מתקין Homebrew ששונה דרך מודעת חיפוש זדונית; בספטמבר מהנדס נוסף (Software Engineer B) פותה דרך פלטפורמת משרות לגיטימית לראיונות מזויפים מרובי סבבים שהסתיימו ב'מטלה' של מאגר קוד זדוני על מחשב עבודה.

הנוזקה מסוג zero-day עקפה כלי endpoint, החליפה רכיב לגיטימי והקימה C2. בהמשך ניצלו התוקפים כלי AI פנימי ו-tokens גנובים כדי להגיע למהנדסים נוספים, לפרוס קונטיינר, וב-29 באוקטובר לאשר משיכות מהירות מארנקים חמים (מאות מיליונים של XRP, SOL ו-OP). Binance בנתה מחדש מערכות, הקפיאה או שיחזרה חלק גדול מהנכסים, ומצהירה שהמשתמשים מקבלים פיצוי מלא.

מי מושפע

תשתית הארנקים החמים של Binance והמהנדסים הספציפיים ש-endpoints ופרטי ההזדהות שלהם נפרצו. משתמשי הקצה של הבורסה חוו שיבוש זמני במשיכות אך לפי החברה אינם נושאים בהפסד.

תעשיית הקריפטו הרחבה נשארת יעד בעדיפות גבוהה ליחידות DPRK שמשתמשות שוב ושוב בפיתויי גיוס מזויף ובשרשרת אספקה נגד מפתחים.

למה זה חשוב

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

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

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

אכפו הפרדת תפקידים קפדנית ובקרות מבוססות חומרה לחתימת ארנקים; אל תאפשרו מטלות ראיון או מאגרים לא מאומתים על תחנות production או תחנות בעלות הרשאות. השתמשו במקורות חבילות ב-allow-list, בבקרת אפליקציות וב-EDR התנהגותי שתופס החלפת רכיבים. בצעו רוטציה של פרטי הזדהות ובנו מחדש אחרי כל חריגה, הגבילו הרשאות של כלי AI, והריצו תרגילי red-team רציפים נגד תרחישי גיוס ושרשרת אספקה. נטרו TTPs המקושרים ל-DPRK ושתפו אינדיקטורים ברחבי התעשייה.