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

מה קרה

Cisco חשפה שתוקפים ניצלו את CVE-2026-76504 כ-zero-day ב-Catalyst SD-WAN Manager. צוותי התגובה של היצרן למדו על ניצול בפועל בספטמבר 2026, תוך טיפול בפניית תמיכה ב-TAC.

הפגיעות היא עקיפת אימות ב-API שנגרמת מטיפול לקוי בקידוד URI בבקשות HTTP. תוקף מרוחק ללא הרשאות יכול לשלוח בקשה שנבנתה במיוחד, לעקוף הגבלות ולקבל גישת admin ל-API, ובכך להשתלט פוטנציאלית על הרשת המנוהלת. ציון ה-CVSS הוא 9.8, והפגיעות מופיעה ב-CISA KEV.

Cisco פרסמה אינדיקטורים לחדירה בקבצי serviceproxy-access.log ו-vmanage-server.log, אך שיתפה מעט פרטים על התקיפה. זהו הגילוי החמישי השנה של zero-day בקו Cisco SD-WAN.

מי מושפע

ארגונים שמריצים Cisco Catalyst SD-WAN Manager בגרסאות 26.2, 26.1, 20.18, 20.15, 20.12, 20.9, וכל גרסה מוקדמת מ-20.9, ללא תלות בקונפיגורציה.

ארגונים וספקי שירות הנשענים על Cisco SD-WAN לניהול רשתות WAN חשופים, במיוחד כאלה עם קונסולות ניהול נגישות מהאינטרנט. סוכנויות אזרחיות פדרליות בארה"ב כפופות למועד יעד מנדטורי של CISA ב-3 באוקטובר 2026, בתוספת הערכת חדירה נדרשת.

למה זה חשוב

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

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

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

החילו את עדכוני האבטחה ש-Cisco שחררה לגרסאות 20.9 עד 26.2. העבירו מערכות ישנות מ-20.9.10.1 לגרסה מתוקנת; אין עקיפות שמכסות את הבעיה במלואה.

בפריסות on-premise, הגבילו גישת ניהול מרשתות לא מהימנות כמו האינטרנט, וצמצמו את החשיפה למארחים מהימנים ידועים בפורטים מתועדים. לפני העדכון או מיד אחריו, אספו לוגים ו-snapshots של מכשירים, ואז אתרו את ה-IoCs שפורסמו תוך התחשבות באפשרות של false positives בפעילות שוטפת. פתחו פניית TAC אם נדרשת עזרה בחקירה.

מה קרה

חוקרי אבטחה ב-Calif פרסמו את ה-proof-of-concept הציבורי הראשון ל-CVE-2026-86950, כתיבה מחוץ לגבולות (out-of-bounds write) ב-framework של CoreGraphics ב-Apple. Apple כבר החילה תיקון ב-28 בספטמבר, וציינה שייתכן שהפגיעות נוצלה במתקפות מתוחכמות במיוחד נגד אנשים ספציפיים שמוקדו בגרסאות iOS ישנות.

הטריגר הוא PDF זדוני שנבנה במיוחד ומכיל גופן TrueType מוטמע עם קואורדינטות glyph קיצוניות. התוצאה היא buffer overflow מבוקר במהלך rasterization, שמוביל לקריסה ב-iPhone וב-Mac שלא עודכנו. החומר שפורסם מדגים את הקריסה ואת ה-primitive של memory corruption, אך אינו כולל אקספלויט מלא להרצת קוד. CISA הוסיפה את ה-CVE לקטלוג ה-KEV שלה יום לאחר התיקון, עם מועד יעד פדרלי לתיקון ב-2 באוקטובר.

ציון ה-CVSS הוא 8.8. אותו תיקון הוחל על מספר פונקציות rasterizer; שורש הבעיה היה טיפול לא עקבי בהמרות מ-floating-point ל-fixed-point מחוץ לטווח, שיצרו buffer עבודה קטן מדי.

מי מושפע

משתמשים ב-iOS 26.7 וגרסאות מוקדמות יותר שלא עודכנו, במקבילות ב-iPadOS, ב-macOS Sequoia 15.8 וגרסאות מוקדמות יותר, וב-macOS Tahoe 26.7 לפני עדכוני 26.7.1 / 15.8.1. Apple לא כללה את iOS 27 או את macOS Golden Gate 27 כמושפעות.

