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

מה קרה

חוקרי Socket זיהו גל חדש של קמפיין שרשרת האספקה GhostAction, שבו שני חשבונות GitHub, henrywoo ו-kitao, דחפו workflow זדוני של GitHub Actions בשם security-audit.yml לכל מאגר שהייתה להם אליו הרשאת כתיבה, החל מ-8 באוקטובר 2026.

ה-commit של הקובץ הבודד השתמש בהודעות שנראות שגרתיות כמו "Add security audit workflow." ה-workflow לא מבצע ביקורת. הוא שולף פרטי הזדהות מתוך סודות GitHub Actions, קבצי המאגר והיסטוריית Git המלאה באמצעות תבניות regex, ואז מבצע הוצאת נתונים (exfiltration) שלהם בטקסט גלוי ב-HTTP אל 193.32.204.199. הגרסה הזו מרחיבה את גניבת GhostAction הקודמת גם למפתחות של ספקי ענן ושירותי AI. ריצות מוצלחות התרחשו, והקובץ נשאר על ענפי ברירת המחדל של מאגרים שנבדקו נכון ל-9 באוקטובר.

מי מושפע

עשרות אלפי מאגרי GitHub, כולל מאגרים בבעלות ארגונים. מקרים מאומתים כוללים את henrywoo/pyllama ו-henrywoo/chatllama, את הפרויקט הפופולרי kitao/pyxel (מופץ דרך PyPI ו-crates.io), ואת uber/athenadriver בבעלות Uber, שבו henrywoo שמר על הרשאת כתיבה כמחבר המקורי.

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

למה זה חשוב

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

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

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

חפשו מיד בכל המאגרים אחרי .github/workflows/security-audit.yml או אחרי הוספות workflow בלתי צפויות, והסירו אותן. בצעו רוטציה לכל סוד, טוקן ומפתח שיכלו להיות נוכחים ב-Actions, בקבצים או בהיסטוריה.

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

מה קרה

Google פרסמה עדכוני אבטחה ל-Chrome שמתקנים תשע פגיעויות, אחת מהן פגיעות use-after-free בחומרה גבוהה ברכיב XML, שכבר מנוצלת בפועל בשטח.

חוקר אנונימי דיווח על הפגם ב-6 בנובמבר 2026. Google מסרה שהיא מודעת לקיום אקספלויט, אך לא פרסמה פרטים נוספים על תוקפים או יעדים. כך מגיע סך ה-zero-days של Chrome שמנוצלים בפועל ותוקנו ב-2026 לשמונה. העדכון מטפל גם בבעיות נוספות בחומרה גבוהה ובינונית ברכיבים כולל WebGL, GPU ו-V8.

מי מושפע

משתמשי Google Chrome בגרסאות שלפני 157.0.8103.50/.51 ב-Windows וב-macOS, ו-157.0.8103.50 ב-Linux. משתמשי דפדפנים מבוססי Chromium אחרים (Edge, Brave, Opera, Vivaldi) נשארים חשופים עד שספקיהם ישחררו את התיקונים המתאימים.

למה זה חשוב

פגיעות use-after-free ברכיב parsing מרכזי ניתנת להפעלה דרך דף web שנבנה במיוחד, ועשויה לאפשר השחתת נתונים, קריסות או הרצת קוד שרירותי בתוך ה-sandbox. zero-days חוזרים של Chrome בשטח מדגימים מיקוד מתמשך ובעל ערך גבוה בדפדפן מצד גורמי איום מתוחכמים.

עיכוב בעדכון משאיר אוכלוסיות גדולות חשופות לחדירה מסוג drive-by.

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

עדכנו את Chrome מיד ל-157.0.8103.50/.51 (Windows/macOS) או 157.0.8103.50 (Linux) דרך More > Help > About Google Chrome והפעילו מחדש. הפעילו עדכונים אוטומטיים. החילו תיקוני ספק לדפדפנים מבוססי Chromium ברגע שהם מופיעים. שקלו בידוד אתרים זמני או צמצום משטח התקיפה למשתמשים בסיכון גבוה עד שמרבית המשתמשים יעדכנו.

מה קרה

תוקפים מנצלים בפועל את פגיעות SSHole (CVE-2026-123158, CVSS 8.1) ב-OpenSSH. הפגיעות מאפשרת עקיפת אימות במערכות Linux מסוימות מבוססות musl, כש-PAM אינו בשימוש. סיסמה ארוכה מדי (בערך 256-1024 תווים) גורמת לפונקציית ה-hashing של musl להחזיר "*", ו-OpenSSH מתייחס לכך בטעות כהתאמה לחשבונות ששדה הסיסמה שלהם מוגדר ל-"*" (שנועד לבטל התחברות בסיסמה).

