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

מה קרה

CISA הוסיפה ל-KEV catalog שתי פגיעויות RCE ב-PHP המכונות PHP2Shell, לאחר שאישרה ניצול פעיל בשטח.

הפגיעות CVE-2026-109618 היא בעיית out-of-memory corruption (CVSS 9.8) והפגיעות CVE-2026-109619 היא פגם stale internal request-state (CVSS 8.1). שתיהן מאפשרות RCE ללא הזדהות. החוקר עאדל כרימי (Adel Karimi) זיהה RCE מוצלח במלכודות דבש ב-24 באוקטובר 2026, כולל חשיפת זיכרון שמישה בשרשרת האקספלויט. התיקונים שוחררו ב-21 באוקטובר 2026 ב-PHP 8.5.12, 8.4.27, 8.3.36 ו-8.2.35.

מי מושפע

כל סביבת PHP חשופה לאינטרנט שעדיין רצה על גרסאות שקדמו לתיקונים של 21 באוקטובר. Censys מעריכה שיותר מ-32.51 מיליון שירותי PHP נותרים על builds מושפעים.

סוכנויות אזרחיות פדרליות בארה"ב כפופות למועד יעד מחייב של 29 באוקטובר 2026 במסגרת הוראה תפעולית מחייבת. ספקים רבים (אקוסיסטמות WordPress, Drupal, Craft CMS, ומכשירי enterprise של F5, Citrix, Siemens ואחרים) פרסמו advisories מדורגים משום שהם משווקים PHP או תלויים בו.

למה זה חשוב

פגיעות RCE ללא הזדהות בשפה שמניעה בערך 70 אחוז מהאתרים יוצרת סיכון מיידי לחדירה המונית. ציוני EPSS עומדים על 100 אחוז בשתי ה-CVEs, ופגיעות אמיתיות במלכודות דבש כבר מוכיחות shells שמישים.

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

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

עדכנו מיד ל-PHP 8.5.12, 8.4.27, 8.3.36 או 8.2.35 (או ל-rebuilds המקבילים ב-Windows). אם עדכון לא אפשרי בטווח הקצר, בודדו תהליכי PHP, השביתו מודולים מיותרים, הציבו מאחורי WAF שיכול לחסום תבניות אקספלויט מוכרות, ונטרו הפעלות תהליכים חריגות או ארטיפקטים של חשיפת זיכרון. לאחר התיקון, בצעו רוטציה לכל פרטי הזדהות שניתן להגיע אליהם מתוך מארח ה-PHP.

מה קרה

Wiz Research חשפה קמפיין שכינתה Gheist, שמנצל personal access tokens גנובים של GitHub כדי לשתול workflows זדוניים של Actions במאגרים פרטיים ולבצע הוצאת נתונים (exfiltration) של הסודות שלהם.

הכלי סורק כל repo שה-token מגיע אליו, יוצר branch בשם ci-sync- בתוספת תווים אקראיים, מבצע commit ל-workflow שמקודד secrets ב-base32 כדי לעקוף את ה-log masking של GitHub, מדפיס אותם, מוריד את ה-log דרך ה-API, ואז מוחק את ה-run תוך שניות. אותרו יותר מ-13,500 branches שנשתלו ביותר מ-850 חשבונות שנפרצו. וריאנט מאוחר יותר מכוון גם ל-runners self-hosted.

מי מושפע

ארגונים שבהם נגנבו tokens של GitHub ממפתחים או מחשבונות אוטומציה, וששומרים secrets (במיוחד פרטי הזדהות production בהיקף environment) במאגרים פרטיים או ב-GitHub Enterprise Server.

מאגרים ציבוריים מוגנים במידה רבה על ידי שער האישור המחייב של GitHub ל-workflows בפעם הראשונה, אך מאגרים פרטיים ו-GHES אינם. חשבונות cloud בהמשך השרשרת (AWS Secrets Manager נצפה) ניתנים להגעה ברגע שגונבים את ה-secrets.

למה זה חשוב

secrets במאגרים פרטיים הם לעתים קרובות פרטי הזדהות production לטווח ארוך. מכיוון שהוצאת הנתונים מתבצעת כולה דרך ה-API של GitHub עצמו, בקרות egress רשת מסורתיות ורשימות חסימת דומיינים לעולם לא רואות את התעבורה.

אותם חשבונות גנובים ממוחזרים על ידי גורמים אחרים לפיתיונות שינוי שם של repo ולפיתיון RDP-runner, מה שמעיד על שוק משני פעיל ל-tokens.

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

