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

מה קרה

גורמי איום החלו לנצל עקיפת אימות בחומרה גבוהה ב-OpenSSH, המכונה SSHole ומזוהה כ-CVE-2026-123158.

הפגיעות נובעת מפרשנות שגויה של השאלה האם מחרוזת היא hash של סיסמה. במערכות Linux שמשתמשות ב-musl libc בלי PAM, sshd עלול לקבל כל סיסמה באורך 257-1024 תווים כאימות תקף עבור חשבונות מסוימים (כולל root) שבהם שמור '*' בשדה הסיסמה, כי crypt() של musl מחזיר '*' על קלטים ארוכים והתוצאה תואמת את הערך השמור.

OpenSSH שחררה תיקונים בשבוע שעבר. חוקרים ב-WatchTowr, Previdian, GreyNoise ו-Defused זיהו ניסיונות ניצול ראשונים בסוף השבוע, עד כה בעיקר מצד בוטנטים וכורי קריפטו, כאשר Previdian מציינת עשרות ניסיונות ממדינות שונות החל מסביבות 6 בנובמבר 2026.

מי מושפע

OpenSSH לפני 10.6p2 בהפצות Linux שמשתמשות ב-musl libc עם PAM מושבת. זה כולל Alpine, Buildroot, OpenWrt, Yocto ומערכות משובצות או מינימליות דומות.

החשבונות המושפעים כוללים בדרך כלל root, משתמשי key-only שנוצרו בלי סיסמה, משתמש ברירת המחדל של Alpine בתמונות tiny-cloud, ומשתמשי directory service דרך musl-nscd. מערכות שמשתמשות ב-glibc או ב-PAM אינן מושפעות ממסלול ספציפי זה.

למה זה חשוב

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

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

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

עדכנו את OpenSSH ל-10.6p2 או מאוחר יותר מיד, והפעילו מחדש את sshd.

במערכות Alpine ובמערכות musl דומות, החילו עדכוני יצרן בהקדם. הגבילו את חשיפת ה-SSH בכללי firewall, השתמשו באימות key-only במידת האפשר, ונטרו ניסיונות התחברות חריגים עם סיסמאות ארוכות. בדקו את לוגי ה-auth לאיתור התחברויות מוצלחות לחשבונות שלא אמורים לקבל סיסמאות.

מה קרה

SonicWall תיקנה פגיעות באכיפת אימות שמנוצלת בפועל ב-SSL-VPN של SonicOS, CVE-2026-19868 (CVSS 7.5).

כש-SAML מופעל עבור SSL-VPN, משתמש שמחזיק בפרטי הזדהות תקפים לשיטת אימות חלופית יכול לעקוף את בקרות ה-SAML וכל MFA שנאכף דרך ספק הזהויות (IdP). ההתחברות מצליחה עם סיסמה בלבד במקום לעבור דרך Okta, Entra ID או דומיהם.

CISA הוסיפה את ה-CVE לקטלוג Known Exploited Vulnerabilities שלה. SonicWall אישרה שהיא חוקרת דיווחים על ניצול, אך לא פרסמה פרטי תקיפה או IoCs. אותם שחרורים מטפלים גם בשש פגיעויות נוספות שלא סומנו כמנוצלות.

מי מושפע

חומות אש פיזיות ווירטואליות של SonicWall מדור Gen7 ו-Gen8 שמריצות SonicOS 7.3.3-7015 ומטה, או 8.2.2-8015 ומטה, עם SAML מופעל עבור SSL-VPN.

תוקן ב-7.3.4-7013 ומעלה, וב-8.2.3-8015. חומרת Gen6 וישנה יותר היא end-of-support ואינה רשומה כמושפעת, אך יש לשדרג אותה. ארגונים שמסתמכים על MFA של SAML ל-VPN ניצבים בחשיפה העיקרית.

למה זה חשוב

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

סוכנויות אזרחיות פדרליות ניצבות בפני מועד יעד לתיקון ב-20 בנובמבר 2026 במסגרת KEV. בלי IoCs, הזיהוי מסתמך על מתאם לוגים בין הצלחת VPN לבין היעדר אירועי MFA ב-IdP.

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

עדכנו ל-SonicOS 7.3.4-7013+ או 8.2.3-8015+ מיד. אין פתרונות ביניים זמינים.

