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

מה קרה

ב-23 באוקטובר פרסמה PHP הודעה אינפורמטיבית על נתיב נפרד להרצת קוד מרחוק (RCE), יומיים אחרי תיקוני חירום לפגיעויות PHP2Shell הקריטיות (CVE-2026-109618 ו-CVE-2026-109619).

הבעיה החדשה דורשת שילוב חריג: האפליקציה מגדירה את session.serialize_handler ל-php_binary או php_serialize, ואז מחליפה אותו ל-php באמצעות ini_set() לפני session_start(), בעוד ש-session upload progress נשאר מופעל. PHP מעריכה שהסיכון אינו סביר ואינה משחררת תיקון חירום, אלא דוחה אותו לשחרור השגרתי הבא.

לא דווח על ניצול של הווקטור החדש. המתקפות שנצפו עד כה מכוונות רק לצמד PHP2Shell הקודם, שתוקן ב-PHP 8.5.12, 8.4.27, 8.3.36 ו-8.2.35.

מי מושפע

אפליקציות ווב שרצות על PHP ומשנות דינמית את ה-session serialize handler ב-runtime, תוך השארת session upload progress מופעל (ברירת המחדל).

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

למה זה חשוב

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

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

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

הגדירו session.upload_progress.enabled=0 ב-php.ini או דרך הקונפיגורציה עד לשחרור PHP השגרתי הבא שיכלול את התיקון. השינוי הבודד הזה כיסה גם את המיטיגציה ל-CVE-2026-109619 הקודם.

החילו את תיקוני החירום של PHP2Shell אם טרם עשיתם זאת, הפעילו מחדש את ה-workers, ובדקו כל קוד שקורא ל-ini_set() על session.serialize_handler לפני session_start().

מה קרה

Microsoft ייחסה פריצה לשירות הגיבוי בענן של ConnectWise לקבוצת התקיפה Storm-0940, המיושרת עם סין. התוקפים גנבו פרטי הזדהות של אפליקציה ששימשו לקישור ConnectWise לסביבות Microsoft של לקוחות.

לאחר מכן השתמשו במסגרת סוכני ה-AI בקוד פתוח ARTEX כדי לאוטומט ניסיונות התחברות מהירים מול כ-2,250 ארגונים, בקצב של כמעט 3,000 ניסיונות לדקה, והותירו למגינים חלון תגובה מצומצם. אותה מסגרת הופיעה בעבר במתקפות על מערכות פיננסיות בדרום קוריאה.

ConnectWise השעתה את שירות הגיבוי בענן ומשחזרת אותו תוך כדי חקירה.

מי מושפע

לקוחות ConnectWise Cloud Backup שפרטי ההזדהות של האפליקציה שלהם נגנבו, וחשפו את סביבות Microsoft 365 והסביבות הקשורות שלהם.

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

למה זה חשוב

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

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

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

בדקו ובצעו רוטציה מיידית לכל פרטי ההזדהות של אפליקציות ול-OAuth tokens המקושרים ל-ConnectWise. אכפו Phishing-resistant MFA, גישה מותנית וניטור רציף של התחברויות חריגות מכתובות IP בלתי צפויות או מניסיונות בקצב גבוה.

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

מה קרה

Arista Networks שחררה תיקונים ל-CVE-2026-114625, פגיעות SQL injection קריטית (CVSS 9.9) בפורטל ניהול ה-web של VeloCloud Orchestrator (VCO) on-premise. משתמשים מאומתים עם הרשאות בסיסיות יכולים להסלים ל-superuser ולגשת לפונקציות פנימיות מועדפות.

Arista אישרה שהפגיעות מנוצלת בפועל בשטח. סביבות VCO Hosted ו-Dedicated כבר תוקנו מצד הספק. גרסאות התיקון ל-on-prem הן 5.2.3.18, 6.1.3.10, 6.4.2.12 ומעלה.

זו פגיעות ה-zero-day הרביעית שמנוצלת בפועל ש-Arista תיקנה השנה בתשתיות שלה.

מי מושפע

ארגונים שמריצים VeloCloud Orchestrator on-premises בגרסאות שקודמות לגרסאות התיקון שצוינו למעלה. Arista משרתת יותר מ-10,000 לקוחות ברחבי העולם; כל פריסה שחושפת את פורטל הניהול נמצאת בסיכון.

לקוחות VCO Hosted כבר מכוסים בתיקונים מצד הספק.

למה זה חשוב