בעיקר אנשים שמוקדו בעבר במתקפות סלקטיביות מאוד, וכל מי שפותח קובצי PDF לא מהימנים במכשירים שעדיין פגיעים, עכשיו כשקיים PoC ציבורי. אפליקציות מסרים שמייצרות אוטומטית thumbnails של PDF או של קבצים מצורפים (החוקרים בחנו שינויים ב-WhatsApp) הן נתיב מסירה סביר.

למה זה חשוב

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

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

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

עדכנו מיד ל-iOS/iPadOS 26.7.1, ל-macOS Sequoia 15.8.1, ל-macOS Tahoe 26.7.1 או לגרסה מאוחרת יותר. לא תועדה עקיפה למערכות שלא ניתן לעדכן.

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

מה קרה

מיקרוסופט דיווחה שקבוצת התקיפה Star Blizzard, המקושרת לרוסיה (מנוטרת גם כ-Callisto ו-ColdRiver, ומשויכת על ידי ממשלות מערביות ל-FSB), הרחיבה משמעותית את פעילות הפישינג שלה השנה. הפעילות פגעה ביותר מ-100 ארגונים, בעיקר בארה"ב ובבריטניה.

הקבוצה עברה מ-spear-phishing ממוקד מאוד לקמפיינים גדולים יותר של עשרות או מאות הודעות, בעזרת פלטפורמת דיוור המוני. לפחות 13 קמפיינים כאלה נצפו מאז ינואר 2026. המשלוח נעשה כיום לעיתים קרובות דרך חשבונות שנוצרו באתרים שנפרצו, ולא דרך webmail חינמי. אחרי שהקורבן משיב, המפעילים שולחים ארכיון מוגן בסיסמה; פתיחת קובץ בתוכו מפעילה את טכניקת RedFlick החדשה.

RedFlick מתקינה את הדלת האחורית CosmicPulse דרך scheduled tasks בפעולת משתמש אחת בלבד, ומשפרת את שיטת ClickFix הקודמת שדרשה כמה שלבים. פיתיונות תחילת 2026 התמקדו במשתמשי Ukr.net אוקראינים עם הודעות מס או קנס מזויפות; גלים מאוחרים יותר השתמשו בהזמנות לכנסים ובהודעות שנראות פנימיות, שכוונו ל-NGO, לthink tanks, לממשלות ולמוסדות פיננסיים שתומכים באוקראינה.

מי מושפע

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

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

למה זה חשוב

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

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

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

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

דרשו אימות רב-שלבי עמיד לפישינג (phishing-resistant MFA), הגבילו יצירת scheduled tasks ככל האפשר, וצודו אחר אינדיקטורים הקשורים ל-CosmicPulse ורישומי משימות חריגים. הכשירו את הצוות על המעבר מ-spear-phishing קלאסי לפיתיונות בנפח גבוה מאתרים שנפרצו ולהודעות שנראות פנימיות. בצעו סגמנטציה לרשתות תמיכה באוקראינה בעלות ערך גבוה ונטרו גניבת פרטי הזדהות או נתונים בהמשך.

מה קרה

OpenAI שיבשה קמפיין מתואם שביקש לבצע distillation ולחלץ יכולות reasoning מהמודלים שלה. פעילות ברמה נמוכה החלה בסביבות 1 ביולי 2026, עלתה לכ-16,000 prompts מ-4,000 משתמשים שהתאימו לתבנית חילוץ ב-24-25 ביולי, והגיעה לכ-15,000 משתמשים חשודים עד 28 ביולי, אז החברה קטעה את המבצע לחלוטין.

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

OpenAI ייחסה אשכול ליבה של הפעילות ליחידים המקושרים לחברת Moonshot AI הסינית, אך לא סיפקה ראיות טכניות בפוסט הפומבי שלה. נאמר שאותו סוג של פגיעות קיים גם במודלי AI אחרים; המידע שותף עם Frontier Model Forum. OpenAI חסמה חשבונות, החמירה בקרות הרשמה ותשתית, הרחיבה ניטור ותיקנה את באג הפענוח בין-שיחתי.

מי מושפע

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

ארגונים וחוקרים שמסתמכים על יכולות מודל קנייניות ניצבים בפני סיכון תחרותי וסיכון IP אם distillation מצליח בקנה מידה רחב. Moonshot AI וחברות דומות הואשמו בעבר על ידי חברות אמריקאיות ועל ידי ממשלת ארה"ב ב-distillation שיטתי.

למה זה חשוב

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

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

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

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

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

מה קרה