בדקו התחברויות SSL-VPN אחרונות לאיתור כאלה שאין להן התחברות מקבילה ב-IdP ואירוע MFA. אפסו את פרטי ההזדהות של החשבונות האלה, בדקו את פעילות הסשן ובצעו רוטציה לסודות. העדיפו גישת VPN דרך מסלולים מודרניים שנאכפים על ידי IdP, ושקלו סגמנטציית רשת לסיכון שנותר. שדרגו חומרת Gen6 שהגיעה ל-end-of-support.

מה קרה

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

אזהרה ראשונית צרה יותר כוונה להרחבת Paywall. כ-80 דקות לאחר מכן הרחיב הפרויקט את ההודעה לקריאה לכיבוי מלא, במקביל להכנת מספר תיקוני אבטחה. מפעיל אחד דיווח על חשבונות חדשים שניצלו פגם כדי למשוך 2,285,545 סטושי (כ-0.023 BTC) לפני שנבלמו. הפרויקט אישר את האקספלויט הספציפי בהרחבה שנעשה בו שימוש, אך טרם פרסם את שמו בזמן הדיווח. נכון לתחילת 9 בנובמבר 2026 לא הייתה גרסה מתוקנת זמינה. התיקונים הוערכו בתוך 24 עד 48 שעות. הסביבות המתארחות של הפרויקט עצמו ב-my.lnbits.com הוצאו מהרשת.

מי מושפע

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

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

למה זה חשוב

LNbits נמצא בשימוש נרחב לטיפים ב-Lightning, ל-paywalls ולארנקים משמורתיים קטנים. ניצול בפועל יכול לרוקן יתרות במהירות, והיעדר תיקון מיידי יחד עם פירוט טכני ציבורי חלקי משאירים את המפעילים חשופים.

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

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

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

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

מה קרה

Google DeepMind, בשיתוף קריפטוגרפים מ-UC San Diego ומ-Inria, דיווחה שסוכני AI בהנחיה אנושית מצאו שתי גישות בעלות נמוכה יותר נגד RSA של 1024 ביט.

אחת משפרת זיוף חתימות מול padding מסוג PKCS#1 v1.5 שבשימוש בממשקי HSM מסוימים של PKCS#11: ברגע שתוקף שולט בכמחצית או יותר מהבלוק החתום, ה-padding אינו מוסיף הגנה. בשיחזור בסביבת sandbox קיצצו הסוכנים את זמן ה-CPU בכ-3.5x (391 שנות ליבה לעומת 1,380). קו עבודה שני משפר פירוק לגורמים על פני מפתחות מרובים, באמצעות פריסת חישוב מקדים גדול על פני מפתחות רבים באותו גודל. RSA מודרני של 2048 ביט ומעלה נשאר ללא השפעה, לפי החוקרים.

מי מושפע

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

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

למה זה חשוב

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

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

מה קרה

תוקפים ניצלו פגיעות אבטחה בתשתית Web3Auth שמשמשת את ארנק Keplr להתחברות דרך Google ו-Apple, וגנבו כספים מחלק מארנקי ה-social login.

Keplr תיארה את האירוע כפריצת מפתח פרטי בחשבונות Google ו-Apple שנפגעו. לאחר מכן Web3Auth השתמשה באותו נתיב כדי לרוקן באופן יזום ארנקים נוספים שהיו בסיכון אל כתובות שחזור ברשתות ממשפחת Cosmos ובשרשראות EVM, בשיתוף פעולה עם Keplr, כך שהכספים יישמרו ולא ייגנבו. ארנקים שנוצרו עם משפטי שחזור או התקני חומרה אינם מושפעים. ההתחברות דרך Google ו-Apple הושהתה. הספקים לא מסרו ציר זמן מדויק לשורש הבעיה ולא סכום כולל בדולרים; הערכות צד שלישי ציינו כמיליון דולר שנגנבו ויותר מ-6 מיליון דולר שהועברו לארנקי שחזור מעשרות אלפי כתובות.

מי מושפע

משתמשי Keplr שיצרו ארנקים דרך התחברות Google או Apple באמצעות Web3Auth. משתמשי משפט שחזור וארנקי חומרה אינם מושפעים.

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

למה זה חשוב

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

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

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

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

