InvoiceShelf שחררה תיקון (patch) עבור CVE-2026-55610, פרצה קריטית שאפשרה לכל בעלים (Owner) בחברה אחת להשתלט על חשבונות משתמשים בחברה אחרת. הפגיעות, שקיבלה דירוג של 8.7 בסולם CVSS, נבעה מחוסר בבדיקת שייכות לדייר (tenant-scope check) בקוד ה-Laravel של האפליקציה.

איך הפרצה עבדה

InvoiceShelf היא כלי SaaS הבנוי על Laravel המאפשר לחברות לנהל משתמשים, חשבוניות והגדרות מלוח בקרה (dashboard) יחיד. הפלטפורמה קוראת כותרת (header) מותאמת אישית כדי לזהות דייר (tenant). כאשר בעלים (Owner) מבקש רשומת משתמש, הקוד בודק רק: "האם המבקש הוא בעלים של החברה שלו?"

הוא מעולם אינו מאמת שהמשתמש המבוקש שייך לאותו דייר. מנגנון ה-implicit route-model binding של Laravel פותר את מזהה המשתמש (user ID) לשורה בטבלת המשתמשים הגלובלית, ומדיניות ההרשאה (authorization policy) מאשרת את הבקשה על בסיס תפקיד המבקש בלבד.

תוקף יכול היה, אם כן:

  • לספק כל מזהה משתמש מספרי (numeric user ID) בכתובת ה-URL של הבקשה.
  • לקבל את רשומת המשתמש המלאה, כולל כתובת האימייל.
  • לבצע עדכון שדורס את האימייל והסיסמה של הקורבן, ואפילו להקצות מחדש את החשבון לחברה של התוקף כ-super-admin.

בפועל, בעלים זדוני הפך כלי לניהול חברות לכלי אוניברסלי להשתלטות על חשבונות (account-takeover). לא נדרשו הרשאות מעבר ל-"Owner".

מי מושפע

כל לקוח של InvoiceShelf המריץ גרסה קודמת ל-2.4.1 היה חשוף. מכיוון שהפרצה נמצאת בנתיב הליבה של טיפול בבקשות (request-handling path), כל דייר יכול היה להיות יעד של בעלים מדייר אחר, ללא קשר לגודל או למצב האבטחה שלו. ההשפעה כוללת פגיעה בסודיות (כתובות אימייל) ופגיעה בשלמות הנתונים (שינויי סיסמה לא מורשים, שדרוג ל-super-admin).

התיקון

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

מה מפתחים צריכים ללמוד

  • לעולם אל תסתמכו על מפתחות ראשיים גלובליים (global primary keys) באפליקציות מרובות-דיירים (multi-tenant).
  • הפעילו מסנן דייר (tenant filter) על כל חיפוש במסד הנתונים, ולא רק בפעולות מחיקה או יצירה.
  • הגדירו מדיניות הרשאה (authorization policies) שתאמת גם את תפקיד הפועל (actor) וגם את השייכות של האובייקט המבוקש לדייר (tenancy).
  • התייחסו לתכונות מובנות של ה-framework, כמו route-model binding, ככלי נוחות שעלולים להסתיר פרצות אבטחה, אלא אם כן תוסיפו הגבלה מפורשת (explicit scoping).

מבט לעתיד

האירוע מדגים סיכון רחב יותר עבור כל SaaS המשתמש בטבלאות משותפות. ביקורות אבטחה צריכות לבחון את כל ה-endpoints המקבלים מזהים (identifiers) ולוודא שהגבלת הדייר (tenant scoping) נאכפת באופן אחיד.

בשורה התחתונה: בדיקת דייר אחת חסרה יכולה להפוך תפקיד משתמש בעל הרשאות לדלת אחורית אוניברסלית. הגבלה נכונה (scoping) אינה אופציונלית; היא הבסיס לבידוד נתונים בכל מערכת מרובת-דיירים (multi-tenant).