חדשות הסייבר היומיות - 8 באוגוסט 2026

מה קרה

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

הפגיעות (CVSS 10.0, לא הוקצה CVE) מאפשרת לתוקף מרוחק ללא הזדהות להזריק SQL שרירותי למסד הנתונים של אפליקציית Metabase ולקבל גישת administrator. עם הגישה הזו תוקפים יכולים לשנות קונפיגורציה, לגנוב פרטי הזדהות שמורים למסדי נתונים מחוברים, לקרוא נתונים נגישים ולייצא אותם.

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

מי מושפע

סביבות Metabase self-hosted בגרסאות >= x.58.0 < x.58.23 (תוקן ב-x.58.24), >= x.59.0 < x.59.20 (תוקן ב-x.59.21), >= x.60.0 < x.60.16 (תוקן ב-x.60.17), >= x.61.0 < x.61.10 (תוקן ב-x.61.11), >= x.62.0 < x.62.8 (תוקן ב-x.62.9), וכן >= x.63.0 < x.63.3 (תוקן ב-x.63.5).

Metabase Cloud הושפע אך תוקן. בסיכון נמצא כל ארגון שמריץ Metabase self-hosted בגרסאות הפגיעות, כשה-endpoints נגישים לגישה ציבורית.

למה זה חשוב

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

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

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

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

כעקיפה זמנית, חסמו את ה-endpoint "/api/session/reset_password". לאחר העדכון, בטלו את כל הסשנים הפעילים באמצעות מחיקת שורות בטבלת core_session במסד הנתונים של האפליקציה, סקרו והסירו מפתחות API לא מזוהים וחשבונות admin בלתי צפויים, בצעו רוטציה לפרטי הזדהות של מסדי נתונים מחוברים, ובדקו לוגים של מחסני הנתונים יחד עם היסטוריית הפעילות והשאילתות ב-Metabase לאיתור סימנים לגישה לא מורשית.

עקבו אחרי תבנית ה-IoC: POST /api/session/reset_password שמחזיר 400 ואחריו GET /api/user/current שמחזיר 200.

מה קרה

אשכול של כמעט 800 חבילות זדוניות פורסם ב-registry של npm במסגרת קמפיין שמפיץ נוזקות RAT ו-infostealer לכל הפלטפורמות, המכוונות ל-Windows, macOS ו-Linux.

החבילות משתמשות בשמות typo-squatted שנוצרו ב-AI או הוקלדו באקראי. בניגוד למתקפות npm טיפוסיות שמתעללות ב-hooks מסוג preinstall/postinstall, החבילות האלה מנחות מפתחים דרך README לטעון אותן באמצעות require(). הפעולה מריצה downloader בשם WEL1DROPPER, שמזהה את מערכת ההפעלה והארכיטקטורה ואז מוריד payload תואם מדומיינים של Cloudflare Workers (או עובר לרשומות DNS TXT מדומיינים של wel1[.]ru עבור payloads ב-Base64 מחולקים למקטעים).

ה-payloads הסופיים רצים כתהליכים מנותקים: ב-Windows הם מבצעים patch ל-ETW/AMSI, בודקים sandboxes ומגדירים persistence דרך מפתח Registry Run ומשימה מתוזמנת; ב-macOS נעשה שימוש ב-LaunchAgent ובדיקות דומות; ב-Linux נפרס ELF ארוז ב-UPX שמוביל ל-framework ה-C2 מסוג Sliver. Sonatype עוקבת אחרי הקמפיין תחת השם Flooding Dropper.

מי מושפע

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

כל מערכת Windows, macOS או Linux שבה נטענת חבילה כזו חשופה ל-RAT/infostealer.

למה זה חשוב

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

RATs לכל הפלטפורמות יחד עם גניבת פרטי הזדהות ונתונים, בשילוב התחמקות (patch ל-AMSI/ETW, בדיקות sandbox) ו-persistence, מעניקים לתוקפים גישה מתמשכת לחדירה נוספת או להוצאת נתונים (exfiltration).

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

