גוגל סימנה 'תפיסה יפה' – ואז סירבה לשלם על פרצת אבטחה חמורה שנותרה ללא תיקון

פרצת אבטחה קריטית ב-Config Connector של גוגל (Google Cloud) הפכה למוקד מחלוקת הולכת וגוברת סביב מדיניות תגמולי הבאגים (Bug Bounty) של החברה. חוקר האבטחה ג'סטין אולירי (Justin O'Leary) גילה את הפרצה, שדורגה בחומרה מקסימלית (CVSS 10.0), ודיווח עליה לצוות תגמולי הבאגים של גוגל. הצוות קיבל תחילה את הדיווח, סימן אותו כעדיפות גבוהה, ושיבח את אולירי ב-'תפיסה יפה!' (Nice catch!) . לאחר מכן, גוגל שינתה את עמדתה, קבעה שההתנהגות 'פועלת כמתוכנן' (working as intended), סירבה לשלם תגמול, והשאירה את הפרצה ללא תיקון במשך קרוב לשלושה חודשים . המקרה העלה שאלות לגבי מחויבותה של גוגל למחקר אבטחה, במיוחד על רקע ארגון מחדש של תוכניות התגמולים שלה, תוך ציטוט של גל דיווחים מבוססי בינה מלאכותית .

איך Config Connector עובד ואיפה הוא נשבר

Config Connector הוא אופרטור (operator) של Kubernetes המאפשר לארגונים לנהל משאבי GCP – כמו אחסון ענן, מסדי נתונים ומדיניות IAM (Identity and Access Management) – באמצעות פקודות Kubernetes . הוא נועד לאחד כלים: ניתן ליצור, לעדכן ולמחוק משאבי ענן באמצעות kubectl, כלי שורת הפקודה המוכר של Kubernetes .

אולירי גילה שלגישה המאוחדת הזו יש תופעת לוואי מסוכנת. הפרצה מאפשרת לכל משתמש ב-namespace של Kubernetes לעקוף את בקרות ה-IAM של Google Cloud Platform. מפתח עם גישה בסיסית ל-namespace בודד של Kubernetes יכול לנצל זאת כדי להשיג שליטה מלאה (administrative) על סביבת ה-GCP של ארגון שלם – כלומר, להשתלט על כל חשבון הענן . אולירי אמר ל-The Register שניתן לבצע את הניצול בכחמש שניות, ללא השארת עקבות ביקורת (audit trail) .

המנגנון הטכני: הסלמת הרשאות בין Namespaces

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

באשכול GKE (Google Kubernetes Engine) מרובה-דיירים (multi-tenant) המוגדר כראוי, namespaces שונים אמורים להיות מבודדים – משתמש ב-namespace A לא אמור להיות מסוגל לנהל משאבים ב-namespace B או להעניק לעצמו תפקידי GCP מוגברים. התגלית של אולירי מראה שסוגי המשאבים IAM של Config Connector אינם אוכפים את גבולות ה-namespace הללו . על ידי יצירה או שינוי של משאב מדיניות IAM דרך Config Connector מתוך namespace יחיד, משתמש עם הרשאות Kubernetes מינימליות יכול להעניק לעצמו את התפקיד roles/owner בפרויקט GCP – או בארגון כולו .

זוהי הפרה של עקרון ההרשאות המינימליות (principle of least privilege) ועקיפה ישירה של שכבת ההרשאות של GCP (IAM). לא מדובר בתצורה שגויה שמנהל יכול לתקן; מדובר בפגם ברמת התכנון (design-level flaw) באופן שבו Config Connector מאציל סמכויות IAM .

ציר הזמן: מ'תפיסה יפה!' ל'פועל כמתוכנן'

לפי דיווח בלעדי של The Register מיום 18 ביוני 2026 ומקורות תומכים, ציר הזמן התפתח כך:

• סוף מרץ / תחילת אפריל 2026 (בערך): אולירי מגלה את הפרצה ומגיש דוח מפורט לתוכנית תגמולי הבאגים של גוגל קלאוד (Cloud VRP). הדוח כולל הוכחת היתכנות (PoC) המדגימה כיצד תוקף יכול להסלים ממשתמש namespace לבעלים של ארגון GCP .
• טריאז' ראשוני: צוות תגמולי הבאגים של גוגל בודק את הדיווח, מקטלג אותו כבעל עדיפות גבוהה וחומרה גבוהה, ונציג גוגל משיב אישית במילים 'תפיסה יפה!' .
• ~מאי/יוני 2026: מבלי לפרסם תיקון, גוגל משנה את החלטתה. החברה סוגרת את הדיווח, וקובעת שההתנהגות 'פועלת כמתוכנן' – כלומר, היא אינה עומדת בהגדרות הפגיעות על פי כללי Cloud VRP. לא מונפק תגמול .
• נכון ל-18 ביוני 2026: הפרצה נותרת ללא תיקון. עם זאת, דוח הבאג של אולירי עדיין מסומן כ'עדיפות גבוהה' (high-priority) ו'מקובל' (accepted) במערכת המעקב של גוגל – סתירה לכאורה . המקרה פתוח כבר קרוב לשלושה חודשים .

למה גוגל אולי סירבה לתגמול

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

הכללים הרשמיים של Cloud VRP קובעים: "דוחות פגיעות של Google Cloud שבהם נבדקו משאבים שבבעלות הלקוח אינם זכאים לתגמולים." היקף התוכנית מוגבל במפורש לפגיעות בתשתיות ובשירותים שבבעלות גוגל, ולא ברכיבים שניתנים להגדרה על ידי הלקוח . אם גוגל ראתה בהתנהגות Config Connector עניין של תצורת לקוח ולא פגיעות מוצר, היא יכלה לסרב טכנית לתגמול תחת לשון זו – גם אם ההתנהגות עוקפת בקרות IAM מצופות.

