InvoiceShelf ने CVE-2026-55610 साठी एक पॅच जारी केला आहे, ही एक गंभीर त्रुटी आहे ज्यामुळे एका कंपनीतील कोणताही मालक (Owner) दुसऱ्या कंपनीतील वापरकर्त्यांचे (user) खाते हॅक करू शकतो. CVSS स्केलवर ८.७ रेटिंग असलेली ही असुरक्षितता ॲपच्या Laravel कोडमधील 'tenant-scope check' च्या अभावामुळे निर्माण झाली होती.

ही त्रुटी कशी काम करत होती

InvoiceShelf हे Laravel वर आधारित एक SaaS टूल आहे जे कंपन्यांना एकाच डॅशबोर्डवरून वापरकर्ते, इनव्हॉइस आणि सेटिंग्ज व्यवस्थापित करण्यास अनुमती देते. प्लॅटफॉर्म टेनंटची ओळख पटवण्यासाठी एक कस्टम हेडर वाचते. जेव्हा एखादा Owner वापरकर्त्याच्या रेकॉर्डची विनंती करतो, तेव्हा कोड फक्त एवढेच तपासतो की, “विनंती करणारा त्यांच्या स्वतःच्या कंपनीचा मालक आहे का?”

तो लक्ष्यित वापरकर्ता (target user) त्याच टेनंटचा आहे की नाही, याची पडताळणी तो कधीच करत नाही. Laravel चे implicit route-model binding वापरकर्ता ID ला ग्लोबल users टेबलमधील एका रो (row) शी जोडते आणि ऑथोरायझेशन पॉलिसी केवळ विनंती करणाऱ्याच्या भूमिकेवर (role) आधारित विनंती मंजूर करते.

त्यामुळे एखादा अटॅकर (attacker):

  • विनंतीच्या URL मध्ये कोणताही न्यूमेरिक युजर ID देऊ शकतो.
  • ईमेलसह वापरकर्त्याचा संपूर्ण रेकॉर्ड प्राप्त करू शकतो.
  • अपडेट जारी करून पीडित वापरकर्त्याचा ईमेल, पासवर्ड बदलू शकतो आणि अगदी त्या खात्याला अटॅकरच्या कंपनीमध्ये super-admin म्हणून पुन्हा नियुक्त करू शकतो.

प्रत्यक्ष व्यवहारात, एका दुर्भावनापूर्ण मालकाने (malicious Owner) कंपनी-व्यवस्थापन साधनाचे रूपांतर युनिव्हर्सल अकाऊंट-टेकओव्हर शस्त्रात केले. यासाठी “Owner” व्यतिरिक्त इतर कोणत्याही विशेषाधिकारांची (privileges) गरज नव्हती.

कोणावर परिणाम झाला आहे

२.४.१ पूर्वीची आवृत्ती वापरणारा प्रत्येक InvoiceShelf ग्राहक याला असुरक्षित होता. ही त्रुटी मुख्य request-handling path मध्ये असल्याने, कंपनीचा आकार किंवा सुरक्षा स्थिती काहीही असो, कोणत्याही टेनंटला दुसऱ्या टेनंटच्या Owner द्वारे लक्ष्य केले जाऊ शकत होते. याचे परिणाम गोपनीयता गमावणे (ईमेल पत्ते) आणि अखंडता गमावणे (अनधिकृत पासवर्ड बदलणे, super-admin पदावर बढती मिळवणे) यामध्ये आहेत.

पॅच (The Patch)

डेव्हलपर्सनी आवृत्ती २.४.१ जारी केली आहे, ज्यामध्ये वापरकर्ता रेकॉर्डवरील कोणत्याही read किंवा write ऑपरेशनपूर्वी स्पष्ट tenant check जोडले आहे. ही सुधारणा क्वेरीला सक्रिय कंपनी आयडेंटिफायरपर्यंत मर्यादित करते, ज्यामुळे Laravel केवळ विनंती करणाऱ्याच्या टेनंटशी संबंधित रो (rows) परत करण्यास भाग पडते.

डेव्हलपर्सनी काय शिकावे

  • मल्टी-टेनंट ॲप्लिकेशन्समध्ये कधीही ग्लोबल प्रायमरी कीजवर (global primary keys) अवलंबून राहू नका.
  • केवळ delete किंवा create कृतींवरच नाही, तर प्रत्येक डेटाबेस लूकअपवर tenant filter लागू करा.
  • ऑथोरायझेशन पॉलिसीजद्वारे कृती करणाऱ्याची भूमिका आणि लक्ष्यित ऑब्जेक्टची टेनन्सी (tenancy) या दोन्हीची पडताळणी करा.
  • route-model binding सारख्या implicit framework features ला केवळ सोयी म्हणून पाहू नका, कारण जोपर्यंत तुम्ही स्पष्ट scoping जोडत नाही, तोपर्यंत ते सुरक्षा त्रुटी लपवू शकतात.

भविष्यातील दृष्टीकोन

ही घटना कोणत्याही SaaS साठी मोठा धोका दर्शवते जे टेबल्स शेअर करतात. सुरक्षा ऑडिटमध्ये (Security audits) आयडेंटिफायर्स स्वीकारणाऱ्या सर्व एंडपॉइंट्सचा (endpoints) आढावा घेतला पाहिजे आणि टेनंट स्कोपिंग समान रीतीने लागू केले जाते याची खात्री केली पाहिजे.

निष्कर्ष: केवळ एक गहाळ झालेली tenant check विशेषाधिकार प्राप्त वापरकर्ता भूमिकेला युनिव्हर्सल बॅकडोअरमध्ये बदलू शकते. योग्य स्कोपिंग (scoping) हे ऐच्छिक नाही; ते कोणत्याही मल्टी-टेनंट सिस्टममधील डेटा आयसोलेशनचा पाया आहे.