בדקו dependencies ו-lockfiles של npm שנוספו לאחרונה; הסירו כל חבילה לא מזוהה או חשודה, במיוחד כאלה עם שמות מוזרים דמויי AI או typo-squatted.

אל תעקבו בעיוורון אחרי הוראות README לביצוע require() לחבילות. השתמשו ב-allow-lists לחבילות, בכלי software composition analysis ובדיקות שלמות (למשל npm audit, אימות lockfile). נטרו חיבורים לדומיינים המפורטים של Cloudflare Workers ו-wel1[.]ru, ובדקו תיקיות זמניות לאיתור binaries בלתי צפויים. בצעו רוטציה לפרטי הזדהות אם קיים חשד לחדירה.

מה קרה

באג use-after-free בקוד הרשת SCTP של Linux, שקיים מאז 2008, ניתן להפוך להרשאות root מלאות על המארח; חוקרי Tencent הדגימו ניצול שלו לבריחה מקונטיינר והגעה למכונה שמתחתיו.

הפגיעות מזוהה כ-CVE-2026-64564 (ומכונה SCTPhantom על ידי מגליה), ונוגעת לקונפיגורציה דינמית של כתובות (ASCONF). הקרנל בודק בקשת מחיקה מול כתובת המקור של החבילה, אך פועל על path שנבחר לפי כתובת אחרת בתוך ההודעה - משחרר transport ואז משתמש שוב בפוינטר התלוי.

תיקונים הגיעו לקרנלים יציבים 7.1.6, 6.18.42, 6.12.101 ו-6.6.148 (שוחררו ב-3 באוגוסט). במועד הגילוי לא היה אקספלויט ציבורי זמין, והפגיעות אינה ב-CISA KEV. מדובר בפגיעות מקומית שדורשת ש-SCTP יהיה נגיש. Tencent דיווחה על root בבילדים שנבדקו של Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 ו-OpenCloudOS; בריחת הקונטיינר שלהם שמרה על seccomp ברירת המחדל ולא נזקקה ל-CAP_NET_ADMIN או ל-CAP_SYS_ADMIN בגרסאות מאוחרות יותר.

מי מושפע

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

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

למה זה חשוב

הסלמת הרשאות מקומית ל-root יחד עם בריחה אמינה מקונטיינר מערערת את הנחות הבידוד בסביבות ענן ורב-דיירות.

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

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

עדכנו לגרסאות קרנל מתוקנות (או ל-backports של ההפצה) שכוללות את תיקון ה-transport של SCTP ASCONF: קרנלים יציבים כולל 6.6.148, 6.12.101, 6.18.42 ו-7.1.6 כפי שדווח.

כשעדכון מיידי אינו אפשרי, הגבילו שימוש ב-SCTP, השביתו יכולות SCTP שאינן בשימוש דרך sysctls אם זה בטוח לעומס העבודה שלכם, החמירו פרופילי seccomp ומדיניות user-namespace לקונטיינרים, והגבילו הרשאות ליצירת סוקטים. בדקו את ה-tracker של ההפצה הספציפית שלכם במקום להסתמך רק על מחרוזות גרסת הקרנל.

מה קרה

מתקפות הנדסה חברתית בסגנון ClickFix מפיצות נוזקה מבוססת Go ל-macOS שגונבת נכסי קריפטו, סיסמאות השמורות בדפדפן, נתוני Apple iCloud Keychain ופרטי הזדהות שבמטמון.

הקורבנות מרומים להדביק פקודה באפליקציית Terminal. הפקודה מריצה פרופילר/טוען Bash שאוסף פרטי מערכת ומושך payload מסוג Mach-O התואם את ארכיטקטורת ה-CPU. הגונב מבקש פרטי הזדהות דרך דיאלוג מזויף של "שגיאת מערכת בלתי צפויה", ואז מבצע הוצאת נתונים (exfiltration).

בולטת במיוחד שגרת "DRAIN" שבודקת יתרות ארנקי קריפטו ויכולה לשאוב חלק מהכספים (כולל סכומים מחושבים של 1%) או את כולם לארנקים בשליטת התוקף - עבור Bitcoin, Litecoin, Dogecoin, Monero, Ethereum ו-XRP. ה-payloads ותשתית ה-C2 מקושרים ל-Aeza Group, ספק bulletproof רוסי תחת סנקציות. פעילות ClickFix קשורה הפיצה גם גונבי macOS אחרים וניצלה בינאריים של Windows.

