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

מה קרה

תוקפים החלו לנצל את CVE-2026-21589, פגיעות קריטית לגישה שרירותית לקבצים ללא הזדהות במספר מוצרי Atlassian Data Center, בתוך שעות מפרסום proof-of-concept ציבורי של watchTowr.

הגורם הבסיסי הוא ספריית web-resource משותפת שממירה נקודתיים כפולות "::" ללוכסנים קדמיים, ומאפשרת בקשות directory traversal דרך endpoints של plugins לקריאת קבצים ספציפיים ב-web root (כולל WEB-INF) אם הנתיב המדויק ידוע. בסביבות עם אינטגרציית Crowd, הדבר עלול לחשוף פרטי הזדהות בטקסט גלוי מתוך crowd.properties, ולאפשר יצירת חשבונות מנהל דרך ה-API של Crowd.

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

מי מושפע

סביבות self-hosted של Bitbucket Data Center, Confluence Data Center, Jira Software Data Center, Jira Service Management Data Center, Bamboo Data Center, Crowd Data Center, Crucible ו-Fisheye. כל הגרסאות שלפני גרסאות התיקון מאוקטובר 2026 מושפעות.

מוצרי Atlassian Cloud כבר עודכנו. ארגונים עם סביבות חשופות לאינטרנט או עם אינטגרציית Crowd SSO ניצבים בפני הסיכון הגבוה ביותר. משתמשי enterprise של כלי שיתוף הפעולה ו-DevOps האלה נמנים בעשרות אלפים ברחבי העולם.

למה זה חשוב

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

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

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

החילו מיד את עדכוני האבטחה לגרסאות המתוקנות המפורטות ב-advisory של Atlassian (לדוגמה Jira Software 9.12.40 / 10.3.26 / 11.3.12 וקווים מקבילים למוצרים האחרים).

הגבילו גישה מרשתות חיצוניות לסביבות עד להחלת התיקון. פרסו כללי WAF או proxy שחוסמים את תבניות ה-traversal הידועות, כללי Tomcat RewriteValve היכן שרלוונטי, והגבילו גישה ל-API של Crowd לכתובות IP ברשימת allow-list. בדקו לוגי גישה לבקשות resource חשודות והשתמשו בסורק החינמי של watchTowr לבדיקת חשיפה.

מה קרה

האקרים אתיים ב-Pwn2Own Ireland 2026 הדגימו 32 פגיעויות zero-day ייחודיות ביום הראשון של התחרות בקורק, וזכו ביותר מ-368,000 דולר בפרסים בתוספת נקודות Master of Pwn.

היעדים כללו סמארטפונים, מכשירי smart-home, מדפסות וכלי AI. שרשראות בולטות פגעו ב-Sonos Era 300 (כתיבה מחוץ לגבולות בתוספת format string), LiteLLM (אימות קלט ו-code injection ל-reverse shell), Philips Hue Bridge Pro (שבעה zero-days), Lexmark CX532adwe (use-after-free), Oracle Autonomous AI Database (חמישה zero-days), OpenAI Codex (argument injection) ואחרים. Samsung Galaxy S26 נפרץ מספר פעמים.

מי מושפע

בעלים ומשתמשים של המוצרים שנוצלו בהצלחה: Samsung Galaxy S26, Philips Hue Bridge Pro, Oracle Autonomous AI Database, LiteLLM, מדפסות Lexmark ו-Canon, OpenAI Codex, Sonos Era 300, Garmin Index BPM וקטגוריות דומות.

הספקים מקבלים את הפרטים לפי כללי ZDI ויש להם 90 יום לשחרר תיקונים לפני גילוי ציבורי. אוכלוסיות רחבות יותר שמריצות IoT צרכני, מובייל ותשתיות AI מתהוות ללא תיקון חשופות בעקיפין ברגע שהפרטים מתפרסמים.

למה זה חשוב

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

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

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

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

מה קרה

ה-FBI והשירות החשאי האמריקאי פרסמו התרעה משותפת שמאשרת כי קמפיין FortiBleed לגניבת פרטי הזדהות נשאר פעיל, וחדר ליותר מ-86,000 חומות אש ו-SSL VPN gateways של Fortinet FortiGate החשופים לאינטרנט ב-194 מדינות.

