
חדשות סייבר יומיות - 2 בספטמבר 2026
SonicWall SMA1000: פגיעויות zero-day משורשרות בתקיפות בשטח
קריטיתגרסאות מושפעות ותיקונים
- פגיע: 12.4.3-03453 (platform-hotfix) ומטה; 12.5.0-02835 (platform-hotfix) ומטה בדגמים 6210, 7210, 8200v
- תוקן: 12.4.3-03526 (platform-hotfix) ו-12.5.0-02952 (platform-hotfix)
- CVEs: CVE-2026-83548 (SSRF, CVSS 10.0), CVE-2026-83549 (הזרקת פקודות, CVSS 7.8)
מה קרה
SonicWall שחררה hotfixes לשתי פגיעויות במכשירי ה-VPN מסדרת SMA 1000, לאחר שחקרה מקרה של ניצול בפועל שעשוי לשרשר את הבאגים לביצוע קוד מרחוק.
CVE-2026-83548 היא פגיעות SSRF לפני אימות (CVSS 10.0) בממשק Appliance Work Place, שמאפשרת לתוקף מרוחק ללא הרשאות לקבל גישה לא מורשית לפונקציונליות רגישה. CVE-2026-83549 היא פגיעות הזרקת פקודות OS לאחר אימות (CVSS 7.8) ב-Appliance Management Console, שיכולה להוביל ל-RCE בתנאים מסוימים כשלתוקף כבר יש הרשאות admin.
הפגיעויות התגלו פנימית על ידי חוקרי SonicWall. הספקית לא שיתפה פרטים על פעילות הניצול או על הגורמים המעורבים. זה בא בהמשך לפגיעויות קודמות ב-SMA 1000 שנוצלו בפועל (CVE-2026-15409 ו-CVE-2026-15410) ושימשו לפריסת נוזקה.
מי מושפע
דגמי SMA 1000 מסוג 6210, 7210 ו-8200v שמריצים 12.4.3-03453 (platform-hotfix) ומטה, או 12.5.0-02835 (platform-hotfix) ומטה.
ארגונים שמשתמשים במכשירים האלה לגישה מרחוק ול-VPN חשופים עד לעדכון. ההיקף מוגבל ליחידות SMA 1000 שנפרסו ועדיין רצות על builds פגיעים.
למה זה חשוב
מכשירי VPN וגישה מאובטחת יושבים בקצה הרשת. שרשור מוצלח של SSRF לפני אימות להזרקת פקודות מאומתת יכול לתת לתוקפים שליטה מלאה במכשיר, ולאפשר תנועה רוחבית, גניבת פרטי הזדהות וגישה מתמשכת לרשתות ארגוניות.
ניצול קודם של SMA 1000 כבר הראה סיכון ממשי בשטח לפריסת כופרה ונוזקה. מכשירי קצה נשארים יעדים בעלי ערך גבוה, כי חדירה בודדת יכולה לחשוף סביבות פנימיות רחבות.
איך אפשר היה למנוע את זה
עדכנו מיד ל-12.4.3-03526 (platform-hotfix) או ל-12.5.0-02952 (platform-hotfix).
בדקו מערכות לאיתור IoCs. אם נמצאו IoCs, בצעו re-image או פרסו מחדש את המכשירים, החליפו את כל סיסמאות המשתמשים והמנהלים, ואפסו TOTP. הגבילו ממשקי ניהול ונטרו תעבורה חריגה.
מונחים מקצועיים רלוונטיים
- SSRF
- Server-Side Request Forgery היא פגיעות שמרמה שרת לבצע בקשות למיקומים פנימיים או לא מיועדים בשם התוקף.
- Pre-authentication attack chain
- רצף אקספלויטים שמתחיל בלי פרטי הזדהות תקפים ומגיע לביצוע קוד מלא על ידי שילוב של מספר פגיעויות לפי סדר.
JFrog Artifactory: פגיעות CVE-2026-82329 נוצלה ימים אחרי התיקון
קריטיתמה קרה
עקיפת אימות ב-JFrog Artifactory (CVE-2026-82329, CVSS 9.8) נוצלה בשטח ימים ספורים אחרי ש-JFrog שחררה תיקון ב-28 באוגוסט 2026, לפי מחקר של watchTowr שדווח בסביבות 1 בספטמבר.
בקונפיגורציית ברירת מחדל הפגיעות מאפשרת לתוקף ללא הרשאות עם גישה לרשת להשיג הרשאות מנהל. נצפו תוקפים שיוצרים admin tokens בסביבות פגיעות.
הפגיעות יושבת במאגר artifact מרכזי שמשמש ל-builds, ל-packages ול-container images.
מי מושפע
סביבות JFrog Artifactory self-hosted שמריצות גרסאות פגיעות מלפני התיקון של 28 באוגוסט, במיוחד כאלה עם קונפיגורציות ברירת מחדל וחשיפה לרשת.
ארגונים שמסתמכים על Artifactory כנקודת אמון יחידה ב-CI/CD ובשרשראות אספקת תוכנה ניצבים בפני סיכון מוגבר. פריסות בענן או כאלה שנעולות היטב עשויות להיות חשופות פחות.
למה זה חשוב
Artifactory מחזיקה קוד מוגמר והיא צוואר בקבוק בצינורות deployment אוטומטיים. גישת admin מאפשרת לתוקפים להרעיל builds, להזריק דלתות אחוריות, לדרוס artifacts או לבצע הוצאת נתונים (exfiltration) של binaries קנייניים, ובכך עלולים לחדור לכל מערכת downstream ולכל לקוח שמושך מהמאגר.
חדירה למאגר אחד יכולה להתרחב למאות קורבנות. התקפות שרשרת אספקה מהסוג הזה מגדילות את רדיוס הפגיעה הרבה מעבר לפריצה טיפוסית ביישום web.
איך אפשר היה למנוע את זה
החילו מיד את תיקון JFrog ל-CVE-2026-82329 על כל סביבות ה-self-hosted.
בטלו והנפיקו מחדש כל admin token בסביבות שהריצו builds פגיעים. השביתו גישה אנונימית, אכפו אימות admin חזק, אסרו דריסה של גרסאות artifact שפורסמו, השאירו repositories מחוץ לאינטרנט הציבורי מאחורי בקרות רשת, דרשו חתימה קריפטוגרפית ו-provenance attestation, ועגנו manifests של production ל-digests מאומתים עם בדיקות admission controller.
מונחים מקצועיים רלוונטיים
- Artifact repository
- מאגר מרכזי לחבילות תוכנה מוכנות, ספריות ותמונות קונטיינר, שמערכות build ו-deployment שולפות ממנו באופן אוטומטי.
- Software provenance
- אימות קריפטוגרפי של היכן, כיצד ועל ידי מי נבנה binary, כדי שמערכות בהמשך השרשרת יוכלו לאמת שלמות לפני הרצה.
Claude מעביר אקספלויט RCE pre-auth בין דגמי PLC של WAGO
בינוניתאיך זה עובד
מה קרה
צוות Forescout Research - Vedere Labs השתמש ב-Claude של Anthropic כדי להעביר אקספלויט RCE pre-authentication עובד מ-PLC מדגם WAGO 750-852 ל-WAGO 750-831 עם קושחה V01.04.16, והריץ shellcode ARM שסופק על ידי התוקף על חומרה חיה.
הפגיעות הבסיסית היא CVE-2021-31886, stack-based buffer overflow בטיפול בפקודת USER של שרת ה-FTP של Nucleus (CVSS 9.8), שניתן להגיע אליה לפני אימות דרך פורט TCP 21. החוקרים סיפקו את האקספלויט המקורי, את קובץ ה-firmware ואת היעד הפיזי; Claude (שעבר מ-Sonnet 4.6 ל-Opus 4.6) התאים את הרצף בהנחיה אינטראקטיבית של החוקרים, כולל החלפת USER/QUIT ב-USER/CWD והשמטת CRLF כדי לשמור על ה-buffer שלם.
עלות פיתוח ה-RCE הסופי עמדה על כ-535 דולר בשימוש API לאורך כ-8.5 שעות. ניסיון מאוחר יותר לבנות implant של C2 השבית את ה-PLC בכתיבה לזיכרון שממופה ל-flash. CERT@VDE מציינת שאין עדכונים זמינים לבקרים המושפעים.
מי מושפע
בקרי PLC של WAGO שמשתמשים ביישום הפגיע של שרת ה-FTP של Nucleus, ובפרט דגמים כמו 750-852 ו-750-831 (ומכשירי Siemens APOGEE ומכשירים נוספים הרשומים תחת ה-CVE) שבהם FTP בפורט 21 נשאר מופעל.
סביבות תעשייתיות ו-OT שלא השביתו או חסמו FTP חשופות. לא מתואר ניצול נרחב בפועל של עבודת ההעברה הספציפית הזו.
למה זה חשוב
העבודה מראה שמודלי שפה גדולים יכולים להאיץ העברת אקספלויטים בין וריאנטים של חומרה כשהם מונחים על ידי חוקרים מיומנים, ולהוריד את מחסום הזמן והמומחיות בהתאמת פגיעויות ICS קריטיות ידועות.
RCE מוצלח על PLC יכול לאפשר תנועה רוחבית עמוקה ברשתות OT. גם בלי ניצול המוני כיום, ההדגמה מדגישה סיכון שיורי משירותי FTP ישנים שאי אפשר לעדכן, ואת הפוטנציאל לשימוש כפול של עוזרי קידוד מבוססי AI במחקר התקפי.
מונחים מקצועיים רלוונטיים
- PLC
- בקר לוגיקה ניתן לתכנות הוא מחשב תעשייתי שמבצע אוטומציה של מכונות ותהליכים בקווי ייצור ובתשתיות קריטיות.
- Stack-based buffer overflow
- באג השחתת זיכרון שבו נתונים עודפים שנכתבים מעבר ל-buffer קבוע ב-call stack דורסים כתובות חזרה או נתוני בקרה, ולעיתים קרובות מאפשרים הרצת קוד.
חטיפת BGP מספקת עדכון Virtualizor זדוני
גבוההמה קרה
בין 28 באוגוסט ל-30 באוגוסט 2026, גורם איום ביצע חטיפת BGP על בלוק כתובות IP של Softaculous שמשמש לעדכוני תוכנה ולשירותים נוספים, והסיט תעבורה לתשתית בשליטת התוקף.
AS62390 (NexonHost) הכריזה על prefix ספציפי יותר שכיסה חלק ממרחב הכתובות של Hetzner, תוך שמירה על AS24940 בנתיב, כך שהנתיב הזדוני קיבל עדיפות. הגורם השיג תעודת TLS תקפה של Let's Encrypt לדומיינים של Softaculous דרך domain-validation אוטומטי שעקב אחרי הנתיב החטוף.
חבילת עדכון Virtualizor זדונית נמסרה למספר קטן של סביבות שבדקו עדכונים במהלך החלון. Softaculous שחזרה ניתוב לגיטימי ואישרה שההשפעה הוגבלה לקומץ שרתים ולא לבסיס המשתמשים הכללי. החקירה לגבי מוצרים נוספים נמשכת.
מי מושפע
מפעילי Virtualizor (פאנל ניהול VPS של Softaculous) שהמערכות שלהם בדקו עדכונים בזמן שהתעבורה הוסטה, וכן כל שירות Softaculous אחר על הכתובות החטופות (עדכונים, אזור לקוחות, חיוב).
Softaculous מציינת שרק מספר קטן של שרתי Virtualizor קיבלו את החבילה הזדונית. בסיס המשתמשים הרחב לא הושפע באופן כללי, אך המפעילים נקראים לבדוק אם בוצעה חדירה.
למה זה חשוב
חטיפת BGP בשילוב עם תעודת TLS תקפה שוברת את אמון ה-HTTPS הרגיל ויכולה לספק בשקט עדכונים שמכילים דלת אחורית. Virtualizor מנהל שרתים וירטואליים, כך שעדכון זדוני יכול להעניק שליטה מלאה ב-host, גניבת פרטי הזדהות או התפשטות נוספת בשרשרת האספקה.
גם התקפות ניתוב קצרות נגד תשתית עדכונים יוצרות נתיבי חדירה בעלי השפעה גבוהה שיומנים בשרת המקור הלגיטימי לעולם לא רואים.
איך אפשר היה למנוע את זה
בדקו התקנות Virtualizor לאיתור חבילות לא צפויות, persistence או התנהגות חריגה, והתקינו מחדש ממקורות תקינים וידועים אם יש חשד לחדירה.
נטרו את BGP לאיתור הכרזות more-specific לא צפויות של ה-prefixes שלכם, השתמשו ב-RPKI/ROA כשאפשר, עגנו את נקודות הקצה של העדכונים או אמתו חתימות ו-hashes של חבילות מחוץ לערוץ, והגבילו בדיקות עדכון אוטומטיות לחלונות זמן מהימנים או לערוצים מאומתים.
מונחים מקצועיים רלוונטיים
- BGP hijack
- התקפה שמכריזה באופן כוזב על נתיבי כתובות IP, כך שתעבורת אינטרנט המיועדת לקורבן מופנית דרך רשתות שבשליטת התוקף.
- More-specific prefix
- הכרזת נתיב IP צרה יותר, שעל פי כללי הבחירה הרגילים של BGP מקבלת עדיפות על פני נתיב מכסה רחב יותר, ויכולה לגנוב תעבורה עבור תת-הקבוצה הזו של כתובות.
13 חבילות זדוניות ב-Packagist גונבות seeds של ארנקי קריפטו ממכשירי iPhone
גבוההNamespaces של חבילות זדוניות
מה קרה
חוקרים ב-Socket זיהו 13 חבילות ערכות נושא זדוניות של Composer ב-Packagist, שמזריקות JavaScript לאתרי סטרימינג וייטנאמיים של סרטים וקומיקס. הקוד המוזרק מריץ הונאות פרסום במובייל והפניות להימורים, ובמכשירי iPhone מפעיל שרשרת אקספלויט מ-WebKit לקרנל שמתקינה רוגלה לגניבת seeds של ארנקי קריפטו ונתונים נוספים.
החבילות משתרעות על namespaces כולל vsmov, vsphim, haiau009, chilltvcms ו-ophimcms. שרשרת ה-iOS מנצלת את CVE-2025-31277 ו-CVE-2025-43529 (שתיהן פגיעויות WebKit שמנוצלות בפועל), ואז בורחת מה-sandbox דרך תהליך GPU ונתיב בקרנל דרך AppleM2ScalerCSCDriver. Apple תיקנה את בעיית הקרנל ב-iOS/macOS 26.1 (CVEs אפשריות קשורות כוללות את CVE-2025-43398, CVE-2025-43510 ו-CVE-2025-43520).
הקמפיין ממשיך פעילות מוקדמת יותר מ-2026. שרשרת שנפרסה מחדש בסביבות 12 באוגוסט 2026 מיקדה בעיקר את iOS 18.4 עד 18.6.x. במקרה של הצלחה נאספים keychain, סיסמאות Wi-Fi, SMS, אנשי קשר, תמונות, cookies, היסטוריית שיחות ומיקום; הנתונים מוצפנים ב-AES ומועברים בהוצאת נתונים (exfiltration) לדומייני C2 מתחלפים.
מי מושפע
מפעילי אתרים שהתקינו את ערכות הנושא הזדוניות מ-Packagist/Composer (בעיקר אתרי סטרימינג וייטנאמיים) והמבקרים שלהם, ובמיוחד משתמשי iPhone שלא עודכנו בגרסאות iOS הפגיעות לבאגים ב-WebKit ובקרנל (בעיקר 18.4-18.6.x וגרסאות קודמות שלא תוקנו).
משתמשי ארנקי קריפטו במכשירים האלה חשופים לסיכון גניבה ישיר. בעלי האתרים שמשכו את ערכות הנושא מ-Packagist הם וקטור ההפצה הראשוני.
למה זה חשוב
חדירה לשרשרת האספקה של ערכות נושא CMS פופולריות הופכת אתרים לגיטימיים למארחי אקספלויטים מסוג drive-by. שרשור באגי דפדפן עד לגישה לקרנל מעניק שליטה מלאה במכשיר וגניבה המונית של פרטי הזדהות, הודעות ו-seeds של ארנקים, בלי אינטראקציה מצד המשתמש מעבר לביקור באתר.
CVEs ב-WebKit שמנוצלות בפועל, יחד עם בריחה לקרנל, יוצרים נתיב מסירה בעל השפעה גבוהה לרוגלות מובייל, במיוחד מול משתמשים שמתעכבים בעדכון iOS.
איך אפשר היה למנוע את זה
בעלי אתרים: הסירו את החבילות הזדוניות שפורטו, בדקו תלויות Composer וסרקו לאיתור JavaScript שהוזרק. בנו מחדש ממקורות נקיים.
משתמשי iPhone: עדכנו מיד ל-iOS העדכני ביותר (תיקונים לפגיעויות ה-WebKit ולבריחה לקרנל נמצאים בקווים 18.6+, 18.7.3 ו-26.x לפי העניין). הימנעו מאתרי סטרימינג לא מהימנים, השתמשו בקודי גישה חזקים למכשיר, ונטרו ארנקי קריפטו לפעילות לא מורשית. על Packagist ורישומים דומים להמשיך בסריקת נוזקות בחבילות.
מונחים מקצועיים רלוונטיים
- Packagist
- המאגר הציבורי הראשי לחבילות PHP Composer, המקביל ל-npm עבור JavaScript, שממנו מפתחים מתקינים ספריות וערכות נושא.
- WebKit-to-kernel chain
- אקספלויט רב-שלבי שמתחיל במנוע הדפדפן, בורח מ-sandbox התוכן (לעיתים קרובות דרך GPU או תהליכים אחרים), ומגיע ל-read/write בקרנל לצורך חדירה מלאה למכשיר.
גניבת מפתח API של METR שורפת 600 אלף דולר בקרדיטים של מודלי AI
בינוניתמה קרה
METR, עמותה ללא מטרות רווח שמעריכה מודלי frontier AI במשימות agentic ארוכות טווח, חשפה שני אירועי אבטחה. במרץ 2026 גנבו תוקפים מפתח API ל-inference על מודלים ציבוריים וצרכו קרדיטים בשווי של כ-600,000 דולר (השימוש היה חינמי עבור METR דרך הספק, ולכן לא נרשם חיוב בפועל).
חוקר הריץ agents על סביבת EC2 אישית שפנתה לציבור מאחורי Google auth. פגיעות fail-open באפליקציית vibe-coded השביתה בשקט את האימות וחשפה את לוח הבקרה של ה-orchestration. התוקפים כנראה איתרו אותה דרך certificate transparency ומילות מפתח בעלות אות חזק סביב LLM ו-agents, הנחו agent לחשוף את המפתח, הוסיפו מפתח SSH ל-persistence, ושרפו tokens במשך שלושה שבועות. נפח הערכה רגיל גבוה והיעדר מגבלות הוצאה עיכבו את הזיהוי.
במאי 2026 קמפיין נפרד בעל מניע כלכלי בדק באופן שיטתי תשתית ציבורית, כולל ניסיון כושל דרך endpoint שנחשף בטעות. ההערכה היא שלא בוצעה גישה לנתוני הערכה רגישים. האירועים שותפו עם חברות AI שותפות לפני הגילוי הפומבי.
מי מושפע
חשבון ה-inference של METR על מודלים ציבוריים והתשתית החשופה של החוקר. חברות AI שותפות קיבלו את הממצאים. אין ראיות לחדירה רחבה יותר לנתוני הערכה פנימיים או לייחוס לקבוצת תקיפה מזוהה.
ארגונים שמריצים לוחות בקרה דומים של agents או מפתחות API על סביבות ענן אישיות או ניסיוניות עם הגנה קלה חולקים את אותה תבנית חשיפה.
למה זה חשוב
מפתחות API של ספקי מודלים גדולים הם יעדים בעלי ערך גבוה. מפתח חשוף אחד יכול לייצר חשבונות compute עצומים או לאפשר ניצול מודלים לתקיפות נוספות. באגי אימות fail-open בכלים שנבנו במהירות בגישת vibe-coded הופכים ניסויים זמניים למשטח תקיפה ציבורי.
האירוע מדגיש שסביבות מחקר והערכה זקוקות לאותה היגיינת פרטי הזדהות, בקרות הוצאה וניטור כמו מערכות production, במיוחד כשמעורבים agents ו-endpoints ציבוריים.
איך אפשר היה למנוע את זה
אל תניחו פרטי הזדהות ארגוניים או נתונים רגישים על תשתית שאינה ארגונית. אכפו אימות שנכשל לסגירה (fail-closed), הוסיפו מגבלות הוצאה והתראות על מפתחות API, נטרו שימוש חריג ב-tokens, נעלו סביבות ניסיוניות, ובדקו certificate transparency ודומיינים שנרשמו לאחרונה לחשיפה מקרית. בצעו רוטציה למפתחות אחרי כל חשד לאירוע.
מונחים מקצועיים רלוונטיים
- API key
- token סודי שמאמת בקשות לשירות ענן כדי שהספק יוכל לחייב ולאשר שימוש במודלים או ב-APIs אחרים.
- Fail-open
- פגם בתכנון שבו בקרת אבטחה (כמו אימות) מאפשרת גישה כברירת מחדל כשהיא נתקלת בשגיאה או בקונפיגורציה שגויה, במקום לדחות אותה.
פגיעויות ownCloud לא מתוקנות: פריצה לסוכנות הגרעין של הפיליפינים
גבוההמה זה אומר
כלי שיתוף פעולה מדור קודם שנשארו ללא תיקון וחשופים לאינטרנט הציבורי נשארים וקטור גישה ראשונית אמין, גם מול יעדים מדעיים בעלי ערך גבוה. תעדופו עדכון של מערכות שיתוף קבצים ו-CMS החשופות לאינטרנט באותה דחיפות כמו התקני VPN קצה.
מה קרה
גורמי איום פרצו לסוכנות המחקר הגרעיני של הפיליפינים בניצול פגיעויות ידועות ולא מתוקנות בתוכנת שיתוף הקבצים ownCloud כדי להשיג גישה ראשונית.
הנתונים שנגנבו כללו לפי הדיווחים מסדי נתונים הקשורים לכורים, רשומות כוח אדם ומאגרי פרטי הזדהות. המתקפה הסתמכה על פגיעויות commodity ולא על zero-days חדשים, ומדגישה חשיפה ממושכת ולא מתוקנת במערכות שיתוף פעולה שפונות לאינטרנט.
מי מושפע
סוכנות הגרעין הפיליפינית (ובפרט פריסת ה-ownCloud שלה) ספגה את הפריצה המאושרת. כל ארגון אחר שעדיין מריץ סביבות ownCloud לא מתוקנות ונגישות מהאינטרנט עם אותן פגיעויות commodity חולק סיכון דומה.
ההשפעה התמקדה בנתונים מדעיים, כוח אדם ואימות רגישים שהוחזקו בסוכנות.
למה זה חשוב
ארגוני גרעין ומחקר קריטי מחזיקים מידע טכני וכוח אדם רגיש ביותר. ניצול באגים ישנים או ידועים ב-ownCloud מראה שכשלי היגיינת תיקונים בסיסיים יכולים להוביל לגניבת נתונים אסטרטגית.
מאגרי פרטי הזדהות במיוחד מאפשרים תנועה רוחבית נוספת או שימוש חוזר נגד יעדים אחרים. ניצול פגיעויות commodity נשאר יעיל מול תשתית שלא מתוחזקת כראוי.
איך אפשר היה למנוע את זה
עדכנו את ownCloud לגרסה הנתמכת העדכנית ביותר מיד, והסירו או בודדו כל סביבה בסוף חיים מהאינטרנט.
אכפו אימות רב-שלבי (MFA), סגמנטציית רשת לפלטפורמות שיתוף קבצים, סריקות פגיעויות סדירות, גישה בהרשאות מינימליות לנתוני כורים וכוח אדם, וניטור תבניות הורדה או הזדהות חריגות. בצעו רוטציה לפרטי הזדהות אם יש חשד לחדירה ובדקו persistence.
מונחים מקצועיים רלוונטיים
- ownCloud
- פלטפורמת סנכרון ושיתוף קבצים בקוד פתוח שארגונים מארחים בעצמם כחלופה לאחסון ענן מסחרי.
- Commodity vulnerability
- פגיעות נפוצה וידועה, מתועדת בפומבי, שקיים עבורה קוד אקספלויט או חתימות סריקה, ושתוקפים ממחזרים אותה בקנה מידה רחב במקום לפתח אקספלויטים מותאמים.
פורסם על ידי סייבר בקצרה