מי מושפע

משתמשי macOS שנופלים בפיתיונות ClickFix ומדביקים את הפקודה הזדונית ב-Terminal, במיוחד מי שמחזיקים ארנקי קריפטו, סיסמאות שמורות בדפדפן או נתוני Keychain.

כל מערכת שבה הפרופילר מצליח למשוך ולהריץ את ה-payload התואם לארכיטקטורה נחשבת לחדירה.

למה זה חשוב

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

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

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

הדריכו משתמשים לעולם לא להדביק פקודות לא מבוקשות ב-Terminal, במיוחד מדפי אינטרנט, מיילים או צ'אט. אכפו חשבונות עם הרשאות מינימליות, ושקלו בקרות יישומים שמגבילות פעילות shell או רשת בלתי צפויה מתהליכים שהמשתמש מפעיל.

נטרו פעילות Terminal/Bash חשודה, בקשות בלתי צפויות לפרטי הזדהות, וחיבורים לתשתיות זדוניות מוכרות (כולל hosts הקשורים ל-Aeza). השתמשו בארנקים חומרתיים או באחסון cold מסוג air-gapped עבור אחזקות קריפטו משמעותיות, עדכנו דפדפנים ו-macOS, ובדקו את Keychain ומאגרי הסיסמאות בדפדפן אחרי כל אירוע חשוד. פרסו זיהוי endpoint שמסמן LaunchAgents, תהליכים מנותקים ותבניות גישה לארנקי קריפטו.

מה קרה

מערכת המחקר בסיוע AI של PortSwigger, HTTP Terminator, שבנה James Kettle, ייצרה ואימתה טכניקות חדשות לשיבוש סנכרון HTTP אחרי שסקרה כ-30,000 וקטורים מועמדים שנלקחו ממקטעי RFC.

המערכת זיהתה כ-700 יעדים פגיעים (כולל בנקים, תשתיות ממשלתיות, מוצרי אבטחה ונמל תעופה) בבדיקות מורשות. הממצאים החדשים כוללים טריגרים חדשניים ל-desync, תבנית Content-Length עם התאמה כפולה, טכניקת "dangling-byte" שמשפרת את אמינות ה-response queue poisoning (RQP) בכך שהיא מבטלת race, והמושג הרחב יותר Shared-Parser Confusion (מצב שבו כללי עיבוד תגובות מוחלים בטעות על בקשות).

שרשרת נפרדת בהנחיה אנושית חשפה zero-day של שיבוש סנכרון ב-Apache Traffic Server שכבר תוקן. טכניקת Content-Type אחת מסוג multipart/byteranges לבדה פגעה ביותר מ-200 אתרים בסט הבדיקות.

מי מושפע

יישומי ווב ותשתיות שעדיין משתמשים ב-HTTP/1.1 בין שרתי front-end ל-back-end, במיוחד כאלה עם הבדלים מורכבים ב-parsing או בטיפול בגוף הבקשה.

ארגונים שמריצים Apache Traffic Server (לפני התיקון לבעיה שנתגלתה) וכל אתר שפגיע לווקטורים החדשים של desync/RQP שהודגמו במחקר.

למה זה חשוב

מתקפות HTTP request smuggling ו-desync מאפשרות לתוקפים להרעיל את מצב החיבור, לגנוב תגובות של משתמשים אחרים (כולל cookies של סשן או מפתחות API), או לעקוף בקרות אבטחה.

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

מה קרה

שני חוקרי אבטחה רכשו דומיינים זולים, בהם noreply.net ו-noreply.us (וכן deleteduser.com), והגדירו אותם כמאזיני catch-all למייל. מאות חברות וארגונים שולחים אליהם בטעות מידע רגיש.

מאז דצמבר 2024 דומיין אחד בלבד קיבל יותר מ-400,000 הודעות (כ-700 ביום בממוצע), כולל קבצים מצורפים; הנפח המשולב בתקופה האחרונה עבר 11,000 הודעות בחודש. המיילים הגיעו מיותר מ-14,000 כתובות from ב-6,200 דומייני שורש. התוכן כלל דוחות פציעה מרשות עירונית, אישורי הזמנת פיצה, מיילי הקמת חשבון בפלטפורמות בית ספר, הזמנות שירות ופרטי הזדהות לפלטפורמות בדיקה.

ההודעות הן כמעט כולן מייל מערכת אוטומטי. החוקר קורי סולובביץ' (Cory Solovewicz), שהציג ב-Defcon, מודיע לארגונים המושפעים כדי שיתקנו את הקונפיגורציות השגויות, במקום לפרסם את שמותיהם.

מי מושפע

כל ארגון שמערכותיו מוגדרות לשלוח מייל לכתובות בדומייני placeholder או catch-all כמו @noreply.net, @noreply.us, או דומיינים דומים בסגנון deleted user - במיוחד התראות אוטומטיות, הודעות מחזור חיי חשבון, או מערכות שמשכתבות כתובות של עובדים שעוזבים.

מקבלי הנתונים שדלפו (במקרה הזה החוקרים) ונושאי המידע המקוריים שפרטי ה-PII או המידע העסקי שלהם נחשפים.

למה זה חשוב

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

בידיים הלא נכונות אותו זרם היה מאפשר הונאה, spear-phishing, credential stuffing או מודיעין תחרותי; הנפח והמגוון של השולחים מראים שהבעיה מערכתית ולא נקודתית.

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

בדקו את כל המערכות שמייצרות מייל אוטומטי (HR, כרטוס, CRM, DevOps, שירותי התראות, הקצאת חשבונות) לאיתור דומייני נמען שמוטמעים בקוד או שעברו שכתוב. אל תשתמשו בדומיינים ציבוריים אמיתיים כבור black-hole או ככיור no-reply, אלא אם אתם שולטים בהם ומנטרים אותם.

הטמיעו DLP או ניטור למייל יוצא מול דומיינים חיצוניים בלתי צפויים, אכפו SPF/DKIM/DMARC כראוי, וסקרו מעת לעת לוגים של bounce ומשלוח. כשעובדים עוזבים, בטלו כתובות באופן פנימי במקום לשכתב אותן לדומייני placeholder חיצוניים. התייחסו לכל תבנית no-reply או catch-all כנתיב פוטנציאלי להוצאת נתונים (exfiltration) ואמתו לאן ההודעות האלה באמת מגיעות.

מה קרה

מחקר שבדק את יכולת תיקון הפגיעויות של שני מודלים מסחריים פופולריים - ChatGPT 5.5 של OpenAI ו-Claude Opus 4.8 של Anthropic - מצא ש-AI גנרטיבי נוטה יותר לייצר תיקון חלקי או שניתן לניצול, או להכניס באגים חדשים לגמרי, מאשר לתקן פגם באופן מלא.

חוקרי 1Password העריכו את המודלים מול שישה CVE-ים בעלי השפעה גבוהה ומורכבות גבוהה (כולל בעיית Copy Fail בקרנל שיכולה להעניק root בסביבות ענן של Linux). שיעור ההצלחה הכולל - תיקון מלא של כל נתיבי האקספלויט הידועים בלי שינויי התנהגות שגויים - עמד על 47%.

המודלים תיקנו לעיתים קרובות רק תת-קבוצה של נתיבים פגיעים, הוסיפו קוד הגנה שביר שעבר בדיקות בלי לטפל בשורש הבעיה, או שינו בעדינות את התנהגות היישום. מחקר נפרד של Veracode על פני מודלים רבים מצא שיעור מעבר אבטחה ממוצע של כ-56% לקוד שנוצר ב-AI, כאשר 44% מהבדיקות הכניסו פגיעות OWASP Top 10 שניתנת לזיהוי. מודלים ייעודיים חדשים יותר לא נכללו בבדיקות הספציפיות האלה.

מי מושפע

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

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

למה זה חשוב

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

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