התוקפים סורקים פורטלים חשופים, מבצעים credential stuffing ו-password spraying עם פרטי הזדהות ממוחזרים או שדלפו, מחלצים ושוברים נתוני אימות (כולל hashes ישנים מסוג SHA-256) בקנה מידה רחב באמצעות אשכולות GPU, יוצרים חשבונות admin חדשים לצורך persistence, ולעיתים חוסמים את הגישה של משתמשים לגיטימיים. הגישה נמכרת על ידי initial access brokers לשותפי כופרה הקשורים לקבוצות INC/Lynx ו-Payload. הקמפיין נחשף במלואו אחרי שהמפעילים חשפו בעצמם את שרת ה-backend שלהם.

מי מושפע

כל ארגון שמריץ חומות אש FortiGate או VPN gateways החשופים לאינטרנט בלי פרטי הזדהות חזקים וייחודיים ובלי אימות רב-שלבי (MFA). ההיקף המאומת עומד על יותר מ-86,000 מכשירים ברחבי העולם; הערכות מאוחרות יותר מצביעות על מספר גבוה יותר של מערכות ממוקדות. מגזרים שזקוקים לגישה מרחוק מיוצגים באופן בולט, והפעילות כבר שימשה כנקודת כניסה ראשונית לכופרה.

למה זה חשוב

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

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

הגבילו או הסירו מיד גישת ניהול ו-admin ל-FortiGate החשופה לאינטרנט. סיימו את כל סשני ה-admin וה-VPN הפעילים, אפסו את כל פרטי ההזדהות, הפעילו Phishing-resistant MFA, ובדקו את כל החשבונות המקומיים לאיתור תוספות או שינויים לא מורשים.

בדקו לוגים לאיתור אימות חריג ותנועה רוחבית. העדיפו אימות מבוסס תעודות או חומרה, ושמרו על FortiOS מעודכן במלואו. עקבו אחרי ה-IOCs שפורסמו בהתרעת ה-FBI/USSS.

מה קרה

תוקפים פרצו למפעילי צד שלישי של ה-ccTLD של .gh (גאנה), .sl (סיירה לאון) ו-.as (סמואה האמריקנית), ואז שינו רשומות DNS סמכותיות והאצלות nameserver עבור דומיינים נבחרים.

עם שליטה ב-DNS הם עברו domain-control validation והשיגו תעודות HTTPS לא מורשות שמכסות מספר דומיינים של Google, לצד דומיינים של מותגים גלובליים גדולים נוספים ושירותים מקוונים פופולריים. מערכות Google עצמן לא נפרצו, ורשויות התעודות המנפיקות פעלו לפי הנהלים הרגילים. Google למדה על ההשתלטויות בשבוע שעבר, חסמה את התעודות הלא מורשות ב-Chrome באמצעות CRLSets, תיאמה ביטולים עם ה-CAs, והודיעה לארגונים נוספים שנפגעו שזוהו דרך לוגי Certificate Transparency.

מי מושפע

כל דומיין תחת .gh, .sl או .as בחלון החדירה, לצד נכסי Google הספציפיים ומותגי צד שלישי שעבורם הונפקו תעודות לא מורשות. משתמשי Chrome מוגנים על ידי חסימות ה-CRLSet; משתמשי דפדפנים אחרים מסתמכים על הביטולים מצד ה-CA. ייתכן שלא זוהו כל הדומיינים שנפגעו.

למה זה חשוב

תעודות תקפות שהונפקו אחרי השתלטות DNS ברמת הרגיסטרי מאפשרות מתקפות man-in-the-middle או פישינג משכנעות שעוקפות אינדיקטורי אמון רגילים. האירוע מדגים שהחוליה החלשה באקוסיסטם HTTPS יכולה לשבת מעל גם בעל הדומיין וגם ה-CA, ולערער הנחות לגבי אותנטיות תעודות גם כשכל הצדדים פועלים לפי הכללים.

הוא גם ממחיש את הערך של חסימה מהירה מצד הדפדפן וניטור Certificate Transparency.

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

