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

מה קרה

שלושה צוותי מחקר פרצו מרחוק למכשירי Google Pixel 10 מעודכנים במלואם ב-8 באוקטובר, ב-Pwn2Own Ireland בקורק. כללי התחרות מחייבים שהיעדים יהיו מעודכנים במלואם, ומשלמים על אקספלויטים עובדים שמועברים אחר כך לספקים.

Ikotas Labs זכתה בפרס הראשון של 300,000 דולר ובניצחון הכללי עם שרשרת מרובת פגיעויות שסומנה כ-collision. Xint הרוויחה 150,000 דולר על collision של באג בודד, וצוות שלישי שכלל את דימיטריוס ולסאמראס (Dimitrios Valsamaras), קן גנון (Ken Gannon) וטניה ולסאמרה (Tenia Valsamara) קיבל 112,500 דולר על שרשרת של שני באגים ששילבה collision ו-zero-day. סך הפרסים על שלושת הניצחונות ב-Pixel הגיע ל-562,500 דולר.

כל ההגשות נרשמו כאקספלויטים מרחוק דרך דפדפן ברירת המחדל או ממשקי רדיו (NFC, Wi-Fi, Bluetooth או baseband). יוזמת Zero Day Initiative (ZDI) של Trend Micro לא פרסמה פרטים טכניים על האקספלויטים.

מי מושפע

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

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

למה זה חשוב

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

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

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

החילו עדכוני אבטחה של Google Pixel מיד כשהם מתפרסמים אחרי חלון הגילוי של הספק. הגבילו תוכן אינטרנט לא מהימן וממשקי רדיו מיותרים (NFC, Bluetooth) דרך MDM או מדיניות משתמש, היכן שניתן.

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

מה קרה

חבילת npm בשם tensorlake, SDK ב-TypeScript ליישומי Tensorlake, נפרצה במתקפת שרשרת אספקה מסוג ChainDrop / Shai-Hulud. הגרסה הזדונית 0.5.144 כללה נוזקה מעורפלת (obfuscated) שאספה פרטי הזדהות, ביצעה הוצאת נתונים (exfiltration) של סודות, הקימה persistence ויכלה להריץ קוד שסופק מרחוק.

הנתונים שהיו יעד כללו tokens של npm ו-GitHub, פרטי הזדהות של AWS ו-Kubernetes, מפתחות SSH, ארנקי קריפטו וקבצי קונפיגורציה לכלי AI כמו Anthropic Claude. הנוזקה גם פרסה את הבינארי HackBrowserData והשתמשה בחוזה Ethereum ל-C2, עם GitHub כגיבוי.

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

מי מושפע

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

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

למה זה חשוב

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

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

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

הסירו מיד את tensorlake בגרסה 0.5.144 אם היא מותקנת. בצעו רוטציה לכל פרטי ההזדהות שעלולים היו להיחשף: tokens של npm, tokens של GitHub, מפתחות AWS, פרטי הזדהות של Kubernetes, מפתחות SSH וכל סוד של כלי AI או ארנק.

קבעו pin לגרסאות חבילות, הפעילו lockfiles, השתמשו ב-npm audit ובסורקים דומים, העדיפו חבילות עם provenance מאומת ואישורי Sigstore, והגבילו סקריפטי install ב-CI. נטרו פעילות רשת לא צפויה ל-Ethereum או שימוש חריג ב-GitHub משרתי build.

מה קרה

CrowdStrike דיווחה שגורם איום החשוד כפועל מסין, בעל מניע כלכלי, השתמש בכלי ה-pentesting הסוכני (agentic) בקוד פתוח ARTEX יחד עם המודל Claude של Anthropic, בקמפיין נגד ארגונים פיננסיים בדרום קוריאה מסוף ספטמבר עד תחילת אוקטובר 2026.

