חוקרי Hacktron נעזרו ב־Claude לחדירה מחקרית ל־OpenAI
לפי מחקר Hacktron, חוקרים נעזרו ב־Claude כדי לגשת לחשבונות עובדים ולמאגר קוד פנימי של OpenAI ביולי 2026. החולשות תוקנו; אין בתחקיר ראיה לגניבת מידע.
חוקרי האבטחה של Hacktron נעזרו ב־Claude בשרשרת פריצה שאפשרה גישה לחשבונות עובדים ולמאגר קוד פנימי של OpenAI, לפי מחקר שקיבל סיקור נרחב ב־18 בספטמבר. החדירה המחקרית התרחשה ב־25 ביולי 2026 והחולשות תוקנו, כך שלא מדובר בפריצה חדשה השבוע. עבור חברות ישראליות המחברות כלי AI לסביבת הפיתוח, החשיפה מציבה שאלה מעשית: אילו פעולות אפשר לבצע דרך חשבון עובד אם הגישה אליו נפרצת?
מה נחשף, ומה כבר תוקן
המחקר של Hacktron פורסם במקור ב־13 בספטמבר. לפי התיאור שנכלל בתחקיר, החוקרים השתמשו ב־Claude, לרבות Opus 5, כחלק משרשרת החדירה. הם הוכיחו את הגישה באמצעות פתיחת בקשת שינוי בקוד דרך Codex, ולדבריהם לא קראו מידע רגיש. אלה פרטים חשובים משום שהם מפרידים בין הוכחת יכולת לפעול בתוך מערכת לבין טענה לגניבת מידע, שאינה מבוססת בתחקיר.
גם משמעותה של בקשת השינוי דורשת דיוק. פתיחת בקשה אינה זהה לאישור השינוי, למיזוגו במאגר או להפעלתו במערכת ייצור. התחקיר אינו קובע שהשלבים האלה התרחשו. עם זאת, עצם היכולת להגיע למאגר פנימי ולפתוח בו בקשה דרך כלי פיתוח ממחישה מדוע הגישה לכלי AI ארגוני עשויה להיות בעלת ערך לתוקף.
סדר הזמנים: החדירה המחקרית בוצעה ב־25 ביולי 2026; המחקר פורסם ב־13 בספטמבר; הסיקור הנרחב הגיע ב־18 בספטמבר. לפי התחקיר, החולשות תוקנו. אין בו בסיס לקבוע שהן עדיין ניתנות לניצול.
ההבחנה הזאת אינה מקטינה את חשיבות הפרסום. היא משנה את השאלה: במקום להתייחס אליו כהתרעה על אירוע פעיל, נכון לבחון אותו כמקרה מבחן לגבולות ההרשאה של מערכות AI מחוברות.
Claude סייע לחוקרים; החיבורים הארגוניים הם לב הסיפור
הכותרת על שימוש ב־Claude כדי לחדור ל־OpenAI מושכת תשומת לב בגלל זהות החברות. אבל זה אינו תיאור של מודל שהחליט בעצמו לתקוף חברה מתחרה. מדובר במחקר שביצעו חוקרים חיצוניים, שהשתמשו במודל במסגרת עבודתם. אין בתחקיר פירוט מספיק כדי לייחס למודל לבדו את גילוי החולשות או את ביצוע כל שלבי השרשרת.
כדאי להפריד בין שני תפקידים: כלי AI המסייע לחוקר לנתח ולבצע משימות, וכלי AI המחובר למערכות הארגון ויכול לפעול בהן. במקרה המתואר, Claude שימש את החוקרים, ואילו Codex שימש להוכחת הגישה באמצעות בקשת שינוי. ערבוב התפקידים עלול ליצור רושם שגוי לגבי מקור החולשה או לגבי אחריותו של מוצר מסוים.
הלקח הרחב הוא ניתוח אבטחתי, לא ממצא נוסף מהמחקר: כשכלי יכול לפעול בשם עובד, גבולות החשבון והחיבורים שלו הופכים לחלק מגבולות האבטחה של הארגון. לכן לא מספיק לשאול אם התשובה שהמודל כתב נכונה. צריך לבדוק גם אילו משאבים זמינים לו, באיזו זהות הוא פועל, ומי מאשר פעולות המשנות מצב.
חשבון AI מחובר צריך להיבחן גם לפי ההרשאות שלו, לא רק לפי איכות התשובות שלו.
המשמעות לצוותי פיתוח ולעסקים בישראל
בחברת תוכנה ישראלית, השאלה המיידית היא לא אם להפסיק להשתמש ב־AI, אלא אם החיבור שלו למערכות החברה קיבל בדיקה מסודרת. דוגמה אפשרית היא צוות קטן המאפשר לעוזר קוד לעבוד על מאגר לצורך תיקון תקלה. הרשאה רחבה יותר מהנדרש עשויה לחשוף גם פרויקטים שאינם קשורים למשימה. זו דוגמה לסיכון תכנוני, ולא תיאור של מה שקרה ב־OpenAI.
ההבחנה חשובה גם לבית תוכנה בארץ שמשרת כמה לקוחות. צריך לברר האם חשבון אחד מאפשר לכלי להגיע לקוד של לקוחות שונים, והאם אפשר להפריד את הגישה לפי פרויקט. האחריות לבדיקה אינה יכולה להישאר רק אצל העובד שחיבר את הכלי: מנהל הפיתוח ואחראי האבטחה צריכים להבין מה אושר ומה אפשר לבטל.
אין בתחקיר ראיה לכך שחשבונות של משתמשים ישראלים נפגעו, או שכל חיבור של ChatGPT או Codex מסוכן באותה מידה. המשמעות המקומית היא תפעולית: ארגון שמאשר לעוזר לבצע משימות צריך להגדיר לו גבולות כמו לכל רכיב אחר בעל גישה לקוד. גם צוות שאין בו איש אבטחה ייעודי יכול להתחיל ממיפוי החשבונות, המאגרים ובעלי האחריות.
מה כדאי לבדוק בחיבורים הקיימים
המקרה אינו מספק רשימת תיקונים טכנית לכל מוצר. הוא כן מצדיק בדיקה של בקרות מוכרות סביב זהויות, הרשאות ושינויי קוד. אלה המלצות כלליות לצמצום סיכון, ולא טענה שבקרות מסוימות נעדרו אצל OpenAI:
- למפות גישה בפועל: אילו חשבונות מחוברים לכלי AI, ולאילו מאגרים ומערכות כל חיבור מגיע.
- לצמצם הרשאות: להפריד בין קריאה, פתיחת בקשת שינוי, מיזוג ופעולות במערכות ייצור.
- לשמור על ביקורת אנושית: בקשה שנפתחה באמצעות כלי AI אינה צריכה לעקוף את כללי בדיקת הקוד.
- לוודא תיעוד: לשמור יכולת לברר באיזו זהות בוצעה פעולה ואיזה חיבור אפשר אותה.
- לבדוק ביטול גישה: לדעת מי יכול לנתק חיבור ומה קורה להרשאות כשעובד מחליף תפקיד או עוזב.
בדיקה מועילה צריכה להסתיים בתשובות קונקרטיות, לא רק במדיניות כתובה. למשל, מי רשאי לאשר חיבור למאגר נוסף, והאם אפשר לזהות פעולה בלתי צפויה ולחסום את הגישה בלי לעצור את כל צוות הפיתוח. המטרה היא לצמצם את היקף הנזק האפשרי אם שכבת הגנה אחת נכשלת.
מה עדיין לא ניתן להסיק מהחשיפה
התחקיר המצורף אינו מפרט את כל חוליות הפריצה, את היקף ההרשאות בכל חשבון או את השינויים הטכניים שבוצעו בעקבות המחקר. לכן אין בסיס לקבוע מכאן שמנגנון מסוים היה הגורם, שמוצר מסוים אינו בטוח לשימוש, או שהאירוע מעיד על פגיעה רחבה בלקוחות. גם ההצהרה שלא נקרא מידע רגיש מיוחסת לחוקרים.
החשיפה כן מספקת המחשה קונקרטית לחיבור בין גישה לחשבון לבין יכולת לפעול בסביבת פיתוח. עבור ארגונים בישראל, הפעולה הסבירה כעת אינה בהכרח החלפת מודל. היא בדיקת ההרשאות שסביבו: איזה קוד הוא יכול לראות, אילו שינויים הוא יכול להציע, ומי מחזיק בהחלטה להפוך הצעה לפעולה מחייבת.
שאלות נפוצות
האם הפריצה המחקרית ל־OpenAI התרחשה בספטמבר 2026?
לא. לפי התחקיר, החדירה המחקרית התרחשה ב־25 ביולי 2026, והחולשות תוקנו. המחקר פורסם ב־13 בספטמבר וקיבל סיקור נרחב ב־18 בספטמבר.
איך Claude ו־Codex היו מעורבים במחקר של Hacktron?
חוקרי Hacktron השתמשו ב־Claude, לרבות Opus 5, במסגרת שרשרת פריצה שאפשרה גישה לחשבונות עובדים ולמאגר קוד פנימי של OpenAI. לפי החוקרים, הם הוכיחו את הגישה באמצעות פתיחת בקשת שינוי בקוד דרך Codex, בלי לקרוא מידע רגיש.
איך מצמצמים סיכון כשמחברים כלי AI לקוד של החברה?
מגבילים את החיבור למאגרים ולהרשאות הנחוצים בלבד, ומפרידים בין קריאת קוד, הצעת שינוי ואישורו. כדאי גם לדרוש ביקורת אנושית לפני מיזוג שינויים, לתעד פעולות ולוודא שאפשר לבטל את הגישה במהירות.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות