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

מה קרה

גורמי איום החלו להפעיל את שרשרת האקספלויט Plex2Shell נגד סביבות Plex Media Server החשופות לאינטרנט, בערך יום אחרי שחוקר פרסם פרטים טכניים וקוד proof-of-concept עובד ב-16 באוקטובר.

השרשרת משלבת ארבע פגיעויות שמסומנות כ-CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 ו-CVE-2026-96656. יחד הן מאפשרות לתוקף ללא הרשאות להריץ קוד שרירותי על שרתים חשופים, כשה-payload רץ תחת הרשאות שירות Plex. חוקר שניטר מלכודת דבש עם build פגיע זיהה לראשונה שימוש בשטח ב-17 באוקטובר. התוקפים פרסו כורה מטבעות מבוסס XMRig, ובהמשך השאירו תוכנת proxy שזוהתה כ-myawesomeproxy.

מי מושפע

מפעילי Plex Media Server בגרסאות שלפני 1.43.3.10861, ובמיוחד כל סביבה שנשארה נגישה מהאינטרנט הציבורי. Plex אישרה את הבעיות אחרי דיווח ביולי, שיחררה תיקונים ודחקה לשדרוג החל מ-1 בספטמבר. שרתים ביתיים ומעבדות קטנות הם יעדים נפוצים כי רבים מהם רצים על חיבורי מגורים.

למה זה חשוב

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

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

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

עדכנו כל Plex Media Server לגרסה 1.43.3.10861 או חדשה יותר ללא דיחוי. הסירו חשיפה ישירה לאינטרנט; הציבו את השירות מאחורי VPN, reverse proxy מאומת או בקרת גישה Zero Trust.

נטרו תהליכים וחיבורים יוצאים לכורים או לקבצי proxy בלתי צפויים, ובדקו אינדיקטורים לחדירה שפורסמו ממלכודות דבש תוך התייחסות אליהם כחלקיים.

מה קרה

מאיץ השקעות Web3 מזויף שכינה את עצמו Apex Accelerator (במעקב כ-REF8801) מפיץ נוזקות לגניבת מידע ודלתות אחוריות דרך חבילות npm זדוניות. החבילות קודמו לסטארטאפים ולמייסדים בתחום הקריפטו עם הצעות לקרדיטי AI חינמיים ל-Claude ול-Gemini, כלי פיתוח וביקורות אבטחה.

Elastic Security Labs זיהתה חבילות כולל @apexacc/cli ו-@apexacc/audit שתוקפות גם Windows וגם macOS. חבילות קשורות קודמות פרסו את Atomic Stealer (AMOS). המבצע גם ארז מחדש סוכן קידוד לגיטימי כדי להפנות תעבורת מודלים דרך תשתית התוקפים, והפיק ממצאי audit מפוברקים. בהיסטוריית ה-commit הופיעו הערות ברוסית, אם כי הייחוס נותר לא מאושר. דומיינים וחשבונות GitHub קשורים הוסרו מאז.

מי מושפע

מייסדי קריפטו, מפתחי ארנקים וצוותי Web3 שהתקינו את חבילות ה-npm שקודמו או הריצו את כלי ה-due-diligence וה-audit לכאורה. נקודות הקצה ב-Windows וב-macOS מותקפות. הקמפיין פעיל בגלים לפחות מאפריל 2026 תחת המיתוג Apex Foundation.

למה זה חשוב

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

ממצאי audit מפוברקים יכולים גם ליצור ביטחון שווא בחוזים או בארנקים לא מאובטחים.

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

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

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

מה קרה

החוקר קוונטין קייזר (Quentin Kaiser) גילה פגיעות ביישום Wi-Fi Protected Setup (WPS) של Broadcom, שמאפשרת לתוקף בטווח רדיו להשיג הרצת קוד כ-root בנתבים מושפעים בלי לדעת את סיסמת הרשת ובלי להשלים שלב pairing כלשהו.

הבאג מטפל בצורה שגויה בהרכבה מחדש של הודעות WPS מקוטעות, וכך מאפשר השחתת זיכרון. קייזר הדגים קריאה של ה-Wi-Fi PSK משער Askey TCG3000 של Orange Belgium ופתיחת reverse shell באוויר על Proximus Sagemcom BBOX3V+. לא הוקצה CVE ולא הופצו תיקונים למכשירים שנבדקו. הוא מדווח שאין עדיין ראיות לניצול בשטח; האקספלויטים העובדים הם שלו. הקוד הפגיע קיים לפחות מאז 2010.

מי מושפע