אפשרות נוספת: כללי Cloud VRP קובעים שהתוכנית מכסה "ליקויי אימות או הרשאה" בפריטים שבתחומה, מה שאמור לכסות את הממצא של אולירי . אבל גוגל טענה בעבר בהקשרים אחרים שהסלמות הרשאות מסוימות אינן באגים אם הן דורשות הרשאות ספציפיות כדי להפעיל אותן – עמדה שספגה ביקורת מצד חוקרים . במקרה של אולירי, ההרשאה הראשונית הנדרשת (גישה ברמת namespace למשאבי Config Connector) היא מינימלית ומוענקת בדרך כלל למפתחים, מה שהופך את ההסלמה לאמיתית ומסוכנת כאחד .

גורם שלישי קשור לארגון מחדש של תוכניות תגמולי הבאגים לשנת 2026 של גוגל עבור Chrome ואנדרואיד. בסוף אפריל ותחילת מאי 2026, גוגל הודיעה שהיא קוצצת תשלומי Chrome ומבצעת ארגון מחדש של תגמולים, תוך ציטוט של גל דיווחים באיכות נמוכה שנוצרו על ידי בינה מלאכותית . החברה הצהירה שהיא "מפחיתה חלק מסכומי התגמולים והבונוסים ברחבי אנדרואיד ו-Chrome" כדי להתמקד ב*"איכות והשפעה בעולם האמיתי על פני כמויות גרידא"* . בעוד שהמקרה של אולירי נופל תחת Cloud VRP הנפרד, ולא תחת תוכניות Chrome או אנדרואיד, העמדה הפומבית של החברה לגבי הידוק התשלומים עשויה הייתה להשפיע על ההחלטה – במיוחד אם גוגל ראתה בסוגיית Config Connector בחירה עיצובית ולא באג .

תגובת נגד גוברת מצד חוקרים

התקרית עוררה ביקורת מצד קהילת חוקרי האבטחה, כאשר חלקם טוענים שגוגל משתמשת בנרטיב הדיווחים מבוססי הבינה המלאכותית ככיסוי לשלילת תגמולים לגיטימיים שהתגלו באופן ידני . פרשנות של PC Perspective כינתה את ההחלטה "להיות קמצנים לגבי תגמולי באגים" וציינה את הפער בין השבח הראשוני של גוגל לסירוב הסופי . Cyber News Live הדגיש שהפרצה עלולה לאפשר השתלטות בת חמש שניות ללא השארת עקבות .

המקרה מתרחש גם בתקופה שבה גוגל במקביל מגדילה תגמולים עליונים עבור קטגוריות מסוימות של באגי אנדרואיד – עד 1.5 מיליון דולר עבור ניצול Titan M zero-click מתמשך . גישה דו-כיוונית זו – תגמול נדיב על ניצולי חומרה עמוקים תוך סירוב אפילו להכרה בהסלמת הרשאות ענן חמורה – הזינה תפיסות לפיהן תוכניות תגמולי הבאגים של גוגל מקצות משאבים באופן אסטרטגי ולא מעריכות סיכונים בכנות .

מה זה אומר עבור ארגונים המשתמשים ב-Config Connector

ארגונים המפעילים Config Connector באשכולות GKE מרובי-דיירים או משותפים צריכים להתייחס לכך כאל סיכון דחוף שלא תוקן. ללא תיקון רשמי מגוגל, ניתן להפחית את החשיפה באמצעים הבאים:

• הגבל יצירת משאבי iam* ברמת ה-namespace באמצעות מדיניות Kubernetes RBAC. אל תעניק הרשאות create, update או Delete על משאבים מותאמים אישית (Custom Resources) מסוג IAMPolicy, IAMPolicyMember או IAMPartialPolicy ל-namespaces לא מהימנים.
• השתמש ב-Config Connector במצב namespace עם חשבונות שירות (service accounts) נפרדים ובעלי הרשאות נמוכות לכל namespace. תיעוד גוגל תומך בתצורה זו, המגבילה את רדיוס הפיצוץ .
• נטר שינויים ב-IAM של GCP שמקורם ב-Config Connector. אפשר יומני ביקורת (audit logs) והגדר התראות עבור כל קריאות setIamPolicy שמקורן באשכול GKE שלך.
• שקול להשבית את Config Connector בסביבות שבהן נדרש בידוד מרובה-דיירים, עד שגוגל תפתור את הפגיעות.

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

נקודות עיקריות

• פרצת הסלמת הרשאות ב-Config Connector של גוגל (CVSS 10.0) מאפשרת לכל משתמש ב-namespace של Kubernetes להשיג בעלות מלאה על פרויקט GCP.
• צוות תגמולי הבאגים של גוגל קיבל תחילה את הדיווח כעדיפות גבוהה, ואז התהפך, קבע שההתנהגות 'פועלת כמתוכנן' וסירב לתגמול.
• קרוב לשלושה חודשים לאחר הדיווח הראשוני, הפגיעות נותרת ללא תיקון וללא לוח זמנים לתיקון מגוגל.
• האירוע מתרחש על רקע השינויים הרחבים יותר בתוכניות התגמולים של גוגל לשנת 2026, שקיצצו תשלומי Chrome תוך העלאת תגמולי אנדרואיד, מהלך שמסבך את יחסי החברה עם חוקרי אבטחה.