דליפת מפתחות API של Stripe: מאות בתי עסק ו-688 אלף רשומות לקוחות נחשפו

האירוע שפורסם ב-18 באוגוסט 2026 נראה בשלב זה כחשיפה של פרטי גישה השייכים לבתי עסק המשתמשים ב-Stripe — ולא כפריצה מאומתת למערכות הליבה של Stripe. לפי הדיווחים, גורם איום שפעל בכינוי "Satanic" פרסם בחינם ארכיון בנפח של כ-35 ג'יגה-בייט, שכלל 17,654 קבצים מ-659 חשבונות סוחרים ומידע הקשור, לפי הערכה, ל-688,363 לקוחות ב-42 מדינות. מדובר במספרים מדווחים, וחלק מהטענות הרחבות יותר של גורם האיום לא אומתו באופן עצמאי.

איזה מידע נכלל בארכיון?

לפי הדיווחים, החומר כלל רשומות מהתקופה שבין ינואר 2022 ליוני 2026, ובהן:

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

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

החוקרים דיווחו כי מצאו 650 מפתחות סודיים פעילים מסוג sk_live ותשעה מפתחות מוגבלים. מתוך החשבונות שנפגעו, 573 יכלו לקבל תשלומים, 531 יכלו לבצע העברות כספים, ו-519 יכלו לבצע את שתי הפעולות — כך לפי הניתוח שצוטט בדיווחים.

מדוע מפתח פעיל אחד עלול להספיק לנזק משמעותי?

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

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

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

מדוע החוקרים לא הגדירו זאת כפריצה ל-Stripe?

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

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

• הדבקה בתוכנות גניבת מידע במחשבי מפתחים או מנהלי מערכת
• מאגרי קוד ציבוריים והיסטוריית Git
• קובצי .env חשופים והגדרות שרת
• אחסון בענן, גיבויים ושכבות של קונטיינרים
• מערכות CI/CD ויומני GitHub Actions
• שרתים שהוגדרו באופן שגוי או סריקות אוטומטיות לאיתור משתני סביבה חשופים

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

השחרור המקביל והפערים במספרים

חברת Hudson Rock ייחסה לאותו גורם איום שחרור נוסף בפורום. לפי הדיווחים, השחרור כלל 669 תיקיות של ספקים ו-1,033 מפתחות API שנפגעו, בנפח שהוצג כ-33 ג'יגה-בייט; קובץ ההורדה המקושר היה, לפי הדיווח, קטן יותר. גורם האיום טען גם כי ברשותו כ-20,000 מפתחות API נוספים של Stripe, ורמז כי עשויות להתפרסם קבוצות מידע נוספות.

אין לחבר את כל הנתונים האלה לסך מאומת אחד. ההבדלים בין 659 חשבונות סוחרים, 669 תיקיות ספקים ו-1,033 מפתחות עשויים לנבוע ממאגרי מידע שונים, ממספר מפתחות לכל חשבון או משיטות ספירה שונות. המספר של 20,000 מפתחות הוא עדיין טענה לא מאומתת של גורם האיום.

באילו מדינות נמצאו רוב בתי העסק?

המדינות שהובילו בהתפלגות שפורסמה היו:

• ארצות הברית: 212 בתי עסק
• בריטניה: 81
• צרפת: 57
• קנדה: 38
• ברזיל: 30
• אוסטרליה: 27

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

מה בתי עסק המשתמשים ב-Stripe צריכים לעשות עכשיו?

1. לבטל ולהחליף מפתחות סודיים חיים

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

2. לבדוק פעילות API ופעולות תשלום

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

3. לאמת את הגדרות העברות הכספים

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

4. להחליף הרשאות רחבות במפתחות מוגבלים

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

5. לחפש סודות בכל מקום שבו הם עלולים להישאר

יש לסרוק מאגרים נוכחיים והיסטוריים, היסטוריית Git, פלט של מערכות CI/CD, יומני GitHub Actions, קובצי .env, שכבות קונטיינר, אחסון בענן, תיעוד וגיבויים לאיתור ערכים מסוג sk_live. כל מפתח שיימצא צריך להיות מבוטל ומוחלף — גם אם אינו מופיע עוד בגרסה הנוכחית של הקוד.

6. להתייחס לסריקה של GitHub כשכבת הגנה אחת בלבד

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

הלקח המרכזי לסוחרים

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