חדשות סייבר יומיות - 26 בספטמבר 2026

מה קרה

CISA הוסיפה ב-25 בספטמבר 2026 שתי פגיעויות שמנוצלות בפועל לקטלוג Known Exploited Vulnerabilities (KEV) שלה: CVE-2026-65660 ב-Microsoft SharePoint ו-CVE-2026-67279 ב-MikroTik RouterOS.

הפגיעות CVE-2026-65660 היא בעיית הזרקת קוד (CVSS 8.8) ש-Microsoft סימנה תחילה כ-spoofing, אך בהמשך אישרה שהיא מאפשרת הרצת קוד מרחוק לתוקף מורשה דרך הרשת. Microsoft מסרה שיש בידיה ראיות אמינות להתקפות שנצפו נכון ל-25 בספטמבר.

הפגיעות CVE-2026-67279 (CVSS בסביבות 6.5-6.9) מאפשרת ללקוח ללא הזדהות לפתוח ערוץ סשן ולשלוח בקשות exec. היא משורשרת עם CVE-2026-86060 הקודמת (CVSS 9.8, כבר ב-KEV) באקספלויט MikroTrick, לצורך השתלטות מנהלית מלאה ללא הזדהות על מכשירי RouterOS פגיעים.

מי מושפע

ארגונים שמריצים Microsoft SharePoint Server on-premise (גרסאות נתמכות מרובות) ומכשירי MikroTik RouterOS 7.x (וחלק מ-6.x) החשופים לאינטרנט.

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

למה זה חשוב

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

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

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

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

עבור MikroTik, שדרגו את RouterOS לגרסאות מתוקנות כמו 7.23.4, 7.24.2 או מקבילות מאוחרות יותר, והגבילו ממשקי SSH וניהול לרשתות מהימנות בלבד. נטרו פעילות סשן או exec חריגה, ובצעו רוטציה לכל פרטי הזדהות שנחשפו.

מה קרה

Canadian Centre for Cyber Security הזהירה כי CVE-2026-48842, הזרקת SQL לפני הזדהות ב-Roundcube Webmail שכבר תוקנה, מנוצלת בפועל בשטח.

הפגיעות (CVSS 8.1) יושבת בתוסף virtuser_query ונובעת מעקיפת backslash escape ב-preg_replace(), שמאפשרת לתוקפים ללא הזדהות להזריק SQL שרירותי. היא משפיעה על גרסאות 1.6.x לפני 1.6.16 ועל 1.7.x לפני 1.7.1. התיקונים שוחררו במאי 2026.

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

מי מושפע

מפעילי Roundcube Webmail 1.6.x ו-1.7.x שהתוסף virtuser_query מופעל אצלם ושלא שדרגו ל-1.6.16 או ל-1.7.1.

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

למה זה חשוב

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

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

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

שדרגו מיד ל-Roundcube 1.6.16 או 1.7.1 ומעלה. השביתו את התוסף virtuser_query אם אינו נדרש.

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

מה קרה

שני GitHub Actions של הארגון actions-cool (issues-helper ו-maintain-one-comment) הופעלו מחדש ב-16 בספטמבר 2026, ועדיין הכילו קוד זדוני מקמפיין Mini Shai-Hulud ממאי 2026.

הפריצה המקורית גרמה ל-Actions לאסוף פרטי הזדהות מצינורות CI/CD. אחרי ש-GitHub השביתה את הריפוזיטוריז במאי, הם שבו להיות נגישים בלי שניקו את התגיות הזדוניות. Workflows שמפנים ל-Actions דרך תגיות גרסה משתנות משכו והריצו את ה-payload אוטומטית בהרצה הבאה לפי לוח זמנים או לפי אירוע.

GitHub השביתה את הריפוזיטוריז פעם שנייה בהמשך. אלפי ריפוזיטוריז תלויים היו חשופים פוטנציאלית.

מי מושפע

כל פרויקט ש-workflows ב-GitHub שלו קוראים ל-actions-cool/issues-helper או ל-actions-cool/maintain-one-comment לפי תגית ולא לפי commit SHA קבוע.

מפתחים וארגונים שמשתמשים ב-Actions הפופולריים האלה לאוטומציה של issues ותגובות בצינורות CI/CD, במיוחד כאלה שבהם ל-runner יש גישה לסודות או לפרטי הזדהות בענן.

למה זה חשוב

הפעלה מחדש של נוזקה מוכרת בשרשרת האספקה לא דורשת פעולה חדשה מצד התוקף ולא שינוי בקבצי ה-workflow של הקורבן. גניבת פרטי הזדהות מ-CI/CD עלולה להוביל לפריצה נוספת בריפוזיטורי, השתלטות על חשבון ענן או הרעלת חבילות בהמשך השרשרת.

תגיות משתנות יוצרות חלון סיכון מתמשך גם אחרי ניקוי ראשוני.

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

עגנו את ה-Actions המושפעים ל-commit SHA ספציפיים שקדמו לפריצה ממאי 2026. בדקו את כל ה-workflows לאיתור הפניות לחבילות actions-cool.

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

מה קרה

Mandiant ו-Google Threat Intelligence Group זיהו קמפיין ניצול המוני מחודש של UNC6240 (ShinyHunters) נגד CVE-2026-35273 ב-Oracle PeopleSoft.