נתבים ונקודות גישה שמשתמשים בשבבי Wi-Fi של Broadcom במשפחות eCos הישנות (BCM3380, BCM3383, BCM33834) ובמשפחות החדשות מבוססות Linux (BCM3390, BCM65xx, BCM68xx). קייזר מעריך שמדובר במיליוני מכשירים ברחבי העולם. בבלגיה הפגיעות אומתה בשערים של Proximus, Orange Belgium ו-VOO, שמייצגים מאות אלפי מנויים; רשימת ספקים רחבה יותר כוללת את Cisco, Huawei, ARRIS ואחרים ברמות ביטחון משתנות.

למה זה חשוב

לתוקף מספיקה קרבה רדיו, בלי פרטי הזדהות ובלי גישה פיזית, כדי להשתלט במלואה על השער. השליטה הזו מעניקה את סיסמת ה-Wi-Fi, תעבורת הרשת המקומית ונקודת אחיזה מתמשכת שיכולה לשמש נקודת זינוק לכל מכשיר מאחורי הנתב.

בשבבי eCos הישנים מדובר ב-forever-day שלא קיבל מעולם תיקון שמיש, ומשאיר בסיסי התקנה גדולים חשופים באופן קבוע.

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

השביתו WPS בכל נתב שבו האפשרות קיימת. החליפו שערים מבוססי Broadcom שהגיעו לסוף חיים או שאינם ניתנים לעדכון, במיוחד דגמי eCos ישנים. בחומרה חדשה יותר מבוססת Linux לחצו על הספקים למעבר ל-hostapd או לעדכוני קושחה.

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

מה קרה

ConnectWise השעתה כמה שירותי ענן אחרי שגילתה גישה לא מורשית לזהויות יישומים בסביבת Cloud Backup שלה. חקירת פעילות חשודה החלה ב-15 באוקטובר; עד 17 באוקטובר החברה אישרה את הגישה.

השירותים המושפעים (Cloud Backup, לשעבר SkyKick, לצד SaaS Security ו-Cloud Management) הוצאו מקו Offline. תוקף שמחזיק בפרטי ההזדהות של היישום יכול להזדהות בתור אפליקציית הגיבוי ולהשיג tokens שיורשים את ההרשאות הרחבות שלה, ולהגיע לתיבות דואר של לקוחות, OneDrive, SharePoint, נתוני Teams ומידע directory. MFA לא חל כי ההתחברות מבוססת יישום. Huntress זיהתה לפחות tenant אחד שבו התוקף הקצה לעצמו Global Administrator וניסה לשנות הרשאות של יישומים אחרים. ConnectWise מציינת שטרם מצאה ראיות לכך שנתוני גיבוי של שותפים נלקחו, אך החקירה נמשכת. לא פורסמה שיוך לגורם איום.

מי מושפע

ספקי שירותים מנוהלים (MSP) והלקוחות שלהם שמסתמכים על ConnectWise Cloud Backup, SaaS Security או Cloud Management להגנה ולניהול של Microsoft 365. כל tenant שהעניק ליישום ConnectWise את הרשאות הגיבוי הנדרשות עשוי להיות בטווח כל עוד החקירה פתוחה.

למה זה חשוב

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

עבור MSP רדיוס הפגיעה משתרע על ארגונים רבים במורד הזרם, והופך תקרית ספק בודדת לאירוע multi-tenant.

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

פעלו לפי הנחיות ConnectWise: אמתו את הסטטוס של חיבורי היישומים המפורטים והשאירו את האפליקציות המושפעות מושבתות עד שיופיעו הוראות שחזור רשמיות. שמרו מיד לוגים של התחברות ו-audit.

ב-Microsoft 365 בדקו enterprise applications ו-service principals לאיתור הענקות Global Admin או הרשאות גבוהות בלתי צפויות, בצעו רוטציה לכל secret חשוד, הפעילו continuous access evaluation היכן שאפשר, ונטרו פעילות בסגנון גיבוי או שינויי הרשאות חריגים.

מה קרה

פולש הגיע למערכת legacy של OpenCode בליל 16 באוקטובר, וייתכן שחשף מפתחות API של ספקי AI חיצוניים שמשתמשים שמרו ב-OpenCode Console. החברה הודיעה בדוא"ל ב-17 באוקטובר לקבוצת המשתמשים המושפעת, תחת הכותרת "Action Required: Potential provider key breach".

Console הוא שירות hosted אופציונלי שבו workspace שומר מפתח OpenAI, Anthropic או Google משלו, כדי שחברי הצוות יוכלו לקרוא למודלים בלי לראות את הסוד. רק 1.4% ממשתמשי Console (אלה שקישרו ספק חיצוני) נמצאים בטווח האירוע; מפתחות מקומיים שנשמרו ב-OpenCode CLI או במסד SQLite של אפליקציית שולחן העבודה לא היו מעורבים. OpenCode תיארה את האירוע כמתמשך וקשור למתקפת distillation רחבת היקף, בלי לספק פרטים טכניים נוספים ובלי לאשר שמפתח כלשהו אכן הועתק או נוצל. חלק מהמשתמשים דיווחו בפומבי על שימוש מחויב לא מורשה שנע בין מאות דולרים לכ-1,700 דולר.