VCO הוא מישור הבקרה המרכזי לסביבות SD-WAN. הסלמת הרשאות ל-superuser עלולה לחדור לשרת ה-orchestrator ולכל נתוני הרשת והקונפיגורציות המנוהלים.

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

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

עדכנו VCO on-prem ל-5.2.3.18, 6.1.3.10, 6.4.2.12 או מאוחר יותר באופן מיידי. עד אז, הגבילו גישה לממשק ה-web לרשתות ניהול בלבד, נטרו לוגים לפעילות חשודה, וחסמו תעבורה מכתובות ה-IP שדווחו בניצול: 74.82.197.86 ו-38.54.50.151.

עברו על פעולות admin אחרונות וחפשו שינויי הרשאות בלתי צפויים או דלתות אחוריות.

מה קרה

Huntress עקבה אחרי קמפיין בן עשרה שבועות (14 ביולי עד 22 בספטמבר 2026) שבו תוקף שיחזר סשן טוקנים גנובים של Microsoft 365, והשיג 497 כניסות מוצלחות ב-79 ארגונים ולמעלה מ-200,000 ניסיונות כושלים.

הטוקנים הושגו דרך דפי פישינג מסוג adversary-in-the-middle שהעבירו הלאה מסכי התחברות ו-MFA אמיתיים של Microsoft, פישינג device-code והנדסה חברתית. לאחר מכן התוקף שיחזר אותם בכמות גדולה (token spraying) מכתובות IP של 1337 Services GmbH, לעיתים תוך דקות מהגניבה.

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

מי מושפע

משתמשי Microsoft 365 / Entra ID ב-79 הארגונים ש-Huntress זיהתה. כל ארגון שמשתמשיו עלולים להימשך לדפי פישינג מסוג AiTM או device-code חשוף פוטנציאלית.

הקמפיין השתמש בסט מתחלף של שש כתובות בטווח 193.26.115.0/24.

למה זה חשוב

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

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

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

אכפו MFA עמיד לפישינג (passkeys או מפתחות חומרה), מדיניות Conditional Access שחוסמת auth ישן ומיקומים חריגים, ו-continuous access evaluation. נטרו את Entra ID למכשירים חדשים בשם DESKTOP- בתוספת מחרוזות hex ולשינויי שיטת MFA פתאומיים.

חסמו או התריעו על הטווח 193.26.115.0/24, בדקו כללי inbox לשמות חשודים או להעברות ל-RSS Feeds/Conversation History, ודרשו אימות מחדש וניקוי מכשירים אחרי כל חשד לגניבת טוקן. חנכו משתמשים על פישינג device-code ו-AiTM.

מה קרה

תוקפים פרצו לצינור ה-release של LiteLLM ב-21 באוקטובר ופרסמו את הגרסה הזדונית 1.107.0 ל-PyPI ול-registries של Docker. ה-build הכיל נוזקה שגונבת פרטי הזדהות ו-loaders לביצוע קוד מרחוק, שרצים בכל הפעלת Python דרך sitecustomize ו-hooks קשורים.

החבילה הייתה זמינה ב-PyPI במשך כשעתיים (11:39-13:23 UTC), ותגי Docker (v1.107.0, latest, main-latest, main-stable) בחלון דומה. LiteLLM מסרה שהתוקף השתמש ב-OAuth tokens של GitHub CLI שנגנבו משלושה מהנדסים, ככל הנראה מתוך סביבה פנימית חשופה שקבצי הלוג שלה הכילו את ה-tokens.

זו החדירה השנייה לשרשרת האספקה של LiteLLM ב-2026. הארטיפקטים שנפגעו הוסרו; הגרסה הבטוחה האחרונה היא 1.106.2. לקוחות Enterprise עם private registry לא הושפעו.

מי מושפע

כל מי שהתקין litellm==1.107.0 מ-PyPI או משך את תגי ה-Docker שצוינו במהלך חלון החשיפה הקצר. ל-LiteLLM כ-23 מיליון הורדות שבועיות, והיא מותקנת לעיתים קרובות לצד פרטי הזדהות של ענן, ספקי AI ומסדי נתונים.

נתוני התקרית ממרץ כבר קישרו חומר שנגנב לכ-2,500 ארגונים.

למה זה חשוב

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

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

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