סמכו רק על הערוצים הרשמיים של Keplr ו-Web3Auth; התעלמו מהודעות פרטיות שמציעות עזרה בשחזור. השתמשו ברשימות כתובות השחזור שפורסמו כדי להבדיל בין העברות חילוץ רשמיות לבין העברות זדוניות. העדיפו הגדרות seed או חומרה non-custodial לאחזקות משמעותיות מכאן ולהבא.

מה קרה

גורמי איום מנצלים בפועל את Plex2Shell, שרשרת של ארבע פגיעויות ב-Plex Media Server (CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, CVE-2026-96656), נגד אפליקציית Plex במכשירי NAS של QNAP.

הפגיעויות תוקנו בקיץ 2026; ניצול נרחב החל באמצע אוקטובר לאחר שפורסמו פרטים טכניים וקוד PoC. כל הארבע נמצאות ב-CISA KEV. הניצול אינו דורש פרטי הזדהות תקפים ויכול להוביל להרצת קוד שרירותית תחת שירות Plex. QNAP אישרה דיווחי משתמשים על חדירה, מסרה שלא אירע אובדן נתונים במקרים שטופלו בסיועה, והדגישה שהבעיות קיימות רק ב-Plex Media Server ולא ב-QTS/QuTS hero עצמם.

מי מושפע

משתמשי NAS של QNAP שהתקינו את Plex Media Server דרך App Center ולא עדכנו מעבר לגרסאות הפגיעות (לפני 1.43.3). סביבות חשופות לאינטרנט עם העברת פורט 32400 נמצאות בסיכון הגבוה ביותר.

כל ארגון או משתמש ביתי שמריץ Plex לא מעודכן על NAS או על מארחים אחרים חשוף לאותו סיכון שרשרת.

למה זה חשוב

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

הפריסה הרחבה של QNAP בקרב צרכנים ו-SMB, יחד עם התקנה קלה דרך App Center, מרחיבה את רדיוס הפגיעה. אחרי פרסום ה-PoC מתבצעת סריקה המונית, ולכן סביר שיחידות חשופות לאינטרנט שלא עודכנו כבר נבדקו.

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

עדכנו את Plex Media Server לגרסה 1.43.3 ומעלה באופן מיידי. התייחסו למכשירים נגישים מהאינטרנט כאל כאלה שעלולים להיות חשופים לחדירה: התקינו מחדש את Plex, בצעו רוטציה לסיסמאות של Plex ושל ה-NAS, ופעלו לפי מדריך התיקון של QNAP.

השביתו את Plex Remote Access והפסיקו להעביר את פורט 32400 אלא אם נדרש; השתמשו ב-VPN במקום. דאגו ש-QTS/QuTS hero וכל האפליקציות יישארו מעודכנים. הגבילו את חשיפת ה-NAS ונטרו תהליכים חריגים או חיבורים יוצאים.

מה קרה

תוקפים גנבו סכום מוערך של 133 מיליון דולר מהבנק הקואופרטיבי הצרפתי Crédit Mutuel Arkéa, באמצעות העברות מזויפות מחשבונות הבנק עצמו, לאחר שפרצו לאחד מספקי השירות שלו.

חוקר הבלוקצ'יין ZachXBT עקב אחרי יותר מ-100 מיליון דולר ואז כ-27 מיליון דולר נוספים שיצאו מחשבונות בבורסות מרכזיות כ-USDC/USDT, הומרו ל-ether, עברו דרך בורסות מיידיות, וחלקם הומרו ל-Monero, החל מסביבות 1 בנובמבר 2026. הבנק אישר מתקפה שאפשרה עסקאות מזויפות, דיווח לרשויות והשעה זמנית חלק מההעברות. הוא מסר שהנתיב עבר דרך פלטפורמת ספק שירות שלא נקב בשמה, לא דרך חשבונות לקוחות או בנק האינטרנט Fortuneo שלו, והכחיש טעות אנוש פנימית. נמסר שנכסי הלקוחות לא נפגעו, למעט עיכובים בעיבוד.

מי מושפע

Crédit Mutuel Arkéa (יותר מ-5.8 מיליון לקוחות, מאות מיליארדים בנכסים) וספק השירות שלא נקב בשמו, שפלטפורמתו הייתה נקודת הכניסה.

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

למה זה חשוב

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

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

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

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

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