ARTEX שימש בעיקר לגילוי פגיעויות ולחדירה לשירותים. הגורם גם פנה אל Claude בבקשה לעזרה באיתור קבוצות קוריאניות למכירת נתונים ב-Telegram, כדי לממש כספית את המידע הגנוב. תשתית שמקושרת לכתובת IP בודדת אירחה סביבת ARTEX וספריות פתוחות עם prompts ל-pentesting בסינית, חומרי Claude Code והיסטוריות סשנים. ה-backends כללו את המודלים DeepSeek, GLM ו-Grok.

בפריצות שדווחו ב-Shinhan Bank וב-Yegaram Savings Bank נפגעו כ-25,000 וכ-40,000 אנשים בהתאמה; גם חברות נוספות נפגעו. הוועדה לשירותים פיננסיים של דרום קוריאה (Financial Services Commission) פרסמה התראת צרכנים בנוגע לפישינג ולהונאות הלוואות.

מי מושפע

מוסדות פיננסיים בדרום קוריאה ולקוחותיהם, כולל לקוחות Shinhan Bank ו-Yegaram Savings Bank שמידע שלהם נחשף לפי הדיווחים. מתווכים ועובדים שהשתמשו במערכות שאילתות הלוואות או במערכות תמיכה לעבודה ניידת שנפרצו.

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

למה זה חשוב

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

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

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

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

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

מה קרה

פגיעות קריטית לגישה שרירותית לקבצים, שמזוהה כ-CVE-2026-21589 ודורגה ב-CVSS 9.3 על ידי Atlassian, מדווחת כמנוצלת בשטח. היא משפיעה על שמונה מוצרי Data Center בניהול עצמי: Bitbucket, Confluence, Jira Service Management, Jira Software, Bamboo, Crowd, Crucible ו-Fisheye.

תוקפים ללא הרשאות יכולים לקרוא קבצים ספציפיים תחת שורש אפליקציית ה-web של כל מוצר, בעקיפת הגנות path-traversal בספרייה המשותפת atlassian-plugins-webresource. WatchTowr הראתה שהפגיעות יכולה לחשוף פרטי הזדהות של Crowd השמורים בקבצי קונפיגורציה של מוצרים משולבים, ועלולה לאפשר ניצול זהויות בהמשך.

VulnCheck ואחרים סימנו פעילות ניצול. הפגיעות אינה מופיעה ב-CISA KEV במועד הנתונים המאומתים.

מי מושפע

ארגונים שמריצים מהדורות Data Center בניהול עצמי של Atlassian ל-Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible או Fisheye, ובמיוחד סביבות החשופות לאינטרנט.

ארגונים שמשלבים את Crowd לאימות מרכזי נמצאים בסיכון גבוה יותר לגניבת פרטי הזדהות וליצירה או שינוי של חשבונות בהמשך. מוצרי Atlassian באירוח SaaS או בענן מחוץ להיקף ה-Data Center שצוין.

למה זה חשוב

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

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

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

החילו מיד את התיקונים של Atlassian ל-CVE-2026-21589 על כל מוצרי ה-Data Center המושפעים. אם החלת התיקון מתעכבת, הגבילו את הגישה ברשת לסביבות, הציבו אותן מאחורי שערי אימות ונטרו את לוגי ה-web לבקשות path חריגות ל-endpoints של web-resource.

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

מה קרה

מחלקת המשפטים של ארה"ב האשימה את זוהר פנחסי (Zohar Pinhasi), בן 50, בעליה של חברת ההתאוששות מכופרה MonsterCloud שבסיסה בפלורידה, בהונאת wire fraud ובקשר להונאת wire fraud. לפי התביעה, החברה טענה שיש לה כלים קנייניים וטכניקות פענוח מתקדמות שיכולות לשחזר נתונים בלי לשלם כופר.

במקום זאת, פנחסי כביכול שילם את דמי הכופר, השיג מפתחות פענוח וגבה מהקורבנות סכומים גבוהים בהרבה מהדרישה המקורית. על פני המקרים הוא גבה מלקוחות כ-19 מיליון דולר, בעוד ששילם לפושעי סייבר כ-8 מיליון דולר. בדוגמה אחת מ-2023 הוא כביכול שילם כופר של 8,200 דולר וחייב את הלקוח ב-150,000 דולר.