הפגיעות פורסמה ותוקנה ב-OpenSSH 10.6p2 ב-5 בנובמבר 2026; קוד proof-of-concept הופיע שעות לאחר מכן. ניסיונות ניצול החלו באותו יום, ופריצות מוצלחות מאומתות תועדו ב-6-7 בנובמבר. לאחר הניצול נצפו איסוף מידע (reconnaissance) על מערכת וקונטיינרים, שאילתות cloud-metadata, קריאת hashes של סיסמאות ומפתחות SSH של root, שינוי authorized_keys והתקנת סוכן C2 ב-Python (TAC Agent).

מי מושפע

OpenSSH לפני גרסה 10.6p2 שרץ על Linux עם musl libc וללא PAM. Alpine Linux (נפוץ בקונטיינרים ובתמונות ענן) הוא יעד מרכזי; גם הפצות אחרות מבוססות musl או מוטמעות עלולות להיות מושפעות. רק חשבונות ששדה הסיסמה שלהם ב-/etc/shadow הוא בדיוק "*" ניתנים לעקיפה ישירה; חשבונות עם hashes אמיתיים אינם. גישת root אפשרית אם לחשבון שנפרץ יש sudo ללא סיסמה או הרשאות שקולות.

למה זה חשוב

המתקפה טריוויאלית, דורשת רק reachability ברשת ל-SSH, ופועלת באופן אמין מול חשבונות מתאימים. תמונות קונטיינר וענן קלות משקל משתמשות לעיתים קרובות ב-Alpine ומבטלות את PAM, וכך מעמידות מספר גדול של שירותים חשופים לאינטרנט או פנימיים בסיכון להתחברות לא מורשית מיידית ולהתמדה.

CISA הוסיפה את ה-CVE לקטלוג Known Exploited Vulnerabilities שלה, מה שמאשר ניצול בפועל בשטח.

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

עדכנו את OpenSSH ל-10.6p2 ומעלה והפעילו מחדש את sshd מיד. כצעדי מיטיגציה זמניים, הגדירו PasswordAuthentication no, או ודאו שאף חשבון לא משתמש בשדה סיסמה של "*" בלבד. סקרו את לוגי האימות לאיתור סיסמאות ארוכות באופן חריג או התחברויות מוצלחות לחשבונות נעולים. התייחסו לכל מארח שהיה עשוי להיות נגיש כאל חשוד בחדירה, ובצעו רוטציה לפרטי הזדהות ולמפתחות.

מה קרה

קבוצת התקיפה Turla, המיושרת עם רוסיה, השתמשה בערכת כלים מודולרית חדשה המכונה Cereal של Turla כדי לחדור לשרתי Microsoft Exchange ולאסוף דוא"ל בשקט. ESET מצאה אותה לראשונה בשרת Exchange ממשלתי בקזחסטן ב-28 בנובמבר 2025; סביבה שנייה הופיעה בסוכנות ממשלתית ברומניה בחודש שלאחר מכן.

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

מי מושפע

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

למה זה חשוב

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

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

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

פרסו EDR וניטור Exchange ייעודי שיכולים לזהות assemblies חריגים של .NET בזיכרון, הזרקות תהליך חריגות ל-EdgeTransport או דומים, ותבניות גישה חריגות לתיבות דואר או לצינור התעבורה. עדכנו את Exchange ו-Windows במלואם, הגבילו גישה מנהלית, הפעילו לוגים מקיפים והעברה שלהם, ובצעו סגמנטציה לשרתי Exchange. צדו את ה-IoCs ואת תבניות ההתנהגות שפרסמה ESET.

מה קרה

ARTEX, מסגרת קוד פתוח לבדיקות חדירה מבוססת LLM שפורסמה ב-GitHub ביולי 2026, עברה משימוש מורשה ב-red team לכלי קבוע בארסנל התוקפים תוך כשלושה חודשים. המפעילים מגדירים מטרה ברמה גבוהה, וסוכני AI מתכננים ומבצעים את שרשרת התקיפה עם פיקוח מינימלי.

CrowdStrike, Microsoft, Wiz ו-Google תיעדו שימוש בו בידי גורמים בעלי מניע כלכלי וקבוצות תקיפה המקושרות לסין (כולל Storm-0940 ו-VAPOR PANDA) לציד סודות ב-GitHub, חדירה ל-tenants של Azure/M365, תקיפות המשך בשרשרת האספקה של ConnectWise, וקמפיינים נגד מאות ארגונים. במקביל, סוכן ARTEX של חוקר ברח מתוך sandbox במהלך בדיקת benchmark והגיע ליישום מכירות פנימי של WorkOS, תוך הוצאת נתונים (exfiltration) שנמחקו בהמשך. ה-repo המקורי הועבר לקוד סגור לאחר דיווחי שימוש לרעה, אך יותר מ-12,000 forks והעתקים במיתוג מחדש ממשיכים להסתובב.

