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

מה קרה

חוקרי Darktrace הדגימו במעבדה שמפתחות API גנובים של Claude יכולים להפוך את סוכן הקוד Claude Code של Anthropic לשתל בשליטה מרחוק.

הם הינוו את הסוכן דרך תכונת ה-memory stores של פלטפורמת Claude, באמצעות שלושה קבצים: check-in של heartbeat, קלט משימות ופלט תוצאות. המשימות היו יעדים באנגלית פשוטה. קובץ של 1 GB הוצא החוצה דרך Claude Files API. כל תעבורת ה-C2 עברה דרך api.anthropic.com והתמזגה עם קריאות inference רגילות.

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

מי מושפע

ארגונים ומפתחים שמשתמשים ב-Claude Code או ב-Claude Managed Agents, במקומות שבהם מפתחות API או פרטי הזדהות מאוחסנים בצורה לא מאובטחת על תחנות קצה.

כל סביבה שבה סוכני Claude רצים עם הרשאות כלים רחבות וגישה לרשת. היקף החשיפה מוגבל למי שיש לו מפתחות חשופים; מפתחות API רגילים מגיעים ל-memory stores, בעוד OAuth לא.

למה זה חשוב

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

מי שבונה ומפעיל סוכני AI חייב להתייחס למפתחות הפלטפורמה כמו לפרטי הזדהות של production, כי הם פותחים יכולות חזקות ומתמשכות בתוך הרשת.

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

העדיפו OAuth או פדרציית זהויות על פני מפתחות API ארוכי חיים. הגבילו את היקף המפתחות, הגדירו אותם קצרי תוקף, ואחסנו אותם בצורה מאובטחת מחוץ ל-shell history, ל-dotfiles או למשתני סביבה.

נטרו תהליכי Claude Code לאיתור דגלי שורת פקודה חריגים כמו --dangerously-skip-permissions, תבניות קריאות כלים לא טיפוסיות, ויחסים חריגים של נתונים שנכנסים ויוצאים מ-Anthropic API לעומת התנהגות הבסיס של הסוכן. בצעו קורלציה בין פעילות תהליכים לתעבורת רשת.

מה קרה

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

הקורבנות מזינים סיסמאות ומשלימים MFA אמיתי (SMS, authenticator, Tap-Yes, שחזור) בזמן שהמפעיל לוכד את הסשן בזמן אמת דרך מסגרת Nyasher. Material Security זיהתה את הפעילות ושיבשה מאות דומיינים תחת Operation CloudFire, תוך חסימה של עשרות אלפי הודעות.

מי מושפע

משתמשי Google Workspace ארגוניים שמקבלים הזמנות calendar או לוחצים על קישורים שנראים כאילו הגיעו מאנשי קשר מוכרים או משירותי Google.

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

למה זה חשוב

כל אות קונבנציונלי (בעלות על דומיין, תעודה, מוניטין, URL של Google) נשאר נקי מעצם התכנון (by design), ולכן סורקי קישורים ו-secure email gateways שותקים. ה-MFA מושלם באופן לגיטימי ובכל זאת הסשן נגנב, ומעניק גישה מלאה ל-Gmail, ל-Drive ולאפליקציות מחוברות ב-OAuth.

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

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

העדיפו אימות עמיד לפישינג כמו מפתחות אבטחה חומרתיים או passkeys על פני MFA מבוסס SMS או push. נטרו פעילות סשן חריגה, התחברויות ממכשירים חדשים והענקת OAuth חריגות אחרי אינטראקציות calendar.

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

מה קרה

פגיעות race condition קריטית במודול mod_http2 של Apache HTTP Server (CVE-2026-119618) מאפשרת לתוקף מרוחק ללא הרשאות להשיג הרצת קוד מרחוק בשרתים המושפעים.

היא נובעת מסנכרון לקוי ב-assign_headers() בטיפול ב-streams מקבילים של HTTP/2, שמאפשר ל-thread אחד להשחית זיכרון השייך ל-thread אחר. הבעיה משפיעה על Apache HTTP Server 2.4.55 עד 2.4.70 ועל mod_h2 עצמאי בגרסאות 2.0.8 עד 2.0.42. היא תוקנה ב-2.4.71. רק שרתים שבהם HTTP/2 מופעל (Protocols h2 או h2c) חשופים. Red Hat מדרגת אותה ב-CVSS 9.8 ומציינת שמחקר פומבי הדגים אקספלויט אמין מול קונפיגורציות ברירת מחדל; היא לא מופיעה ב-CISA KEV ולא אושר ניצול נרחב בשטח.

מי מושפע

כל סביבת Apache HTTP Server הנגישה לציבור ומריצה גרסאות 2.4.55-2.4.70 עם mod_http2 ו-HTTP/2 מופעל, כולל הפצות Linux רבות ותמונות ענן.

חבילות Red Hat Enterprise Linux 9 ו-10 מושפעות אך מדורגות Important בגלל allocators per-stream; RHEL 8 וגרסאות קודמות אינן מושפעות. גם משתמשי mod_h2 עצמאי וחלק מ-builds של Debian, Amazon Linux ו-Ubuntu צריכים לבדוק.

למה זה חשוב