חפשו ב-audit logs של GitHub את ה-user-agent gheist ואת workflow runs על branches מסוג ci-sync-*; חפשו גם ב-audit logs של cloud (למשל AWS CloudTrail) אחר OIDC role assumptions שבהם ה-subject מכיל ci-sync-. בטלו כל token שנחשף, בצעו רוטציה לכל ה-secrets ברמת repository, organization ו-environment שהמאגרים המושפעים יכלו להגיע אליהם, אכפו tokens מסוג fine-grained קצרי חיים או OIDC בכל מקום אפשרי, ודרשו אישור ל-workflow runs גם במאגרים פרטיים אם התוכנית שלכם מאפשרת זאת.

מה קרה

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

הפעילות פעילה לפחות מיולי 2025 וממשיכה את ה-playbook של Operation SyncHole הקודמת. התוקפים שולחים קישורי spear-phishing מותאמים לאתרי פורטפוליו או קורות חיים מזויפים, ואז מנצלים את תוכנת האבטחה הפיננסית החובה Initech INISAFE CrossWeb EX (וקודם לכן iniLINE Cross EX) כדי להשיג הרצת קוד. שרשרת הנוזקה משלבת כעת אלגוריתמים קריפטוגרפיים פוסט-קוונטיים להגנה על ה-command-and-control ועל ה-payload.

מי מושפע

ארגונים ויחידים בדרום קוריאה שמחויבים להריץ את רכיבי אבטחת הדפדפן CrossWeb EX / Cross EX, שנכפו על ידי הממשלה, כדי לגשת לבנקאות מקוונת ולשירותים ציבוריים. עד כה אושרו לפחות שלושה ארגונים קורבנות בענפים שצוינו; פעילות היסטורית של Lazarus נגד אותה תוכנה מצביעה על סיכון רחב יותר בענפי הפיננסים, ה-IT, המוליכים למחצה והתקשורת.

למה זה חשוב

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

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

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

החזיקו את INISAFE CrossWeb EX וסוכני האבטחה הפיננסית הקוריאניים הקשורים מעודכנים במלואם, ובמקומות שבהם המדיניות מאפשרת הריצו אותם רק בפרופילי דפדפן מבודדים או ב-VM. התייחסו ל-spear-phishing שמזכיר קורות חיים או פורטפוליו כסיכון גבוה, אכפו allow-listing של אפליקציות בקצה, נטרו תהליכי-בן חריגים של SyncHost.exe או רכיבי CrossWeb, ופצלו את הרשת כך שתחנת קצה שנפרצה לא תוכל להגיע מיד לשרתי ה-crown-jewel.

מה קרה

שער ה-AI בקוד פתוח LiteLLM ספג חדירה בשרשרת האספקה אחרי שמפתח master פנימי, שנשמר בטעות ב-commit במאי, מעולם לא בוטלה לו התוקף. תוקף ניצל את המפתח שעדיין היה בתוקף כדי להשיג טוקן GitHub עם שליטה על כל מאגרי LiteLLM, ואז פרסם ב-PyPI גרסת חבילה זדונית 1.107.0.

הגרסה שהכילה את הדלת האחורית כללה נוזקה לשליפת פרטי הזדהות שהורצה בכל עליית Python, גם אם LiteLLM עצמו מעולם לא יובא. החבילה נשארה זמינה כשעתיים והורדה בערך 49,000 פעמים. פרטי הזדהות ענן שנגנבו אומתו מול שירותי AI של AWS בתוך שעות, בתבנית LLMjacking קלאסית. זהו אירוע שרשרת האספקה השני של LiteLLM ב-2026.

מי מושפע

כל מפתח, מערכת CI או סביבת ייצור שהתקינה ב-pip את LiteLLM 1.107.0 בזמן שהחבילה הזדונית הייתה זמינה. עשרות אלפי הורדות מצביעות על רדיוס פגיעה רחב בצוותי הנדסת AI ובכל שירות downstream שמושך את הספרייה אוטומטית.

למה זה חשוב

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

שורש הבעיה (מפתח חשוף שנשאר ללא ביטול במשך חודשים) הוא כשל תהליכי שרבים מפרויקטי הקוד הפתוח חולקים.

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