מי מושפע

1.4% ממשתמשי OpenCode Console שהדביקו מפתחות API של OpenAI, Anthropic או Google לתוך workspace ב-Console. משתמשים שלא קיבלו את דוא"ל ההודעה מוגדרים כלא מושפעים. מפתחות שנשמרו רק במכונות מקומיות נשארים מחוץ לטווח הפריצה.

למה זה חשוב

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

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

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

בטלו מיד כל מפתח ספק שנשמר אי פעם ב-OpenCode Console, והנפיקו מפתחות חדשים מלוחות הבקרה של OpenAI, Anthropic או Google. עדכנו את כל האפליקציות והסקריפטים שהתייחסו למפתחות הישנים.

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

מה קרה

MITRE שחררה את גרסה 20 של מסגרת ATT&CK והרחיבה את הכיסוי של טקטיקות יריב עדכניות, עם טכניקות ותת-טכניקות חדשות שמתמקדות בניצול AI, בעקיפת MFA ובתקיפות נגד מערכות בקרה תעשייתיות.

בדומיין Enterprise מתועדים כעת שני סוגים של prompt injection (הוראות ישירות בממשק והוראות עקיפות שמוסתרות בתוכן שנקלט), לצד ניצול סוכני AI של הארגון עצמו לגניבת נתונים, הרעלת תוכן אינטרנט כדי להשפיע על המלצות AI, ושיבוש ניתוח נוזקות בסיוע LLM. ערכים נוספים מכסים גניבת סיסמאות ייעודיות לאפליקציה שמדלגות על בקשות אישור MFA, עקיפת CAPTCHA (פתרון אוטומטי והימנעות), וקבצי קונפיגורציה של IDE או של סוכן קידוד שנפרצו. ב-ICS, ערכי קמפיין חדשים מתעדים תקיפות על PLC חשופים לאינטרנט שמנעו ממפעילים גישה ליותר מ-30 מתקני מים ושפכים במינסוטה, ופריצה בסיוע AI שהגיעה למתקן מים עירוני במקסיקו. המגינים מקבלים גם 15 אסטרטגיות זיהוי חדשות (שש ב-Enterprise ותשע ב-ICS) הנתמכות ב-38 analytics.

מי מושפע

צוותי אבטחה, מהנדסי זיהוי, צוותי red team ומפעילי ICS/OT שמסתמכים על ATT&CK למידול איומים, לתכני זיהוי ולניתוח פערים. העדכונים רלוונטיים במיוחד לארגונים שפורסים סוכני AI פנימיים, כלי LLM או בקרי תעשייה החשופים לאינטרנט.

למה זה חשוב

ATT&CK היא השפה המשותפת שמגינים נעזרים בה כדי למפות התנהגות יריבים ולתעדף זיהויים. קידוד טכניקות ספציפיות ל-AI ולעקיפת MFA נותן לצוותי blue team מזהים ו-analytics קונקרטיים לציד טקטיקות שכבר מופיעות בשטח, בעוד שהקמפיינים נגד מתקני מים מדגישים את הסיכון הממשי לתשתיות קריטיות.

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

מה קרה

דידייה סטיבנס (Didier Stevens), handler ב-SANS ISC, פרסם כלל YARA תמציתי שמזהה פרויקטי VBA יתומים המוטמעים בתוך קבצי DWG של AutoCAD. הכלל מחפש את חתימת AutoCAD "AC10" ב-offset אפס, ערך 32-bit ספציפי ב-offset 0x24, את ה-magic bytes של קובץ OLE compound, ואת מחרוזת ה-ASCII "[Host Extender Info]".

retrohunt ב-VirusTotal עם הכלל החזיר רק שתי דגימות תואמות, מה שמעיד שהתבנית נדירה כרגע במאגרי הדגימות הציבוריים.

מי מושפע

ארגונים שמעבדים או מקבלים קבצי DWG של AutoCAD, במיוחד כאלה שמתירים macros או VBA בתוך שרטוטי הנדסה. צוותי אבטחה שכבר משתמשים ב-YARA לטריאז' קבצים או לציד נוזקות יכולים להוסיף את הכלל מיד.

למה זה חשוב

פרויקטי VBA יתומים יכולים לשאת macros זדוניים שמופעלים כששרטוט נפתח בסביבת AutoCAD עם תמיכה ב-VBA, ובכל זאת עשויים לחמוק מבדיקות סיומת או מילות מפתח פשוטות. חתימת YARA קלה מעניקה למגינים דרך זולה לחשוף את החריגות האלה בסריקת קליטה או בציד איומים.

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