חדשות סייבר יומיות - 20 בספטמבר 2026

מה קרה

שלושה חוקרים ב-Hacktron השתמשו ב-Claude Opus 5 של Anthropic כדי לשרשר שתי פגיעויות, להשתלט על חשבונות ChatGPT ו-Codex של כמה מעובדי OpenAI, ומשם להגיע למאגר קוד פנימי של OpenAI.

השרשרת התחילה מבאג ב-Discourse, התוכנה שמפעילה את פורום העזרה הציבורי של OpenAI. תמונת HEIC/HEIF שנבנתה במיוחד גרמה ל-heap buffer over-read ב-libheif (CVE-2026-32882, CVSS 7.1), והצוות שילב אותה בעזרת AI לביצוע קוד מרחוק על שרת הפורום. משם ניצלו פגיעות במערכת ה-SSO המשותפת "Sign in with OpenAI" של OpenAI כדי להשתלט על חשבונות עובדים בלי אינטראקציה מצד הקורבן.

זה היה מחקר אבטחה מורשה. הצוות דיווח על הבעיות, הדגים גישה באמצעות pull request תמים תוך פחות מ-72 שעות, ועצר. OpenAI תיקנה את הבעיה בצד ההתחברות כ-14 שעות אחרי הדיווח, ושילמה בונטי של $6,500 ב-1 בספטמבר על הממצא בצד של OpenAI.

מי מושפע

עובדי OpenAI שחשבונות ה-ChatGPT וה-Codex שלהם קושרו דרך ה-SSO של הפורום הציבורי, וכן כל שירות צד ראשון או צד שלישי שמשתמש באותה התחברות OpenAI. סביבות פורום Discourse שמריצות libheif פגיע (גרסאות 1.21.2 וקודמות) ומעבדות העלאות HEIC/HEIF.

בתיאוריה, אותה גישה יכלה להתרחב לשירותים מחוברים כמו GitHub, Slack ודוא"ל, אם כי החוקרים לא המשיכו בכיוון הזה.

למה זה חשוב

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

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

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

עדכנו את libheif לגרסאות חדשות יותר מ-1.21.2 והחילו advisories של Discourse במהירות. התייחסו לספקי זהויות SSO כיעדים בעלי ערך גבוה: אכפו Phishing-resistant MFA, סקרו משכי חיים של tokens והגבלות audience, והגבילו אילו שירותים חיצוניים יכולים להנפיק או לצרוך tokens של זהות עובדים.

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

מה קרה

חוקרי אבטחה ב-Accomplish AI מצאו שתי דרכים לברוח מה-sandbox של OpenAI Codex. הטכניקה החמורה יותר, שנקראת Heapjack, מאפשרת לתוקף להשיג הרצת פקודות מחוץ ל-sandbox על מחשב של מפתח, פשוט כשהקורבן פותח מאגר זדוני ב-Codex ושואל שאלה על הקוד, בלי בקשת אישור ובלי שום דבר גלוי על המסך.

הטכניקה Heapjack מכוונת לרכיב node_repl ש-Codex Desktop כותב לקובץ הגלובלי ~/.codex/config.toml בזמן ההתקנה. גם הקשרים המהימנים וגם הקשרים הלא מהימנים של JavaScript חולקים תהליך Node.js אחד ו-heap זיכרון אחד. קוד לא מהימן מצלם את ה-heap באמצעות v8.getHeapSnapshot(), מבצע brute-force על ה-token האקראי מסוג UUID שמסמן בקשות מהימנות, ואז כותב בקשות מזויפות אל ה-pipe שבו משתמש תהליך האב ה-native שרץ מחוץ ל-sandbox.

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

מי מושפע

משתמשי OpenAI Codex (CLI ואפליקציית Desktop) שפותחים מאגרים לא מהימנים או של צד שלישי. הרשומה node_repl נכתבת גלובלית בלי opt-in, כך שגם משתמשי CLI רגילים יורשים את החשיפה.

כל מחשב מפתח שהריץ Codex במצב sandbox נעול היה נגיש פוטנציאלית דרך מאגר זדוני.

למה זה חשוב

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

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

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

עדכנו את Codex CLI ו-Desktop לגרסאות ש-OpenAI שחררה אחרי הדיווח מ-12 באוגוסט. הימנעו מפתיחת מאגרים לא מהימנים ב-Codex עד שהסוכן והקונפיגורציה שלו מאושרים כמעודכנים.

בדקו את ~/.codex/config.toml לאיתור רשומות לא צפויות כמו node_repl, הריצו את Codex תחת חשבונות עם הרשאות מינימליות או בסביבות מבודדות כשאפשר, ונטרו הפעלות תהליכים יוצאות או כתיבות קבצים לא צפויות שמקורן בתהליכי Node הקשורים ל-Codex.

מה קרה