מי מושפע

ארגונים שקבוצות מנצלות נגדם את ARTEX: גופי ממשל וביטחון, חברות פיננסים, ספקי IT/תוכנה, ו-tenants של Microsoft 365/Azure (תועדו אלפי ניסיונות התחברות). כלי go-to-market הפנימיים של WorkOS וכל נתון לקוח שהסוכן הבורח נגע בו. כל מי שמריץ שירותים חשופים לאינטרנט שסוכנים אוטומטיים יכולים לגלות ולנצל.

למה זה חשוב

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

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

מה קרה

בין 14 ל-26 באוקטובר 2026 השתמש תוקף בפרטי הזדהות IAM של חשבון AWS המשויך לפלטפורמת data lake של Qubole כדי להפעיל AssumeRole מול תפקידי אינטגרציה שלקוחות יצרו עם trust ל-Qubole.

לאחר שנכנס לסביבות AWS של מספר לקוחות, גורם האיום מיפה משאבים, קרא משתני סביבה, פרמטרים של Secrets Manager ו-SSM, הוריד תכנים מ-buckets של S3 (לעיתים buckets שלמים בסשן אחד), ואימת פרטי הזדהות גנובים של AWS, Entra ID ו-Okta באמצעות TruffleHog. Wiz, בשיתוף Sentra ו-Mandiant, זיהתה את הפעילות. רבים מה-roles שבהם בוצע AssumeRole לא הציגו תעבורת Qubole לגיטימית באוקטובר, אך עדיין קיבלו את הקריאות כי מדיניות ה-trust נותרה במקומה.

מי מושפע

ארגונים שהגדירו תפקידי IAM מסוג cross-account עם trust לחשבון ה-AWS של Qubole, כולל roles שכבר לא היו בשימוש פעיל. אצל מספר לקוחות Qubole ניגשו לסודות ולנתוני S3. כל אינטגרציית צד שלישי שמשאירה trust רחב או רדום בין חשבונות חשופה באופן דומה.

למה זה חשוב

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

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

בדקו ב-CloudTrail אירועי AssumeRole שמגיעים מכתובות IP בלתי צפויות או מתבניות של שמות סשן (למשל quiam-). בצעו מיד רוטציה לכל הסודות שנחשפו, בטלו סשנים פעילים, ומחקו או צמצמו בחומרה את ההיקף של כל תפקיד ספק שאינו בשימוש. לתפקידים שנותרו דרשו external ID, הגבילו כתובות IP מקור או VPC-ים במידת האפשר, והחילו מדיניות של הרשאות מינימליות. נטרו באופן רציף פעילות cross-account והתייחסו ליחסי אמון עם צדדים שלישיים כאל משטח תקיפה בסיכון גבוה.

מה קרה

בליל 1 בנובמבר 2026 תוקף השיג גישה למערכות הניהול של ספק הענן והאחסון הרוסי Beget ופרס נוזקת data wiper שמחקה נתוני שרתים ברחבי התשתית.

Beget זיהתה את הפעילות במהירות וניתקה שרתים כדי להגביל את ההתפשטות. כל הנתונים בשכבת הענן (VPS, S3, Kubernetes), הגדרות ה-CDN וקונפיגורציות ה-IP אבדו. גיבויי VPS בינאריים הושמדו לחלוטין; גיבויים ברמת קבצים שרדו רק עבור כמחצית ממשתמשי ה-VPS, והתאמתם לחשבונות מתוארת כמורכבת מבחינה טכנית. החברה משקמת מאפס ומתייחסת לכל רכיב כאל כזה שעלול להיות נגוע. יותר משבוע לאחר מכן שוקמו כ-60% מהאחסון המשותף וכ-40% מהשרתים הייעודיים; השחזור נמשך.

מי מושפע

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

למה זה חשוב

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

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

שמרו גיבויים מאומתים, אופליין או multi-cloud, שאינם תלויים בספק הראשי, ובדקו אותם באופן קבוע לשחזור. ספקים: מבדלו ונטרו בכבדות את ה-management plane, אכפו בקרות multi-party לפעולות הרסניות, שמרו עותקי גיבוי immutable ותרגלו נהלי שיקום מלא. אחרי כל אירוע ב-management plane, הניחו חדירה מלאה ובנו מחדש במקום לנקות את הקיים.