אם גרסה 1.107.0 הותקנה אי פעם על מארח שמחובר לאינטרנט, הניחו שכל פרטי ההזדהות הנגישים מאותו מארח נפרצו: בצעו רוטציה לכל מפתח API, מפתח גישה לענן וסיסמה, בטלו טוקנים של GitHub ושל רישום החבילות, ובדקו את חיוב הענן לשימוש AI או מחשוב חריג. הצמידו תלויות ל-hash-ים ידועים כתקינים, הפעילו אימות דו-שלבי ופרטי הזדהות קצרי-חיים לפרסום, וסרקו מאגרים באופן רציף לאיתור סודות שנשמרו בטעות ב-commit. LiteLLM עצמה מבצעת רוטציה לטוקנים הפנימיים שלה.

מה קרה

חוקר Kaspersky הדגים שרשרת פגיעויות מהעולם האמיתי, שזכתה להכרה ב-Russian Pentest Award 2026, ששוברת את בידוד ה-tenant בסביבת Kubernetes מנוהלת בענן.

החל מנקודת אחיזה בתוך worker node, השרשרת בורחת מה-node, מנצלת לרעה את Konnectivity (פרוקסי ה-control-plane), מבצעת הסלמת הרשאות על ה-host, ובסופו של דבר מגיעה לשירותים של tenants אחרים דרך רשת ה-overlay. התוצאה היא הרצת קוד מרחוק וחדירה ל-tenants אחרים.

מי מושפע

לקוחות של שירותי Kubernetes מנוהלים שחולקים תשתית בסיסית ומסתמכים על Konnectivity ועל מודל רשת overlay ברירת המחדל לצורך בידוד. פרטי ספק הענן והגרסה המדויקים מוסתרים בפרסום הציבורי, אך כל הצעת K8s multi-tenant עם ארכיטקטורה דומה נמצאת בטווח סיכון מקביל.

למה זה חשוב

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

מפעילי פלטפורמות multi-tenant והלקוחות שלהם צריכים להבין ש"מנוהל" לא שווה אוטומטית ל"מבודד היטב".

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

החילו את התיקונים האחרונים על רכיבי Kubernetes, Konnectivity ותוספי CNI/overlay. אכפו מדיניות רשת מחמירה וסטנדרטים של אבטחת pods שמגבילים egress והסלמת הרשאות, הריצו עומסי עבודה עם capabilities מינימליות, הפעילו זיהוי runtime לתעבורה בלתי צפויה ברמת node או בין namespaces, ושקלו node pools ייעודיים או בידוד חומרה חזק יותר עבור tenants רגישים במיוחד. בקשו מספק הענן שלכם סקירות ארכיטקטורה שמתמקדות ב-Konnectivity ובגבולות האמון של ה-overlay.

מה קרה

Offensive Security שחררה את Kali Linux 2026.3, העדכון השלישי של השנה, שכולל שישה כלים חדשים, שדרוג קרנל מ-6.19 ל-7.1.5, 126 עדכוני חבילות, שיפורים בשולחן העבודה KDE Plasma 6.7, וסקריפטי build מעודכנים לתמונות שתומכים כעת ב-Docker וב-Podman באופן עקבי.

הכלים החדשים הם dalfox (סורק XSS), katana (crawler/spider), qsreplace (מחליף query-string), rustscan (סורק פורטים), sdrangel (ממשק SDR) ו-snaffler-ng (סורק פרטי הזדהות ונתונים רגישים ב-SMB shares).

מי מושפע

בודקי חדירות, צוותי red team, חוקרי אבטחה וסטודנטים שמשתמשים ב-Kali כפלטפורמת הבדיקה העיקרית שלהם, כולל מי שמריץ אותה על Raspberry Pi, מכשירי NetHunter Android או בקונטיינרים.

למה זה חשוב

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

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

מה קרה

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

המחברים משבצים רשתות עצביות מוצפנות שמתפענחות ומופעלות רק כשמסופק trigger סודי. באמצעות digital lockers קריפטוגרפיים, המעגלים המוסתרים נשארים קשים לגילוי או לפירוש גם עם גישת white-box מלאה למשקלים. מימושי proof-of-concept ב-PyTorch עמדו בפני fine-tuning, weight noising, חיפוש trigger מבוסס gradient ו-latent adversarial training, במשימת תגובה כימית ששימשה כ-proxy למיומנויות רלוונטיות ל-CBRN.

מי מושפע

מעבדות AI, מעריכים, רגולטורים וגורמי פריסה במורד השרשרת שמסתמכים על ביקורות יכולות מבוססות elicitation (red-teaming, בדיקות fine-tuning, latent adversarial training) כדי לאשר שלמודלים אין מיומנויות מסוכנות לפני השחרור.

למה זה חשוב

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

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