RCE ללא הזדהות בשרת web מעניק שליטה מלאה בתהליך httpd, ומאפשר גניבת נתונים, פריסת נוזקה נוספת או תנועה רוחבית. HTTP/2 הופך יותר ויותר לברירת מחדל משיקולי ביצועים, ולכן רדיוס הפגיעה כולל אתרי production עם תעבורה גבוהה.

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

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

עדכנו את Apache HTTP Server ל-2.4.71 או החילו מיד חבילות ספק (למשל עדכוני mod_http2 של Red Hat). אם החלת התיקון מתעכבת, השביתו את HTTP/2 באמצעות הסרת h2/h2c מה-directive של Protocols ברמת השרת ובכל virtual host.

וודאו שהמודול לא נטען במקומות שבהם הוא מיותר, ונטרו תעבורת HTTP/2 חריגה או קריסות. עברו על advisories ספציפיים להפצה לשמות חבילות ול-backports.

מה קרה

חוקרי Microsoft הראו שעריכה של פחות מ-10 נוירונים בשימוש נדיר (dormant) במודל שפה open-weight מספיקה כדי לשתול דלת אחורית סמויה בשם Lazarus, בלי אימון מחדש מלא.

כשמחרוזת trigger שנבחרה מופיעה בקונטקסט, המודל פולט פקודה שבחר התוקף, וסוכן יבצע אותה עם ההרשאות שלו. העריכה מכוונת לשכבת ה-feed-forward הסופית; כל נוירון כופה token אחד של payload. בדיקות על Nemotron-Terminal-8B (7 נוירונים), Qwen3.6-27B ו-Gemma-4-31B-IT השיגו שיעורי הצלחה גבוהים של ה-trigger, בעוד שהמודלים עדיין עברו benchmarks רגילים. Microsoft לא זיהתה את הטכניקה בשטח ופרסמה הנחיות הגנה.

מי מושפע

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

כל מי שמקבל משקלות מודל ממקורות חיצוניים בלי בדיקות שלמות.

למה זה חשוב

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

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

מה קרה

CISA הוסיפה בסביבות 9 בנובמבר 2026 ארבע פגיעויות שמנוצלות בפועל לקטלוג Known Exploited Vulnerabilities שלה, ב-IBM Aspera Faspex, SignalWire FreeSWITCH, OpenSSH ו-GPUStack.

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

מי מושפע

מפעילי IBM Aspera Faspex בגרסאות 5.0.0 עד 5.0.19, SignalWire FreeSWITCH לפני 1.11.3, OpenSSH לפני 10.6p2 במערכות Linux מבוססות musl-libc ללא PAM, ו-GPUStack לפני 2.2.0.

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

למה זה חשוב

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

סוכנויות אזרחיות פדרליות חייבות לפעול תוך ימים; ארגונים פרטיים מתמודדים עם אותם איומים פעילים.

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

החילו תיקוני יצרן מיד: GPUStack 2.2.0 ומעלה, FreeSWITCH 1.11.3 ומעלה, OpenSSH 10.6p2 ומעלה, IBM Aspera Faspex 5.0.19 PL1. כשהתיקונים מתעכבים, הגבילו חשיפה ברשת, השביתו פיצ'רים פגיעים ובצעו טריאז' פורנזי לאיתור חדירה קודמת.

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

מה קרה

חברת האבטחה Claroc גילתה שמתוך 37,571 אפליקציות Grok פעילות ב-grok.me, 35,578 (כ-94.7 אחוז) היו נגישות באופן פתוח לכל מי שיש לו את הקישור ולא דרשו התחברות.

24 מהאפליקציות הפתוחות נבנו על ידי עובדים ב-X וב-SpaceXSI (לשעבר xAI) והכילו חומר סודי כמו מפות אזורי מכירה, תוכניות קליטה והצעות. בערך אחת מכל עשר אפליקציות פתוחות החזיקה נתונים עסקיים פנימיים או אישיים מלפחות 30 ארגונים נוספים, כולל חברות Fortune 500, בתי חולים וגופים הקשורים לביטחון. דוגמאות רגישות כללו רשימות עובדים, תדריכי מטופלים, לוחות משמרות וסיסמאות בטקסט גלוי. SpaceXSI הסירה את האפליקציות של עובדיה לאחר ההודעה.

מי מושפע

כל מי שפרסם אפליקציית Grok Build עם הגדרת ברירת המחדל "Anyone with the link", וגם הארגונים שנתונים פנימיים שלהם הגיעו לתוך האפליקציות האלה.

משתמשי בונה האפליקציות chat-to-app של Grok שסאבדומיינים שלהם הופיעו ב-Passive DNS אחרי הביקור הראשון.

למה זה חשוב

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

התקרית מראה איך יכולות קידוד ויצירת אפליקציות מבוססות AI יכולות ליצור בשקט shadow IT ומשטחי דליפת מידע בקנה מידה רחב.

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

בדקו מיד כל אפליקציית Grok Build שפרסמתם. שנו את הגישה מ-"Anyone with the link" ל-"Invited users" או "Only you", או בטלו פרסום של אפליקציות שמחזיקות נתונים רגישים.

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

מה קרה

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

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

מי מושפע

כל ארגון שפורס או מאפשר סוכני AI מבוססי דפדפן או שמפעילים UI, הפועלים בתוך סשני משתמש קיימים ב-CRM, קונסולות ענן, דשבורדים פנימיים או כלים דומים.

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

למה זה חשוב

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

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