MonsterCloud כבר הופיעה בחקירה של ProPublica ב-2019. אם יורשע, פנחסי צפוי לעד 20 שנות מאסר.

מי מושפע

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

קהילת קורבנות הכופרה הרחבה יותר, שפונה לחברות צד שלישי להתאוששות ולמשא ומתן.

למה זה חשוב

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

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

מה קרה

ה-handler ג'ים קלאוסינג (Jim Clausing) מ-SANS Internet Storm Center פרסם שני סקריפטי Python פורנזיים לשיחזור פעילות מסייעני קוד וסוכני AI: opencode-chat-replay.py ו-hermes_forensic_extract.py. העבודה תומכת בחומר FOR577 המעודכן, שעוסק בחקירת שימוש ב-AI במסגרת תגובה לאירועים.

הסקריפטים מכוונים ל-artifacts של OpenCode ושל Hermes. opencode-chat-replay.py הופך נתוני סשן ב-SQLite (ברירת המחדל ~/.local/share/opencode/opencode.db) לתמלילי צ'אט קריאים או לייצוא מובנה, ומתמודד גם עם טבלאות message/part ישנות וגם עם אחסון session_message המאוחד החדש יותר. hermes_forensic_extract.py שולף מערך רחב יותר, כולל שיחות, שימוש במודלים, dumps של בקשות API ולוגים של האפליקציה.

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

מי מושפע

צוותי תגובה לאירועים, אנליסטים של DFIR וצוותי אבטחה שצריכים לחקור תחנות עבודה של מפתחים או שרתים שבהם רצו סוכני קידוד מבוססי AI כמו OpenCode או Hermes. רלוונטי גם לסטודנטים של SANS FOR577 ולארגונים שמאמצים כלי pair-programming מבוססי AI.

כל מי שמשמר ראיות ממערכות שעשויות להכיל מסדי נתונים ולוגים של סשני סוכני AI.

למה זה חשוב

סוכני קידוד מבוססי AI משאירים ארטיפקטים מקומיים עשירים (prompts, קריאות לכלים, reasoning, שימוש ב-API) שיכולים להסביר איך החלה חדירה, איזה קוד או פקודות הוצעו, או האם הודבק מידע רגיש בצ'אטים. בלי parsers ייעודיים, קל לפספס את הראיות האלה או קשה לבנות מהן ציר זמן.

ככל שכלי agentic מתפשטים בסביבות הנדסה, playbooks של IR צריכים דרכים אמינות לחלץ ולבחון את מחלקת הארטיפקטים החדשה הזו לצד היסטוריית דפדפן ו-shell המסורתית.

מה קרה

IDC Frontier, חברה בת של SoftBank Group, דיווחה ששירות IDCF Cloud שלה ספג מתקפת כופרה שהחלה בסביבות 03:40 שעון מקומי ב-7 באוקטובר. המתקפה גרמה לשיבושים ב-East Japan Region 1 ואילצה כיבוי של רשתות ומערכות.

החברה בידדה מערכות שנפגעו כדי להגביל את ההתפשטות, השביתה את הגישה לקונסולת הניהול של לקוחות בכל האזורים בזמן שאימתה את האבטחה, וממשיכה לחקור את שורש הבעיה ואת ההיקף המלא. צילומי מסך של לקוחות הציגו הודעה מגורם האיום שטענה לפריצה של שבע דקות, הצפנה של 225 מסדי נתונים (כ-3.6 PB), הגעה ל-239 hypervisors, נעילה של 16,000 דיסקי VM ומחיקה של יותר מ-554,000 snapshots.

IDCF Cloud מסרה ש-495 חברות ורשויות מקומיות שמשתמשות בשירות נפגעו.

מי מושפע

495 חברות ורשויות מקומיות שמשתמשות ב-IDCF Cloud, ובמיוחד עומסי עבודה ב-East Japan Region 1. לקוחות שמסתמכים על פלטפורמת ה-IaaS לשרתים וירטואליים, אחסון ורשת במרכזי נתונים ביפן.

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

למה זה חשוב

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

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

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

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

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