חדשות סייבר יומיות - 24 באוקטובר 2026
סייבר בקצרה נתמך על ידי הקוראים שלו. ייתכן שנקבל עמלת שותפים, בלי עלות נוספת עבורכם, אם תקנו דרך קישור בעמוד הזה.
PHP מזהירה מפני נתיב RCE שני שלא תוקן אחרי PHP2Shell
בינוניתמה קרה
יומיים אחרי תיקוני חירום לפגיעויות PHP2Shell הקריטיות, PHP פרסמה advisory מידעי על נתיב RCE נוסף שקשור ל-session upload progress.
הבעיה דורשת שילוב חריג: session.serialize_handler מוגדר ל-php_binary או ל-php_serialize, ואז מוחלף בזמן ריצה דרך ini_set() ל-php לפני session_start(), בזמן ש-session upload progress נשאר מופעל. התיקונים מ-21 באוקטובר שטיפלו ב-CVE-2026-109618 וב-CVE-2026-109619 לא סוגרים את הנתיב הזה.
לא דווח על ניצול של הנתיב החדש. מתקפות PHP2Shell קודמות זינקו במהירות אחרי הגילוי, אך לא הובילו להרצת קוד מוצלחת מאומתת בשטח.
מי מושפע
יישומי web שרצים על PHP ומשנים דינמית את ה-session serialize handler בזמן ריצה, תוך השארת session.upload_progress.enabled במצב מופעל (ברירת המחדל). רוב היישומים שלא משנים את ה-handler בזמן ריצה אינם חשופים דרך הנתיב הזה.
PHP לא פרסמה גרסאות מושפעות ספציפיות. תיקוני PHP2Shell הקודמים נכנסו ל-8.5.12, 8.4.27, 8.3.36 ו-8.2.35.
למה זה חשוב
פגיעות RCE ללא הזדהות ב-PHP נשארת בעלת השפעה גבוהה כי השפה מניעה חלק גדול מה-web. גם נתיב קונפיגורציה צר ממשיך להפעיל לחץ על מפעילים שכבר מיהרו להחיל תיקון על שתי הפגיעויות הראשונות.
תוקפים כבר גילו עניין במחלקת PHP2Shell, עם מיליוני סריקות וניסיונות להטמיע וריאנטים של Mirai זמן קצר אחרי הגילוי הראשוני.
איך אפשר היה למנוע את זה
הגדירו session.upload_progress.enabled=0 ב-php.ini, ב-pool של FPM או בקונפיגורציית השרת עד ל-release השגרתי הבא שיכלול את התיקון. אל תסמכו על שינויי ini_set() מאוחרים או על .user.ini.
מי שכבר יישם את המיטיגציה הזו לפגיעויות PHP2Shell הקודמות יכול להשאיר אותה במקום. ודאו גם שתיקוני החירום ל-CVE-2026-109618 ול-CVE-2026-109619 מותקנים.
מונחים מקצועיים רלוונטיים
- Remote code execution (RCE)
- פגיעות שמאפשרת לתוקף להריץ פקודות או תוכניות משלו על מערכת יעד, לעיתים קרובות בלי להתחבר.
- Session serialize handler
- ההגדרה ב-PHP ששולטת באופן הקידוד והפענוח של נתוני session בעת כתיבה לאחסון או קריאה ממנו. החלפה שלה בזמן ריצה עלולה ליצור נתיבי type-confusion או injection.
LiteLLM: מתקפת שרשרת אספקה שמנצלת hooks של אתחול Python
גבוההמה קרה
ב-21 באוקטובר 2026 פורסמה גרסה פרוצה של LiteLLM 1.107.0 ל-PyPI ולתגי Docker הרשמיים. ה-wheels הזדוניים השתילו קבצים שרצים במהלך אתחול רגיל של מפרש Python, כך שה-payload יכול לרוץ גם אם היישום מעולם לא מייבא את LiteLLM.
ניתוח של Microsoft זיהה אספן פרטי הזדהות שמופעל דרך הרחבת נתיב .pth, ו-loader מכוון Unix דרך sitecustomize.py. האספן כיוון לסיסמאות ועוגיות דפדפן, מפתחות SSH, פרטי הזדהות לענן (AWS, Azure, GCP), Kubernetes, Docker, טוקנים של GitHub CLI וסודות נוספים, ואז ביצע הוצאת נתונים (exfiltration). מודול משני יכול היה למשוך קוד מרחוק.
החבילה הייתה זמינה ב-PyPI במשך כשעתיים ובתגי Docker מעט יותר זמן לפני שהוסרה. החדירה נבעה מפרטי הזדהות גנובים של מפתח שהפנו את ה-workflow של ה-release למאגר שנראה זהה למקור.
מי מושפע
כל מי שהתקין litellm==1.107.0 מ-PyPI או משך את תגי Docker המושפעים (v1.107.0, latest, main-latest, main-stable) במהלך החלון הקצר ב-21 באוקטובר. תחנות עבודה של מפתחים, runners של CI וסביבות production שהפעילו Python לאחר מכן נמצאים בסיכון.
LiteLLM נמצא בשימוש נרחב כ-proxy ו-SDK לספקי LLM מרובים, כך שרדיוס הפגיעה כולל מערכי יישומי AI ומאגרי פרטי ההזדהות שלהם.
למה זה חשוב
חדירות בשרשרת אספקה שמצמידות hooks לאתחול Python עוקפות זיהוי רגיל מבוסס import ויכולות לגנוב בהיקף רחב פרטי הזדהות יקרי ערך לענן, לאירוח קוד ול-AI. ברגע שהסודות נגנבים, תוקפים יכולים לבצע תנועה רוחבית אל מאגרים, חשבונות ענן ומערכות production.
החלון הקצר עדיין היה משמעותי, כי התקנות אוטומטיות ותלויות ללא pin יכולות למשוך את הגרסה האחרונה מיידית.
איך אפשר היה למנוע את זה
בדקו סביבות עם pip show litellm או כלי מקביל; אם 1.107.0 מותקנת, התייחסו לסביבה כנפרצת. בצעו רוטציה לכל פרטי ההזדהות שעלולים להיחשף (מפתחות ענן, טוקנים של GitHub, מפתחות SSH, סודות שמורים בדפדפן). נעצו גרסאות ידועות כתקינות והימנעו מהתקנות ללא pin.
אל תפעילו Python או pip בתוך סביבה חשודה לצורך חקירה. בנו מחדש מתמונות בסיס נקיות, הפעילו בדיקות שלמות לחבילות, ונטרו את הקבצים הזדוניים הידועים (cook.pth, cook.py, sitecustomize.py). עברו על זיהויי Defender או EDR של התנהגות האספן.
מונחים מקצועיים רלוונטיים
- Supply chain attack
- מתקפה שחודרת לרכיב תוכנה מהימן או לערוץ ההפצה שלו, כך שמשתמשים שמתקינים או מעדכנים אותו מקבלים נוזקה.
- Python startup hooks
- מנגנונים כמו קבצי .pth ו-sitecustomize.py שה-interpreter של Python מריץ אוטומטית בזמן האתחול, לפני שרוב קוד האפליקציה רץ.
כלי AI חושפים פגיעויות PHP בנות עשרות שנים
גבוההמה קרה
חוקרי אבטחה השתמשו במודלי AI מתקדמים כדי להפוך פגמים ב-PHP שהיו ידועים מזמן אך לא מעשיים לניצול, לאקספלויטים עובדים של הרצת קוד מרחוק, שמכונים כעת PHP2Shell (CVE-2026-109618 ו-CVE-2026-109619).
חוקרים מ-Calif זיהו לראשונה נתיבים מעשיים בתחילת אוגוסט בסיוע AI, במסגרת תוכנית Patch the Planet של OpenAI. צוותי Wiz ו-OpenAI גילו מאוחר יותר את הבעיות מחדש באופן עצמאי, באמצעות מודלים כמו Gemini וגרסאות GPT. חלק מהבעיות הבסיסיות תועדו כבר ב-2024, אך נחשבו מורכבות מדי לניצול אמין בידי אדם באותה תקופה.
תיקוני חירום שוחררו ב-21 באוקטובר. ניסיונות הניצול זינקו תוך שעות מהגילוי והגיעו למיליונים לפי Cloudflare, אך השתלטויות מוצלחות מאומתות טרם דווחו עד כה.
מי מושפע
מערכות PHP שקיימות שנים רבות (בעיות במנוע המרכזי שמשפיעות על חלק ניכר מהאתרים בעולם). שרתים שלא עודכנו ומריצים גרסאות שקדמו לתיקוני החירום מ-21 באוקטובר (8.5.12, 8.4.27, 8.3.36, 8.2.35) חשופים.
כל ארגון שמריץ אפליקציות ווב מבוססות PHP, במיוחד כאלה עם session upload progress מופעל כברירת מחדל.
למה זה חשוב
AI מוריד את רף המיומנות והזמן הנדרשים כדי להפוך באגים תיאורטיים או מורכבים לאקספלויטים אמינים. פגמים שישבו ללא ניצול במשך שנים יכולים להפוך פתאום ליעדי סריקה המונית ברגע שמודלים עוזרים לבצע להם reverse-engineering.
כך מצטמצם החלון בין הגילוי לבין הפיכה לכלי תקיפה, וגובר הלחץ על צוותים עם משאבים מוגבלים שכבר מתמודדים עם נפחי פגיעויות שיא.
איך אפשר היה למנוע את זה
החילו מיד את תיקוני החירום של PHP. כבקרה זמנית הגדירו session.upload_progress.enabled=0. נטרו ניסיונות סריקה וניצול מול נקודות קצה של PHP.
מפו את גרסאות ה-PHP בכל הסביבות, תעדפו שרתים חשופים לאינטרנט, והתייחסו לפיתוח אקספלויטים בסיוע AI כקו בסיס חדש לדחיפות התיקונים ברכיבי קוד פתוח יסודיים.
מונחים מקצועיים רלוונטיים
- Vulnerability disclosure
- התהליך של דיווח פרטי על פגם אבטחה לספק, כדי שיהיה אפשר להכין תיקון לפני שפרטים פומביים יאפשרו לתוקפים לנצל אותו.
- Exploit development
- העבודה המתמחה של הפיכת באג בתוכנה לקוד אמין ומחומש שמשיג מטרת תוקף קונקרטית, כמו הרצת קוד מרחוק.
Token Replay: חדירה ל-Microsoft 365 ב-79 ארגונים
גבוההמה קרה
Huntress עקבה אחרי קמפיין בן עשרה שבועות (14 ביולי עד 22 בספטמבר 2026) שבו תוקף שיחזר טוקני סשן גנובים של Microsoft 365 כדי לגשת לחשבונות ב-79 ארגונים. החוקרים ספרו 497 התחברויות מוצלחות ויותר מ-200,000 ניסיונות כושלים.
הטוקנים הושגו באמצעות ממסרי adversary-in-the-middle שהעבירו לקורבנות דפי התחברות ו-MFA אמיתיים של Microsoft, פישינג מסוג device-code והנדסה חברתית. מכיוון שהטוקן מונפק אחרי MFA, השחזור עוקף MFA נוסף. הפעילות הגיעה בעיקר מבלוק IP-ים של ספק האחסון הגרמני 1337 Services GmbH.
לאחר החדירה רשם התוקף מכשירים זדוניים (לפחות 48 בשם DESKTOP- בתוספת hex), החליף שיטות MFA ב-19 ארגונים, ויצר כללי תיבה נכנסת מוסתרים כדי להסתיר דואר. בלפחות מקרה אחד שימשה תיבת דואר שנפרצה למשלוח מייל חיצוני בנושא שכר.
מי מושפע
משתמשי Microsoft 365 / Entra ID ב-79 הארגונים ש-Huntress זיהתה, וכל מי שותקף באותה תשתית. כל tenant בלי Conditional Access חזק, בלי device compliance או בקרות token-binding חשוף פוטנציאלית לטכניקות token-replay דומות.
מנהלי דואר עסקי וזהויות הם הגורמים העיקריים שצריכים להגיב.
למה זה חשוב
גניבת טוקני סשן ושחזורם שוברים הגנות של סיסמה + MFA שארגונים רבים עדיין רואים כמספיקות. אחיזות מתמשכות דרך מכשירים זדוניים ומאמתים בשליטת התוקף שורדות איפוסי סיסמה אלא אם מנקים אותן במפורש.
כללי תיבה נכנסת מוסתרים מאפשרים פריצת דואר עסקי חשאית, הונאת שכר ופישינג פנימי נוסף בזמן שהקורבנות אינם מודעים לכך.
איך אפשר היה למנוע את זה
אכפו מדיניות Conditional Access שבוחנת device compliance, מיקום וסיכון; העדיפו token protection / binding היכן שזמין. סירקו את יומני ההתחברות של Entra לאיתור בקשות טוקן OAuth חריגות, מזהי client לא מוכרים וטווח ה-IP הידוע של הקמפיין.
אחרי כל חדירה חשודה, בדקו והסירו מכשירים ושיטות MFA לא מוכרים, מחקו כללי תיבה נכנסת חשודים, אפסו סשנים ודרשו רישום מחדש של מאמתים. חסמו או התריעו על ה-ASN של ספק האחסון שנצפה, ובצעו רוטציה לכל סוד שנחשף.
מונחים מקצועיים רלוונטיים
- Multifactor authentication (MFA)
- בדיקת התחברות שדורשת משהו נוסף מעבר לסיסמה, כמו קוד מאפליקציה או מפתח חומרה.
- Adversary-in-the-middle (AiTM)
- מתקפה שממוקמת בין המשתמש לבין שירות ההתחברות האמיתי ומעבירה בפרוקסי את הדפים המקוריים, כדי ללכוד את ה-token של הסשן לאחר האימות.
אפיליאייטים של כופרה מפעילים סוכני AI לחדירות
קריטיתמה זה אומר
- קודם כל מכשירי קצה: Fortinet, SimpleHelp, cPanel ושערי VPN ללא תיקונים נשארים וקטור הגישה הראשונית המועדף.
- AI באישור אנושי: המודלים מבצעים את עיקר הפקודות, והמפעילים משכתבים prompts שנדחו ומציגים אותם כעבודת red team מורשית.
- שימוש חוזר בפרטי הזדהות מכפיל את הנזק: סיסמה אחת בשימוש חוזר פתחה גישה ל-VPN, לשרתים, לפלטפורמות RMM ולפלטפורמות גיבוי במקרה מתועד.
- פעולה: תעדפו CVEs של KEV במכשירי קצה, פרטי הזדהות ייחודיים, ובידוד מהיר של כל מארח גישה מרחוק שנפרץ.
מה קרה
SOCRadar חשפה מערכת אקולוגית של חדירות מונעת AI שבה משתמשים אפיליאייטים של קבוצות הכופרה INC ו-The Gentlemen. במרכזה עומד Phantom, מסגרת Autonomous Red Team Kill Chain שמבצעת שלבים באמצעות OpenCode ומודלים מסחריים המתארחים ב-OpenRouter, כשמפעיל אנושי מספק prompts ייעודיים לקורבן ומאשר פעולות.
תשתית שנחשפה (כולל ספרייה ב-45.227.254.43) הכילה 8,257 הודעות ב-133 סשנים, מאגרי ידע למעקב אחר קורבנות, פרטי הזדהות גנובים, מצפינים מותאמים וכלים. הגישה הראשונית כוונה למערכות קצה ולמערכות גישה מרחוק בקנה מידה רחב, תוך ניצול פגיעויות ידועות ובכללן CVE-2024-57727 (SimpleHelp), CVE-2026-35616 (FortiClient EMS), CVE-2026-41940 (cPanel/WHM), ואחרות שהוכנו או נמצאות בפיתוח.
לאחר הכניסה מיפו המפעילים דומיינים, ביצעו הסלמת הרשאות, קצרו פרטי הזדהות, תעדפו קבצים רגישים, הוציאו נתונים (exfiltration) דרך מנהרות reverse-SOCKS, שיבשו כלי אבטחה והכינו פריסת כופרה. שימוש חוזר בפרטי הזדהות שימש כמכפיל כוח משמעותי.
מי מושפע
ארגונים שמריצים התקני קצה פגיעים ותוכנות גישה מרחוק (FortiClient EMS, SimpleHelp, cPanel/WHM, שערי VPN, SonicWall SMA, וסביבות מסוימות של WordPress/Drupal/LiteLLM). מגזרי הייצור, התעשייה, הבריאות ומגזרים נוספים מופיעים בין היעדים שזוהו בשם.
כל ארגון עם ממשקי ניהול החשופים לאינטרנט ועם היגיינת פרטי הזדהות חלשה נמצא בטווח של מבצעי אפיליאייטים מואצי AI דומים.
למה זה חשוב
סוכני AI מקצרים את הזמן והמיומנות הנדרשים להרצת kill chains מלאים מחדירה ועד כופרה, בעוד שבני אדם שומרים על שליטת האישור. לוגים שנחשפו מראים שימוש מבצעי אמיתי, לא רק תיאוריה, כולל מצפינים מותאמים ומעקב אחר מספר קורבנות.
זה מעלה את הקצב והנפח של פעילות כופרה ומכריח מגנים להניח post-exploitation מהיר יותר ברגע שמכשיר קצה נפרץ.
איך אפשר היה למנוע את זה
עדכנו והקשיחו מיד את ה-CVEs בקצה שמנוצלים בפועל (path traversal ב-SimpleHelp, עקיפת אימות ב-FortiClient EMS, עקיפת אימות ב-cPanel, ופריטי KEV קשורים). השביתו או הגבילו בחומרה ממשקי גישה מרחוק וניהול מיותרים; אכפו פרטי הזדהות ייחודיים ומנוטרים ו-MFA בכל מקום.
פרסו EDR עם anti-tamper חזק, נטרו reverse-SOCKS ותנועה רוחבית חריגה, שמרו גיבויים offline או כאלה שאינם ניתנים לשינוי, ובצעו סגמנטציה לנתונים קריטיים של כספים, HR ומשפטים. צודו אחר מחווני התשתית שפורטו ובחנו מדיניות שימוש ב-AI/LLM שעלולה להיות מנוצלת בכלי בסגנון red-team.
מונחים מקצועיים רלוונטיים
- Ransomware affiliate
- שותף פלילי שפורץ לרשתות ופורס כופרה בשם מותג ransomware-as-a-service גדול יותר, בתמורה לחלק מהכופר.
- Kill chain
- רצף השלבים של מתקפה, מגישה ראשונית דרך הסלמת הרשאות, תנועה רוחבית וגניבת נתונים, ועד לפגיעה הסופית כמו הצפנה.
פריצה ב-Capcom חושפת 11.7 מיליון רשומות חשבון
גבוההמה קרה
Capcom דיווחה שצד שלישי השיג גישה לא מורשית למידע לקוחות של CAPCOM ID. פעילות חשודה זוהתה ואומתה ב-19 באוקטובר 2026.
תוקפים השיגו 11,774,247 רשומות שהכילו כתובות אימייל לצד נתוני מערכת החשבון (זמן יצירה, התחברות אחרונה, מספר התחברויות, IP של ההתחברות האחרונה). ב-43 רשומות הנתונים כללו גם תאריך לידה, מגדר, מדינה/אזור וכינוי. סיסמאות שהוגדרו במקור על ידי הלקוחות לא אומתו כחשופות, אך התוקפים שינו סיסמאות ב-196 חשבונות (שאופסו מאז על ידי Capcom). נתוני כרטיסי תשלום לא הושפעו.
Capcom חסמה את הגישה, הקימה מערך תגובה לאירוע, דיווחה לרשויות ביפן, ומצהירה שטיפלה בשיטת התקיפה. אף קבוצה לא נטלה אחריות. השירותים ממשיכים לפעול.
מי מושפע
כל מי שמחזיק ב-CAPCOM ID לשימוש בשירותי הרשת ובמשחק המקוון של Capcom, במשחקים כמו Resident Evil, Street Fighter, Monster Hunter ואחרים. 11.7 מיליון הרשומות הן מכל העולם; תת-קבוצה קטנה כללה שדות אישיים נוספים.
שחקנים: התייחסו בחשד מוגבר לכל אימייל בנושא Capcom.
למה זה חשוב
מאגרי אימייל גדולים מאפשרים ניסיונות פישינג ממוקדים והשתלטות על חשבונות שמתחזים ל-Capcom או לשירותים קשורים. גם בלי סיסמאות, השילוב של אימיילים, היסטוריית התחברות וכתובות IP עוזר לתוקפים לבנות פיתיונות משכנעים.
שינויי סיסמה לא מורשים בתת-קבוצה של חשבונות מראים שהתוקפים השיגו רמה מסוימת של שליטה בחשבונות במהלך החדירה.
איך אפשר היה למנוע את זה
היזהרו מאימיילים ומהודעות פישינג שמתחזים ל-Capcom; אל תלחצו על קישורים ואל תפתחו קבצים מצורפים. שנו את סיסמת ה-CAPCOM ID שלכם אם עדיין לא עשיתם זאת, הפעילו אימות דו-שלבי אם הוא זמין, ובדקו את פעילות החשבון.
Capcom פתחה ערוצי תמיכה אזוריים. עקבו אחרי חשבונות אשראי וחשבונות משחק לאיתור ניצול משני, והתייחסו לבקשות איפוס סיסמה או אימות לא מבוקשות כעוינות.
מונחים מקצועיים רלוונטיים
- Data breach
- אירוע שבו צד לא מורשה ניגש למידע מוגן או סודי, מעתיק אותו או גונב אותו.
- Account takeover
- מצב שבו תוקף משתלט על חשבון משתמש לגיטימי, לרוב כדי לגנוב מידע נוסף, לבצע הונאה או לחדור עמוק יותר לשירותים מחוברים.
פורסם על ידי סייבר בקצרה