חוקרים מ-Glow Security גילו שסוכני קידוד מבוססי AI, כשביקשו מהם לספק תיעוד חזותי של מצב לפני ואחרי לשינויי תוכנה, העלו צילומי מסך למאגרי GitHub ציבוריים. הפרקטיקה חשפה יותר מ-13,000 צילומי מסך השייכים ליותר מ-300 חברות.

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

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

מי מושפע

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

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

למה זה חשוב

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

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

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

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

הפעילו GitHub secret scanning, ביקורות נראות של מאגרים וכללי DLP שמסמנים העלאות תמונות שמכילות תבניות רגישות. הכשירו מפתחים לסיכוני Shadow AI, אכפו שימוש בחשבונות ארגוניים, ובדקו את הרשאות הסוכנים כך שלא יוכלו להגיע למערכות חיוב production או למערכות סודיות במיוחד. נטרו באופן רציף את GitHub הציבורי לאיתור צילומי מסך הקשורים לחברה, ובטלו חשיפה במהירות.

מה קרה

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

הפעילות הזדונית המוקדמת ביותר בצומת של מוצר מושפע מתוארכת ל-31 באוגוסט 2026: סקריפט מוסתר תחת תהליך שירות קרא למשתנה סביבה שהכיל סיסמת מסד נתונים והתחבר למסד הנתונים. פעילות דומה הופיעה בצמתים אחרים בסוף ספטמבר. ב-25 בספטמבר גורם האיום ניגש לפלטפורמת הניהול של מוצר שני באמצעות זהות של עובד פנימי, הזריק פקודות, כתב קבצים זדוניים והגיש קוד דרך endpoint לביצוע web.

כלי ייעודי שמותאם ללוגיקת משיכת הארנקים ביצע את הגניבה החל מ-01:49 ב-25 בספטמבר. התקרית השפיעה על 11 בלוקצ'יינים ועל נכסים מרובים כולל XRP, ETH, USDT, ZEC ואחרים. Circle, Tether ו-NEAR Intents הקפיאו כ-1.1 מיליון דולר. Bitget הודיעה לספק והשביתה את הפונקציונליות המושפעת עד לתיקון. גם Mandiant חוקרת גישה לא מורשית לרכיבי אבטחה מסוימים של צד שלישי.

מי מושפע

Bitget והמשתמשים שלה שנכסיהם היו בארנקים החמים והפושרים שנפרצו. הגניבה השתרעה על Ethereum, XRP Ledger, Zcash, TRON, Arbitrum, Optimism, Base, BNB Smart Chain, Avalanche, Algorand ו-Celestia.

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

למה זה חשוב

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

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

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

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

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

מה קרה

Magnet Forensics, יצרנית כלי פתיחת הטלפונים GrayKey שנמכר לרשויות אכיפת חוק, טוענת שהיא יכולה לנצח את מנגנון ה-reboot בעקבות חוסר פעילות של Apple. סרטון שיווקי שדלף והגיע לידי 404 Media מתאר מכשיר חדש בשם GrayKey Preserve ומצב Evidence Preservation Mode ליחידות GrayKey קיימות.

המנגנון של Apple, שהוצג קודם לכן, מבצע reboot אוטומטי ל-iPhone שנשאר נעול 72 שעות ומחזיר אותו למצב אבטחה גבוה יותר שמקשה על חילוץ פורנזי. הפתרון של Magnet אמור להקפיא את המכשיר אחרי הגישה הראשונית, להשבית משדרי רדיו (Bluetooth, Wi-Fi וסלולר) גם כשממשק המשתמש לא מאפשר זאת, ולשמור את הטלפון במצב שמור ללא הגבלת זמן. כך הוא גם מתמודד עם מחיקה מתוזמנת של Apple לנתונים שמורים במטמון כמו מיקומים ותמונות או הודעות שנמחקו לאחרונה.

הסרטון, שמיועד ללקוחות אכיפת חוק ונראה מתחילת 2025, מכנה את היכולת game changer לפורנזיקה של iOS אך אינו מפרסם פרטים טכניים ברמה נמוכה.

מי מושפע

מעבדות אכיפת חוק ופורנזיקה שרוכשות מוצרי GrayKey, וכל משתמשי iPhone שמכשירם נתפס ומוחזק מספיק זמן כדי שנעילת ה-72 שעות בעקבות חוסר פעילות תהיה רלוונטית. מכשירים שבמצב אחר היו עוברים reboot למצב עמיד יותר יכולים כעת להישאר ניתנים לחילוץ.

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

למה זה חשוב

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

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