בדקו מיד לוגי Certificate Transparency לאיתור הנפקות בלתי צפויות תחת ה-ccTLDs שנפגעו, ובקשו ביטול אם נמצאו. הטמיעו רשומות CAA, נטרו שינויי DNS, קצרו את משך חיי התעודות במידת האפשר, והתייחסו לאבטחת הרגיסטרי או הרשם כחלק מהערכת סיכוני שרשרת האספקה. ספקי דפדפנים ו-CAs צריכים להמשיך לצמצם חלונות reuse של DCV ותקופות תוקף של תעודות.

מה קרה

OX Security ניתחה 15,465 שרתי Model Context Protocol (MCP) שמאונדקסים בפומבי ברישומים מרכזיים. אחרי הסרת כפילויות נותרו 5,095 שמות מארח ייחודיים, והניתוח חשף כשלי ממשל מערכתיים.

בין הממצאים המרכזיים: 15.6 אחוז משמות המארח מנותבים מחוץ לארה"ב (כולל תשתית בסין וברוסיה), 0.45 אחוז עוברים דרך שירותי tunneling צרכניים כמו ngrok חינמי על מכונות אישיות, ו-2.3 אחוז הם dangling domains (שישה מהם פג תוקפם וזמינים לרישום בעלות נמוכה). שרתים מרוחקים יכולים להריץ קוד ששונה מכל מאגר ציבורי, ובדיקות prompt injection הראו כיצד ניתן לנצל הרשאות "always-allow" קבועות.

מי מושפע

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

למה זה חשוב

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

מה קרה

החוקר NightmareEclipse, עבדלחמיד נסרי (Abdelhamid Naceri), פרסם proof-of-concept בשם BigDiskBuster שמונע מ-Microsoft Defender להתקין עדכוני פלטפורמה ו-security intelligence, בזמן שהשירות ממשיך לרוץ במלואו ונראה תקין.

הכלי ב-C++ באורך של כ-300 שורות עוקב אחרי פעילות עדכון, ואז יוצר קבצים זמניים מוסתרים שצורכים את שטח הדיסק שנותר, כך שהעדכון נכשל עם שגיאה כללית. אחרי ש-Defender מנקה, הכלי משחרר את השטח וחוזר על התהליך. הוא יכול גם להחזיק handle פתוח על MRT.exe. חוקרי LevelBlue שחזרו את ההתנהגות תחת חשבון משתמש רגיל בסביבות Defender סטנדרטיות מהקופסה. לא נדרש אקספלויט של פגיעות.

מי מושפע

נקודות קצה Windows שמריצות Microsoft Defender Antivirus, ובמיוחד כאלה בלי בקרות EDR נוספות, ניטור שטח דיסק או הגנת tamper protection שיזהו את התנהגות מילוי השטח. הטכניקה עובדת על קונפיגורציות סטנדרטיות ויכולה להאריך את חיי נוזקה שכבר נמצאת במערכת על ידי הקפאת חתימות הזיהוי.

למה זה חשוב

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

מה קרה

גורמים לא מורשים ניצלו גישה לגיטימית של חברה דנית פרטית למרשם האוכלוסין המרכזי (CPR) וחילצו שמות, כתובות ומספרי CPR של כ-8.8 מיליון רשומים (חיים, מהגרים ונפטרים).

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

מי מושפע

כ-8.8 מיליון אנשים במערכת ה-CPR מתוך כ-11 מיליון רשומות בסך הכול. אנשים שהפעילו הגנה על שם וכתובת הוחרגו מהשדות האלה. למעשה כל האוכלוסייה הדנית (בתוספת מהגרים ונפטרים) מושפעת. גם החברה הפרטית שפרטי ההזדהות או הגישה שלה נוצלו לרעה מושפעת תפעולית.

למה זה חשוב

פרטי הזדהות בודדים של ספק שנפרצו או נוצלו לרעה עקפו את בקרות הליבה של מאגר זהויות לאומי, והפכו חיבור לגיטימי דמוי API לחשיפת PII המונית. מספרי CPR מתפקדים כמו מספרי Social Security ומאפשרים הונאה, גניבת זהות ופישינג ממוקד. האירוע הוא המחשה קלאסית לכך שמרשמים ממשלתיים מרכזיים דורשים ניטור רציף של צדדים שלישיים, ולא מענקי גישה סטטיים.

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

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

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