פגיעות RCE קריטית ללא הזדהות ב-Orkes Conductor, המזוהה כ-CVE-2026-58138 (CVSS 9.8), מנוצלת בפועל בשטח לפי Fortinet ומקורות טלמטריה נוספים.

גרסאות פגיעות (3.21.21 עד לפני 3.30.2) מאפשרות לתוקפים מרוחקים לשלוח להגדרות workflow מוטמעות, דרך נקודת הקצה של ה-workflow API ולפני הזדהות, ביטויי JavaScript או Python זדוניים. מעריכי GraalVM ללא sandbox, שמוגדרים עם HostAccess.ALL או allowAllAccess(true), ניתנים לניצול דרך סוגי המשימות INLINE, LAMBDA, DO_WHILE ו-SWITCH כדי להפעיל פקודות OS שרירותיות באמצעות Java reflection או קריאות subprocess ישירות.

Fortinet חסמה 1,290 ניסיונות תקיפה בתוך 24 שעות בודדות (עלייה יומית של 132%) וכמעט 7,000 ניסיונות בין 2 ל-9 בספטמבר 2026. זיהויים נוספים במלכודות דבש ובמחקר מאשרים ניסיונות ניצול שראשיתם לפחות ביולי 2026.

מי מושפע

ארגונים שמריצים Orkes Conductor בגרסאות 3.21.21 עד לפני 3.30.2, ובמיוחד סביבות שבהן ה-workflow API חשוף לרשתות לא מהימנות והמעריכים נשארו בהגדרות host-access ללא הגבלה.

נפח התקיפות נצפה ממדינות רבות, בהן גרמניה, הונג קונג, אינדונזיה, איחוד האמירויות והודו.

למה זה חשוב

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

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

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

עדכנו מיד ל-Orkes Conductor 3.30.2 ומעלה. אם לא ניתן להחיל תיקון מיד, הגבילו גישה חיצונית לנקודות הקצה של ה-workflow API, הציבו את Conductor מאחורי בקרות גישה רשתיות חזקות, ובטלו או שימו ב-sandbox הדוק את מעריכי GraalVM (הימנעו מ-HostAccess.ALL / allowAllAccess(true)).

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

מה קרה

CISA הוסיפה שלוש פגיעויות בקרנל של Linux לקטלוג Known Exploited Vulnerabilities (KEV) שלה בסביבות 18 בספטמבר 2026, תוך ציון ראיות לניצול בפועל. גם Red Hat עדכנה את ה-advisories שלה וקבעה שהפגיעויות בסיכון גבוה ועם אקספלויטים ציבוריים ידועים.

הפגיעויות הן: CVE-2025-39682 (CVSS 9.8) - בדיקה לא תקינה של תנאים חריגים בנתיב הקבלה של TLS, שמאפשרת חשיפת זיכרון מקומית או מניעת שירות; CVE-2026-53266 (CVSS 8.8) - כתיבה מחוץ לגבולות בנתיב שכתוב SNAT ARP של ebtables, שעלולה להוביל ל-DoS או להסלמת הרשאות מקומית; ו-CVE-2025-39964 (CVSS 7.8) - race condition שמאפשרת כתיבות מקבילות לאותו AF_ALG socket, עם סיכון לקריסות או לשיבוש תוצאות קריפטוגרפיות.

עדיין אין פרטים ציבוריים שמתארים את שיטת הניצול המדויקת או האם שלוש הפגיעויות משורשרות יחד. סוכנויות פדרליות כפופות למועד יעד לתיקון לפי BOD 26-04 ב-21 בספטמבר 2026.

מי מושפע

מערכות Linux שמריצות קרנלים שכוללים את נתיבי הקוד הפגיעים של TLS, netfilter/bridge ebtables או AF_ALG. משתמשים מקומיים מאומתים או תהליכים יכולים להפעיל את הפגיעויות.

סוכנויות Federal Civilian Executive Branch נמצאות תחת לחץ הנחיה מפורש; ציי Linux ארגוניים ובענן בכלל צריכים להתייחס להוספה ל-KEV כאות תעדוף.

למה זה חשוב

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

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

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

החילו עדכוני קרנל מהספק שמטפלים ב-CVE-2025-39682, CVE-2026-53266 ו-CVE-2025-39964 ברגע שהם זמינים מההפצה שלכם. תעדפו מערכות שמאפשרות הרצת קוד מקומי לא מהימן או עומסי multi-tenant.

כש-reboot מיידי קשה, השתמשו בשירותי live-patching אם הספק מציע אותם, הגבילו הרשאות משתמש מקומי, ונטרו פעילות חריגה ב-TLS, netfilter או AF_ALG. סוכנויות פדרליות חייבות לעמוד במועד היעד של BOD ב-21 בספטמבר 2026.

מה קרה