הפגיעות הקריטית ללא הזדהות (CVSS 9.8) ברכיב Environment Management Hub של PeopleTools 8.61 ו-8.62 נוצלה לראשונה כ-zero-day במאי-יוני 2026, בעיקר נגד יעדים בחינוך. בגל החדש עוקפים הגורמים כללי WAF שחוסמים את הנתיב המילולי /PSEMHUB/ באמצעות קידוד URL של תו בודד (/%50SEMHUB/), שרבים מה-WAFs מבצעים עליו התאמה לפני פענוח בעוד שהאפליקציה מפענחת ומנתבת כרגיל.

הם פרסו web shells בעשרות מערכות בהשכלה גבוהה, טכנולוגיה, בריאות, ממשל ומגזרים נוספים.

מי מושפע

ארגונים שמריצים Oracle PeopleSoft Enterprise PeopleTools 8.61 או 8.62 ללא תיקון, במיוחד כאלה שהסתמכו על חסימת נתיב ב-WAF במקום להחיל את התיקון מ-Oracle Security Alert.

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

למה זה חשוב

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

ניצול מוצלח מוביל ל-web shells, גניבת פרטי הזדהות, סוכני MeshCentral וגישה פנימית נוספת, ומעמיד בסיכון נתוני HR, כספים ותפעול.

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

החילו מיד את התיקון מ-Oracle Security Alert עבור CVE-2026-35273. השביתו או הסירו את שירות Environment Management Hub (PSEMHUB) היכן שאפשר לפי הנחיות Oracle.

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

מה קרה

קמרון ג'ון וגניוס (Cameron John Wagenius), חייל לשעבר בצבא ארה"ב, נידון ל-70 חודשי מאסר וחויב לשלם כמעט 295,000 דולר כפיצוי על מסע פשיעת סייבר שנמשך שנים וכלל תקיפות נגד AT&T וארגונים נוספים בזמן שירותו הסדיר.

וגניוס ושותפיו לקשר, בהם קונור מוקה (Connor Moucka), השתמשו בפרטי הזדהות גנובים כדי לגשת לסביבות לקוחות של Snowflake ולפלטפורמות ענן נוספות, וגנבו נפחי נתונים גדולים לצורך סחיטה. בין הקורבנות: AT&T (רשומות שיחות והודעות של כמעט כל הלקוחות), Ticketmaster, Advance Auto Parts ו-Santander. הקבוצה קיבלה יחד יותר מ-2.5 מיליון דולר בתשלומי סחיטה וגנבה מיליארדי רשומות.

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

מי מושפע

לקוחות הארגונים שנפרצו, ובמיוחד מנויי הסלולר של AT&T שמטא-נתונים של שיחות והודעות שלהם נגנבו, לצד לקוחות Snowflake נוספים וחברות שהיו יעד לסחיטה.

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

למה זה חשוב

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

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

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

אכפו אימות רב-שלבי (MFA) על כל פלטפורמות הנתונים בענן ועל חשבונות ניהול. נטרו באופן רציף credential stuffing וגישה חריגה לנתונים בהיקף גדול או הוצאת נתונים (exfiltration).

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

מה קרה

בורסת הקריפטו Bitget ספגה גניבה של יותר מ-351 מיליון דולר (דיווחים מאוחרים יותר ציינו סכומים שמתקרבים ל-387 מיליון דולר) מארנקי ה-hot וה-warm שלה ב-24 בספטמבר 2026, במה שמתואר כשוד הקריפטו הגדול ביותר הידוע השנה עד כה.

תוקפים פרצו למערכת back-end, זייפו נתוני עסקאות והפעילו תהליכי הרשאה לגיטימיים כדי להעביר כספים בלי לגנוב מפתחות פרטיים. Bitget השעתה משיכות והצהירה שקרן ההגנה על משתמשים שלה (מעל 464 מיליון דולר) מכסה את ההפסד.

המנכ"לית גרייסי צ'ן (Gracy Chen) אמרה שהטקטיקות ומדדי התשתית עקביים מאוד עם קבוצות האקרים מוכרות מצפון קוריאה. חברות בלוקצ'יין קישרו ארנקים קשורים לפעילות של Lazarus Group; צפון קוריאה מוערכת כעומדת מאחורי רוב שווי גניבות הקריפטו ב-2026.

מי מושפע

משתמשי Bitget והבורסה עצמה. אחזקות בארנקי hot ששימשו למסחר פעיל רוקנו על פני מספר chains, בהן Ethereum, XRP ואחרות.

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

למה זה חשוב

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

מפעילים של כל תשתית custody או מסחר המחוברת לאינטרנט חייבים להתייחס לבקרות hot wallet, להרשאת עסקאות ולזיהוי אנומליות כאל רכיבים קריטיים.

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

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

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

מה קרה

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

פלטפורמות vibe coding מאפשרות למי שאינם מומחים או למפתחים לחוצי זמן לייצר תוכנה פונקציונלית במהירות, אבל לעתים קרובות מעדיפות מראה ותחושה על פני ברירות מחדל מאובטחות. פגמים נפוצים שנוצרים כוללים סודות hardcoded, היעדר אימות קלט או בקרות גישה, הגדרות ציבוריות כברירת מחדל, הצפנה חלשה, היעדר הגבלת קצב וחשיפה ל-prompt injection.

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

מי מושפע

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

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

למה זה חשוב

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

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