אם הותקנו 1.107.0 או תגי ה-Docker המורעלים, התייחסו לכל פרטי ההזדהות באותו host כאל כאלה שנפרצו: בצעו רוטציה מיידית לסודות ענן, ספקי AI, Git, SSH, דפדפן ו-proxy של LiteLLM. נעצו ל-1.106.2 או לגרסאות קודמות ידועות כתקינות, ואמתו hashes של חבילות.

בדקו את site-packages של Python לאיתור קבצי .pth / sitecustomize.py לא צפויים, סקרו scopes של tokens ב-GitHub ובטלו OAuth tokens שאינם בשימוש, ובדדו סביבות build. העדיפו private registries או mirrors מאומתים בפרודקשן.

מה קרה

ESET דיווחה שקבוצת התקיפה UAC-0099 (Earth Sirrush), המיושרת לרוסיה, השיגה גישה ראשונית לחברת לוגיסטיקה אוקראינית ב-16 ביולי 2025 באמצעות spear-phishing, פרסה את הדלת האחורית MATCHWOK דרך ה-downloader MATCHBOIL, ויום לאחר מכן התקינה דלת אחורית שלא תועדה קודם בשם MythicRatatoskr.

הדלת האחורית MythicRatatoskr מתקשרת עם שרת C2 בתוך רשת ה-mesh של Yggdrasil, תומכת בביצוע פקודות, העברת קבצים, צילומי מסך, proxying ב-SOCKS5 ופונקציות דלת אחורית סטנדרטיות נוספות, וייתכן שיש לה וריאנט ל-Linux. הגישה הועברה בהמשך ל-Sandworm (יחידה 74455 של GRU), שב-17 בספטמבר 2025 ביצעה מחיקה הרסנית באמצעות SDelete שחולק דרך Group Policy של Active Directory.

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

מי מושפע

החברה האוקראינית הספציפית לתבואה/לוגיסטיקה שנתקפה ב-2025. סיכון רחב יותר חל על ארגוני ממשל, אנרגיה, לוגיסטיקה ומגזר התבואה באוקראינה שכבר צוינו כיעדי תקיפה של UAC-0099/Sandworm.

יש להתייחס בעדיפות גבוהה לכל סביבה שבה מופיעים תעבורת Yggdrasil או משפחת הדלת האחורית החדשה.

למה זה חשוב

שיתוף פעולה בין מומחה לגישה ראשונית לבין גורם הרסני מאריך את זמן השהייה ברשת ומעלה את הסיכוי להשפעות wiper. רשתות mesh ניסיוניות מסוג peer-to-peer מסבכות את זיהוי ה-C2 המסורתי ואת השבתתו.

השימוש בכלי Living off the Land כמו SDelete דרך GPO מראה כיצד ערוצי ניהול לגיטימיים יכולים להשלים את המתקפה אחרי שדלתות אחוריות חשאיות מבססות אחיזה.

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

חסמו או נטרו מקרוב תעבורה הקשורה ל-Yggdrasil ופרוטוקולי mesh לא מוכרים. חפשו אינדיקטורים של MATCHWOK, MATCHBOIL ו-MythicRatatoskr, פרוקסי SOCKS5 בלתי צפויים, ו-SDelete או כלי מחיקה דומים שנדחפים דרך Group Policy.

הקשיחו שערי מייל מול spear-phishing, אכפו הרשאות מינימליות ו-allow-listing של אפליקציות, בצעו סגמנטציה למערכות קריטיות, ושמרו גיבויים offline או immutable שנבדקו לשחזור מהיר מאירועי wiper.

מה קרה

חוקרי אבטחה ומפעילים כינו את מקבץ הגילויים והמתקפות מסוף אוקטובר 2026 בשם "Black October". במרכז עומדות שתי הפגיעויות הקריטיות PHP2Shell (שנתגלו בסיוע כבד של AI על ידי Wiz ואחרים), שבהן ניסיונות האקספלויט זינקו מאלפים למיליונים תוך שעות מהגילוי הפומבי, לפי Cloudflare.

באותה תקופה עלו גם בעיות או אירועים שפגעו בתשתית התעודות של eMudhra, ב-Node.js, ב-GitLab, ב-Plex, ב-Railway, ב-OpenCode ובשירותים נפוצים נוספים, לצד קמפיינים התקפיים מואצים ב-AI. מומחים, מקריפטוגרפים ועד מנכ"לי ספקים, מתארים קפיצת מדרגה הן במהירות גילוי הפגיעויות והן באוטומציה של מתקפות.

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

מי מושפע

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

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

למה זה חשוב

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

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