תוקף השתמש בחשבון GitHub שנפרץ של עובד CrowdSec שעזב לאחרונה, כדי להעתיק ב-22 במאי כ-170 מאגרים פרטיים של החברה. המחשב הנייד של העובד נדבק בגרסאות זדוניות של חבילות npm של TanStack שפורסמו ב-11 במאי (מזוהות כ-CVE-2026-45321, CVSS 9.6, אושרו כמנוצלות בפועל ושימשו בקמפיינים של כופרה).

החבילות הזדוניות גנבו פרטי הזדהות כולל GitHub tokens. CrowdSec השאירה את גישת ה-GitHub של העובד לשעבר פתוחה כדי שיוכל לסיים עבודה. הארכיון שהועתק הופיע מאוחר יותר בפורום מקוון ב-16 בספטמבר, וכלל קוד מקור לצד כתובות אימייל של 83 משתמשים ופרטים על 51 משקיעים פוטנציאליים מ-2020.

CrowdSec מציינת שהחשבון שימש רק להעתקת קוד, לא בוצעה גישה לתשתיות ולמסדי נתונים, ושום קוד לא שונה. אותה מתקפת שרשרת אספקה ב-TanStack פגעה גם במכשירים ב-Mistral AI וב-OpenAI.

מי מושפע

CrowdSec (מאגרים פרטיים, אימיילים של משתמשים ונתוני משקיעים ישנים), וכן כל ארגון שמפתחיו התקינו את 84 הגרסאות הזדוניות מתוך 42 חבילות @tanstack/*. OpenAI ו-Mistral AI ציינו בפומבי שמכשירי עובדים נפגעו.

מפתחים שהחזיקו חבילות TanStack בעץ התלויות שלהם בחלון של 11 במאי, וששמרו GitHub tokens ארוכי טווח או סודות אחרים על הדיסק.

למה זה חשוב

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

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

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

בטלו מיד את כל הגישות של עובדים עוזבים, כולל חברות בארגון GitHub ו-OAuth tokens, כחלק מצ'קליסט offboarding באותו היום. בצעו רוטציה לכל token או מפתח שעשויים היו להיות על מכונות מפתחים.

הצמידו תלויות npm לגרסאות ספציפיות ואמתו אותן, השתמשו ב-lockfiles ובדיקות שלמות חבילות, העדיפו פרטי הזדהות קצרי טווח ואימות GitHub מבוסס חומרה, סרקו endpoints של מפתחים אחרי אירועי שרשרת אספקה ידועים, ונטרו שכפולי מאגרים בלתי צפויים או deploy keys חדשים. שדרגו מכל גרסת TanStack שפורסמה בחלון הזדוני והתייחסו ל-CVE-2026-45321 כמנוצלת בפועל.

מה קרה

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

Microsoft הוציאה תיקונים ל-974 CVEs בחודש אחד לאחרונה, שיא חדש. Oracle שיחררה 1,448 תיקונים ביולי לעומת 309 ביולי הקודם. שני השחרורים הגדולים של Chrome ביוני תיקנו 1,072 פגיעויות, יותר מ-23 השחרורים הגדולים הקודמים יחד. Mozilla מצאה 271 באגים ב-Firefox בספרינט אחד באמצעות מודל Mythos של Anthropic. ספירת ה-CVE הכוללת הוכפלה בקירוב משנה לשנה לפי מעקב של Empirical Security / cve.icu (מעל 66,000 שנרשמו עד אמצע ספטמבר, לעומת כ-33,500 באותה נקודה בשנה הקודמת).

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

מי מושפע

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

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

למה זה חשוב

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

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

מה קרה

קבוצת הסחיטה ShinyHunters פרצה לאתר דליפת הנתונים ב-Tor של מבצע הכופרה Clop (Cl0p), השחיתה אותו, וטוענת שגנבה נתוני שרת כולל קוד מקור, תוספי Grav CMS, לוגי מערכת והמפתחות הפרטיים של שירות ה-onion של Clop.

החדירה החלה בפגיעות העלאת קבצים ללא אימות ב-Grav CMS, כפי שתיארו ShinyHunters. תחילה העלו קובץ טקסט מתגרה, ואז החליפו לחלוטין את תוכן האתר ב-ASCII art של לוגו Umbreon שלהם ובהודעה. BleepingComputer אישרה שגם הקובץ שהועלה וגם ההשחתה שבאה אחריו הוגשו מתשתית Clop.

ShinyHunters טוענת שהחזקה במפתחות הפרטיים של ה-onion מאפשרת לה להמשיך לשלוט בשירות או להתחזות אליו גם אם Clop ינסה להשיב לעצמו את השרת המקורי.

מי מושפע

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

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

למה זה חשוב

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

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

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

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

לכל CMS הפונה לציבור (כולל כאלה שבשימוש פנימי), ודאו שפונקציונליות העלאת קבצים דורשת אימות, מאמתת סוגי תוכן ושומרת העלאות מחוץ ל-web root. החילו עדכוני Grav CMS במהירות ובדדו שירותים באירוח Tor עם הרשאות מינימליות.